OKE in production: what is different from EKS and GKE

Teams who have run EKS or GKE find OKE familiar within an hour — it is upstream Kubernetes with a managed control plane, the usual add-ons and a sensible CLI. The differences that matter are few, and three of them are worth planning around.

The three real differences

The basic control plane is free. Enhanced clusters carry a per-hour fee and add features you probably want in production (add-on lifecycle management, workload identity, higher node limits), but the entry cost is lower than the equivalents. On an estate with many small clusters — per-team or per-environment — this genuinely changes what is affordable.

Ampere A1 ARM node pools with a substantial always-free allowance. For a development or internal-tools cluster, this can mean the compute is close to free. The same build considerations apply as anywhere else: multi-arch images, a check that your agents and operators have ARM builds, and separate node pools rather than mixed architectures.

The CNI choice is made at cluster creation and cannot be changed. This is the decision to get right.

VCN-native or flannel: choose deliberately

VCN-native pod networking gives each pod an IP from a VCN subnet. Pods are directly addressable from the rest of your VCN, network security groups apply to pods, and service-to-service traffic does not traverse an overlay. It is the right choice for production, and it comes with the constraint that you must plan the pod subnet with real headroom — the same exhaustion trap that catches people on Azure CNI in AKS.

Size it properly: pods per node times maximum nodes, plus surge capacity for upgrades. A /24 is not enough for a cluster you intend to grow.

Flannel overlay conserves VCN address space and is simpler where IP space is constrained, at the cost of pod-level network policy and direct addressability.

There is no in-place migration between them, so this is a cluster-recreate decision.

Identity: workload identity, not config files

Enhanced clusters support workload identity, which lets a Kubernetes service account authenticate to OCI services directly. Use it. The alternative — an API signing key in a Kubernetes Secret — is the credential pattern that OCI policies and dynamic groups exist to replace.

For node-level access to OCI APIs, instance principals via a dynamic group matched on the node pool's compartment and a defined tag.

Node pools and cost

The cost work is the same as on every managed Kubernetes and the lever is the same: requests set from observed usage, and packing. Everything in why your EKS cluster costs twice what it should transfers unchanged — the ratio of requested to used CPU is the number that decides your bill regardless of provider.

OCI-specific additions:

• Flexible shapes for nodes. You can size a node pool to the exact OCPU and memory your pods need instead of rounding to a t-shirt size, which improves packing before you tune anything.
• Preemptible node pools for batch, CI and stateless replicas.
• A separate node pool for system components, tainted, so add-ons are not competing with workloads.

Cluster Autoscaler is the supported autoscaler; configure it per node pool and set sensible minimums so a scale-to-zero does not leave you without capacity for CoreDNS.

Operational checklist before production

• Private API endpoint, with a bastion or an OCI Bastion service session for access. A public Kubernetes API endpoint is an unnecessary attack surface.
• Network security groups on the pod and node subnets, not just security lists — NSGs are the more granular and more maintainable of OCI's two firewall models.
• Logging to OCI Logging and metrics to Monitoring, with the flow logs on the VCN enabled.
• Image scanning in OCI Container Registry, and Cloud Guard enabled on the tenancy.
• Upgrade plan. OKE versions age out on a schedule like every managed Kubernetes; set a quarterly cadence and test in a non-production cluster of the same version.
• Pod Disruption Budgets before your first node pool upgrade, not after.

Where OKE fits

For an organisation already on OCI for cost or licensing reasons, OKE is a solid managed Kubernetes with no significant gaps for standard workloads. It is not a reason on its own to choose OCI, and the ecosystem around it — operators, Helm charts assuming other clouds, vendor integrations — is thinner, so budget some time for the edges. We deploy and run it in cloud engagements alongside the other three providers.

What to do this week

Check which CNI your cluster uses and, if it is VCN-native, calculate how many pods your pod subnet supports. That number is your scaling ceiling and it is much better known now than during a scale-up.