Announcing private Kubernetes clusters

March 16, 2021 | 3 minute read
Greg Verstraeten
Senior Principal Product Manager
Text Size 100%:

Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE) reduces the operational burden of setting up and managing enterprise-grade Kubernetes clusters. We recognize that Kubernetes and its ecosystem is complex, so we built OKE with the following design principles in mind:

  • Secure by default: OKE hardens Kubernetes clusters following Enterprise Security best practices.

  • Simplified Kubernetes operations: Oracle manages your cluster resources and automates recurrent Kubernetes administration and scaling tasks.

  • High performance: Containerized applications run on high-performance Compute resources through OCI's non-blocking network.

Today, we’re excited to announce the general availability of fully private Kubernetes clusters for Oracle Container Engine for Kubernetes (OKE). You can now create fully private OKE clusters that don’t use or expose any public IPs.

Fully private Kubernetes clusters

Organizations require robust access control to their Kubernetes Clusters to meet their security and compliance needs. This requires fully integrating Kubernetes clusters with your virtual cloud network (VCN). In OKE, your cluster worker nodes and load balancers are already part of the VCN, you can now add the Kubernetes API endpoint to the VCN too.

Kubernetes administrators configure the Kubernetes API endpoint of a cluster as part of a private or public subnet. Regular VCN routing and firewall rules control the access to the Kubernetes API endpoint and make it accessible from a corporate network only, through a bastion host, or by specific SaaS services. Let's explore these three use cases.

First, to access the Kubernetes API endpoint from authorized subnets in a corporate network, specify a private subnet for your endpoint. In this case, you would typically peer your VCN to your corporate network using OCI FastConnect, which provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure.

Second, if you don't peer your corporate network, you can use a bastion host, which provides access to resources on a private network. To access your API endpoint through a bastion host, configure the endpoint to a private subnet in your VCN and a bastion server on a public subnet. Kubernetes users can set up an SSH tunnel through a bastion to interact with their Kubernetes API endpoint.

Finally, you might also want to configure the Kubernetes API endpoint on a public subnet of a VCN. For example, this configuration can be useful when your continuous integration-continuous delivery (CI/CD) pipeline runs on a third-party SaaS CI/CD service. In this case, restrict the access to your Kubernetes API endpoint to the SaaS service network IPs.

Want to know more?

To learn more or get hands-on, use the following resources:

Greg Verstraeten

Senior Principal Product Manager

Previous Post

Announcing Oracle Cloud Compute E4 platform on third gen AMD EPYC processors

Rajan Panchapakesan | 7 min read

Next Post

Available now: Performance Hub for on-premises databases

Sriram Vrinda | 5 min read