Your search did not match any results.
The Oracle Container Native Platform is an open source, and community driven solution that includes a managed container registry (Oracle Cloud Infrastructure Registry), and a managed Kubernetes service (Oracle Container Engine). The platform leverages Oracle Cloud Infrastructure for high performance, high availability, security and reliability. Oracle plans to add Oracle Container Functions and Oracle Container Microservices to the platform in the near future.
With this platform, Oracle provides a complete and enterprise-grade suite of cloud services to build, deploy, and operate container-native microservices and serverless applications. As developers rapidly adopt container-native technologies for new cloud-native applications and for migrated traditional applications, they are becoming increasingly concerned about getting locked in by their cloud vendors and their application development platform vendors. Moreover, they are seeking the true hybrid cloud, using the same stack in any cloud and on-premises. The Oracle Container Native Platform prevents vendor lock-in by adopting open source standards, and supporting community-driven development of the platform so that its components can run in any cloud environment.
Read more here.
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 master nodes are run in Oracle's managed tenancy for you.
No. When you create a managed Kubernetes cluster, Oracle automatically creates and manages a set of multiple master 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 master 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 master 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 master 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, you have the option of creating your managed Kubernetes cluster with worker nodes in private subnets. These worker nodes have private IP addresses only and will require NAT gateway for outbound connections to your cluster masters and internet.
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.
OCIR or Oracle Cloud Infrastructure Registry is a Docker v2 compatible Docker image registry.
OCIR is best used to store Docker images you will utilize in Containerized Applications, such as those that you deploy with Container Engine for Kubernetes.
It's easy, just create an Auth Token via your user settings and login with the Docker CLI. See the registry documentation.
Docker users are familiar with short urls to push and pull images. Other cloud providers also use shortened URLs. We wanted to make sure that usage of OCIR conforms to these user expectations.
You can scale in and scale out within minutes. You can also control how frequently autoscaling is triggered by adjusting a cooldown period that defines how long to wait between autoscaling actions.
The regional URLs align with the nearby airports. phx.ocir.io; iad.ocir.io; lhr.ocir.io; fra.ocir.io.
Yes, you need to specify the entire path, in this format: .ocir.io///:tag, for example: phx.ocir.io/tenancy-foo/project01/nginx:latest.
Docker users are used to a repository based structure for their container registries. Administrators can limit access to a particular repo path, both for read-only (pull only) and push/pull. Adding compartments would add an unnecessary level of complexity to this simple concept.
Quotas are 500 repos total and 500 images per repo PER region.
Yes, an administrator of the tenancy can make any repo public. This means that if a user has the complete path to the image, they can pull it, with no authentication needed. Note, that the user will not be able to see the Oracle Cloud Infrastructure console page, they will just be able to pull the image.
Yes, with our auto-cleanup feature, you can set retention policies, so for example, if an image is not pulled in x days, it is automatically deleted.
Yes, create a user for that service account and an "Auth Token" (formerly Swift Password), which can be revoked at any time. Put that user in a group that supports your use case, via policy, such as read only and limited to a particular repo path. See Policies to Control Repository Access documentation.
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