Oracle Cloud Infrastructure Kubernetes Engine (OKE) now supports clusters with up to 20,000 worker nodes, helping customers run larger compute pools under a single Kubernetes control boundary when their workload requires it. This update is designed for operating large AI/ML, GPU, batch, high-churn job, and distributed data processing environments where splitting capacity across many clusters can create avoidable scheduling, security, operational, and business complexity.

Large clusters are not the right answer for every workload. Large clusters are most useful when your architecture benefits from one shared scheduler, one large capacity pool, and fewer cluster boundaries. For many applications, multi-cluster designs still remain the better choice for isolation, blast-radius control, regional separation, tenant boundaries, or independent upgrade cadence.

Why larger Kubernetes clusters matter

Very large compute environments are often easier to use when capacity can be managed as part of a larger shared pool. Instead of spreading capacity across many smaller clusters, you can benefit from fewer cluster boundaries, simpler scheduling, more consistent operational controls, and better utilization of expensive compute resources.

This value can apply to both GPU and CPU environments.

  • For AI/ML and GPU environments, you may want a large pool that can be shared across training, fine-tuning, inference, experimentation, and supporting CPU workloads. A larger Kubernetes cluster can help teams keep more of that work under one scheduler and one operating model. This is increasingly relevant as large multi-node GPU systems and related Kubernetes software introduce larger multi-node GPU topologies.
  • For CPU-heavy environments, the value is different. Large job-oriented clusters can benefit from a design that accounts for pod churn, node lifecycle throughput, image-pull behavior, control-plane responsiveness, add-on configuration, and observability from the start. As these systems grow, planning for those details earlier can help you avoid operational constraints later.

When to use a large cluster, and when not to

A larger single cluster can be a good fit when the workload benefits from one shared scheduler, one large capacity pool, and fewer cluster boundaries. This is often relevant for large AI/ML and GPU environments, or for job-oriented platforms where you want to operate a very large fleet under one Kubernetes control plane.A larger single cluster can be the wrong fit when you need stronger isolation between teams or applications, independent upgrade schedules, or separate regional blast-radius boundaries. In those cases, a multi-cluster architecture may remain the better choice.

Bottom line: the decision should start with the workload, not the limit.

Planning for OKE clusters between 5,000 and 20,000 nodes

Running a very large Kubernetes cluster requires more than increasing a limit. Some items are required before scaling above 5,000 worker nodes; others are design decisions that should be reviewed before you create or expand a cluster at this scale.

Customers planning OKE clusters above 5,000 worker nodes should engage their Account team early. Early engagement helps validate workload fit, cluster design assumptions, capacity needs, and readiness before implementation begins.

Before scaling above 5,000 worker nodes, note these cluster configuration requirements:

  • Use OKE Enhanced clusters
  • Run Kubernetes 1.36 or later
  • Use KMS V2

You should also review these design areas before creating or expanding a very large cluster:

  • Design managed node, self-managed node, and node-pool architecture
  • Choose the CNI and IP address plan before cluster creation Oracle recommends Cilium at this scale; if you use flannel, size the Pods CIDR for the target node count and validate startup and performance Ensure the cluster endpoint subnet has capacity for additional endpoint IP addresses
  • Size and configure cluster add-ons Review add-ons that run on every node or process cluster-wide objects, such as Services and EndpointSlices Review kube-proxy resources, rollout settings, and custom configuration before scaling
  • Plan image-pull behavior for large deployments
  • Review workload identity usage for short-lived pods
  • Define observability, alerting, support-data collection, and incident response requirements
  • Confirm OCI service limits, quotas, and capacity availability

Implementation Guidance

1. For New Clusters

For new clusters, plan the large-cluster architecture before creating the cluster. Review the OCI documentation for large-cluster best practices and confirm that the cluster is created with the required version, encryption, networking, add-on, image distribution, observability, and service-limit assumptions in place.

Several large-cluster design choices are difficult to change after cluster creation. Customers should treat the large-cluster guidance as prerequisite planning, not optional tuning.

2. When Enlarging Existing Clusters

When you’re planning to expand an existing cluster beyond 5,000 worker nodes, start with a review of your current cluster configuration before scaling. Existing clusters that still depend on KMS V1 must migrate to KMS V2 before scaling into very large worker-node counts.

Existing clusters may also need review of Kubernetes version, CNI and subnet design, IP address capacity, add-on configuration, image-pull behavior, workload identity usage, observability, and service limits.

You should work with Oracle before expanding an existing cluster into this scale range.

3. Workload and API behavior

Very large clusters amplify normal Kubernetes behavior. Customers should evaluate not only node count, but also object size, object churn, list/watch patterns, controller behavior, and third-party components that create or reconcile large numbers of Kubernetes objects.

4. Scale-up slowly

Whether you are starting new or growing an existing cluster, remember to scale up at a slow, deliberate speed. Gradual node growth up to your top cluster size is important.

Getting started

When you are planning to use very large clusters with OKE, you should start by documenting the workload profile, target node count, pod density, expected churn, CNI choice, IP addressing plan, Kubernetes version, node model, image-pull pattern, region, and operational requirements.

Contact your Oracle account team to begin your journey to using up to 20,000 worker node clusters. 

Review the following OCI documentation:

With the right design, OKE 20K worker node support can help you operate larger compute pools with less cross-cluster coordination and a clearer Kubernetes operating model.