Container Engine for Kubernetes enables you to quickly create, manage and consume Kubernetes clusters that leverage underlying compute, network and storage services without the need to install and maintain complex supporting Kubernetes infrastructure.
You should use Container Engine for Kubernetes when you want to leverage Kubernetes to deploy and manage your Kubernetes based container applications. It allows you to combine the production grade container orchestration of standard upstream Kubernetes, with the control, security and high predictable performance of Oracle Cloud Infrastructure.
There is no dedicated charge for Container Engine for Kubernetes. You only pay for the resources you use for the underlying compute, storage and network used by your Kubernetes clusters. In addition, you are only charged for the "worker" nodes running in your tenancy, your parent nodes are run in Oracle's managed tenancy for you.
Container Engine for Kubernetes is supported on all regions as documented in Regions and Availability Domains.
OKE is compliant with a number of industry standards and regulations, including, but not limited to, FedRAMP High, ISO/IEC 27001, PCI DSS, SOC1/2/3, and more. For more information, please refer to the infrastructure compliance page.
No. When you create a managed Kubernetes cluster, Oracle automatically creates and manages a set of multiple parent nodes across different Availability Domains (logical datacenters) in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these parent nodes to new versions of Kubernetes with zero downtime.
Yes. Kubernetes clusters are created with standard upstream Kubernetes versions. These versions are also certified against the Cloud Native Computing Foundation (CNCF) conformance program.
When you create a managed Kubernetes cluster, Oracle automatically creates and manages a set of multiple parent nodes across different Availability Domains (logical datacenters) in the Oracle control plane on your behalf (and associated Kubernetes infrastructure such as etcd nodes) to ensure you have a highly available managed Kubernetes control plane. You can also seamlessly upgrade these parent nodes to new versions of Kubernetes with zero downtime. Provisioned worker nodes are also automatically labeled with their Availability Domain and Region well known Kubernetes labels to enable customers to leverage Kubernetes scheduling mechanisms to build and deploy resilient container based applications.
Yes. Managed Kubernetes clusters are enabled with Kubernetes RBAC. Managed Kubernetes is also integrated with Oracle Identity and Access Management (IAM), enabling users with powerful controls over access to their clusters.
Yes. You can deploy a managed Kubernetes cluster into an existing VCN, giving you a great degree of control over the use of underlying subnets, and security lists.
Yes. With OKE, your Kubernetes clusters are integrated in your virtual cloud network (VCN). Your cluster worker nodes, load balancers, and the Kubernetes API endpoint are part of a private or public subnet of your VCN. 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 platform services.
Yes. You can deploy a managed Kubernetes cluster on pure bare metal Nodes. You can also leverage the concept of "node pools" (a set of nodes sharing a common node size / image) to create a cluster of both bare metal and virtual machines and target your Kubernetes workloads appropriately.
Yes. Container Engine for Kubernetes allows users to expose Kubernetes services of type "LoadBalancer" and create Oracle load balancers. Users can also create Kubernetes Persistent Volumes and Persistent Volume Claims backed by Oracle Block Volumes.
Yes. When you create a cluster, you can provide a public/private SSH key pair in order to SSH into your worker nodes if desired.
Yes. Worker nodes run the standard Docker runtime, so that users can leverage familiar Docker commands.
Oracle Cloud Infrastructure Service Broker for Kubernetes (OSB or “Service Broker") is an implementation of the Open Service Broker API that can be used to interact with Oracle Cloud Infrastructure Services. With Oracle Cloud Infrastructure Service Broker, you can manage the lifecycle of Oracle Cloud Infrastructure services natively from within Kubernetes via Kubernetes APIs, which means the following:
No need to go to a separate system to provision application-dependent services when deploying an application in Kubernetes.
The lifecycle of dependent Oracle Cloud Infrastructure services can be linked to the applications that depend on them.
Applications become more portable as dependencies can be easily encoded in DevOps procedures.
To use Oracle Cloud Infrastructure Service Broker, you install it in your Kubernetes cluster along with Kubernetes Service Catalog. You can then use kubectl commands that get interpreted into Oracle Cloud Infrastructure CLI commands.
See https://github.com/oracle/oci-service-broker for more information.
As of this writing, you can use Oracle Cloud Infrastructure Service Broker to provision and create service bindings to the following Oracle Cloud Infrastructure service types:
You can use Oracle Cloud Infrastructure Service Broker from within a Kubernetes cluster created on Oracle Linux (using Oracle Container Services for Kubernetes) running on premises to create service instances on Oracle Cloud Infrastructure, but you cannot use the Oracle Cloud Infrastructure Service Broker to provision services that run on premises.
Oracle Cloud Infrastructure Service Broker is normally deployed as a pod in your Kubernetes cluster. With that, the easiest way to troubleshoot the pod is to get the logs from the pod with the following commands:
Users who use Oracle Cloud Infrastructure Service Broker to create Oracle Cloud Infrastructure service instances, such as an ATP database instance, need to have a role that has permission to create those services. For example, make sure that you have a policy in your Oracle Cloud Infrastructure tenancy that looks like the following policy:
Allow group OCI-Service-Broker-Group to manage autonomous-database in compartment