Getting Started with OKE

OCI Kubernetes Engine, known as OKE, is the managed Kubernetes service on Oracle Cloud Infrastructure. If you have decided that containers are how you want to run an application, OKE is the fastest supported way to get a production grade cluster on OCI without operating the Kubernetes control plane yourself. The problem most teams hit is not the idea of Kubernetes, it is the gap between a tutorial cluster and a cluster you would trust with real traffic. This guide walks the path from nothing to a first working deployment, and points out where the early decisions matter for later.

This is part of our OKE and containers series. The pillar is the map, and this article is the on ramp.

What you need before you start

OKE sits on top of several OCI building blocks, and getting them in place first saves a lot of confusion. You need a tenancy with a compartment to hold the cluster resources, a virtual cloud network with the right subnets, and the IAM policies that let OKE create and manage the resources it needs on your behalf. You also need the OCI command line tool configured, and kubectl installed locally so you can talk to the cluster once it exists.

The networking is the part people underestimate. A cluster needs subnets for the Kubernetes API endpoint, for the worker nodes, and for the load balancers that expose your services. OCI provides a quick create flow that builds all of this for you, which is fine for a first cluster, but for anything that will live alongside other workloads you want the network designed deliberately. We cover that in OKE cluster architecture and OKE networking explained.

Quick create versus custom create

OKE gives you two ways to stand up a cluster, and the choice frames everything that follows.

For your very first cluster, quick create is the right call because it lets you see the whole flow without getting lost in network design. For a cluster that will host a real application, use custom create so the cluster lands in a network you control and can secure properly.

Choosing a cluster tier

OKE offers basic and enhanced clusters. Enhanced clusters unlock virtual nodes, fuller add on management, workload identity and a financially backed control plane SLA. Basic clusters cover simple cases. For learning, basic is fine and cheaper. The moment you are heading toward production, choose enhanced, because some features you will want later, such as virtual nodes, are only available on enhanced clusters and you cannot bolt them on after the fact without recreating.

Creating your first cluster, step by step

The node pool is where your money goes, so do not over size it on day one. Three small nodes is plenty to learn on, and you can grow the pool or add the autoscaler later, as covered in autoscaling OKE workloads.

Connecting kubectl to the cluster

Once the cluster is running, you connect your local kubectl to it using the OCI command line tool, which writes a kubeconfig entry pointing at the cluster API endpoint. From that point on, kubectl works exactly as it does against any Kubernetes cluster, because OKE runs conformant upstream Kubernetes. A quick test is to list the nodes, which should show the workers from your node pool in a ready state. If they do, the control plane and the workers are talking to each other and you are ready to deploy.

Deploying your first workload

A good first deployment is a simple stateless web application behind a service of type load balancer. When you create that service, OKE provisions an OCI load balancer automatically and wires it to your pods, giving you a public address that routes traffic into the cluster. Watching that happen end to end teaches you the most important integration point in OKE, which is how Kubernetes services map onto OCI load balancers. Exposing applications properly, including ingress controllers for routing many services behind one load balancer, is covered in OKE networking explained.

Resist the urge to deploy something stateful as your first workload. Databases and other stateful applications on Kubernetes bring real complexity around storage and failover, and they are better tackled once you are comfortable with the basics. When you get there, start with persistent storage on OKE.

The early decisions that matter most

Several choices made in the first hour have long tails. The cluster tier cannot be changed in place, so choosing enhanced early avoids a rebuild. The pod networking model, VCN native versus overlay, shapes how you secure and integrate the cluster and is hard to change later. The compartment and network the cluster lives in determine how it fits with the rest of your estate. And the habit of right sizing node pools from the start, rather than over provisioning and never trimming, is the difference between a cheap cluster and an expensive one. None of these are hard, but all of them are easier to get right at the start than to fix afterward.

Securing the cluster from day one

It is tempting to leave security for later, but a few things belong in place from the first deployment. The Kubernetes API endpoint should be private or tightly restricted rather than open to the internet. IAM policies should grant only the access each person and service needs. And image scanning should be on before you run images in anger. The full layered model is in OKE security best practices, but even a learning cluster benefits from not being wide open.

What to do next

Once you have a cluster, kubectl connected and a first workload running behind a load balancer, you have crossed the gap that stops most teams. The next steps are to understand the architecture you want for production, get networking and autoscaling configured, and put the security layers in place. Work through OKE cluster architecture for the production shape, and decide between managed and self operated Kubernetes with OKE vs self managed Kubernetes if you have not already.

If you would rather have a production grade OKE platform stood up correctly the first time, the OKE solution practice builds clusters to a reference operating model on a fixed project fee, and can run them afterward on a managed monthly retainer.