Kubernetes Is a Commitment, Not a Default

The Decision in Front of You

Kubernetes is open-source software that schedules containers across a fleet of machines, restarts them when they fail, and gives teams a common interface for deploying software. It is the most widely used way to run containers. The CNCF's 2024 survey of 750 members of its community found 80% of organizations running it in production, up from 66% in 2023 ¹¹³. The same survey found cultural and operational change had overtaken security as the top challenge ¹.

The decision is whether your organization should be one of them. Kubernetes gives a large engineering organization one consistent platform for many services. It also carries a fixed operating cost: people who understand it, upgrades on the project's schedule, and a set of add-on components that each have their own maintainers, vulnerabilities and retirement dates.

Those costs do not shrink with the size of the application. A company running six services pays most of the same platform overhead as one running sixty. The question is whether you have enough work on the platform to spread that cost.

What's Happening

The release clock does not stop

The Kubernetes project ships a new minor version about every four months, and each one receives roughly a year of patch support ²⁴. Only the three most recent minor versions are maintained ². A cluster that is not upgraded at least once a year falls out of security support.

Upgrades are more than a version number. Kubernetes removes beta APIs on a published schedule: a beta API is deprecated within nine months or three releases of its introduction and stops being served nine months or three releases after that ³. Any deployment file, chart or tool that still uses a removed API fails on the new version. Each upgrade is a small migration project.

Managed services charge for falling behind. Amazon EKS charges $0.10 per cluster per hour during the first 14 months of a version and $0.60 per cluster per hour during the following 12 months of extended support ⁵. Azure AKS offers a second year of support only on its Premium tier ⁴. From June 1, 2027, AKS will upgrade clusters left on unsupported versions after a 60-day grace period, and that upgrade will not follow the customer's maintenance window, will not stop for deprecated APIs, and can override safeguards that keep applications running during node drains ⁴.

Teams reserve far more than they use

Datadog's telemetry from thousands of customers shows most workloads across Kubernetes, AWS Fargate, Google Cloud Run, Azure Container Apps and AWS Lambda use less than half of their requested memory and less than a quarter of their requested CPU ⁷. Its 2023 report found over 65% of Kubernetes workloads using less than half their requested CPU and memory, and fewer than 1% of Kubernetes organizations using the Vertical Pod Autoscaler that adjusts those requests ⁶. Datadog notes its customers skew toward heavier cloud users, so the sample is not the whole market ⁶⁷.

The same 2023 data showed version lag. The most common Kubernetes release among Datadog customers was about 16 months old ⁶.

Simpler runtimes are already mainstream

Managed runtimes that hide the cluster are now common. Datadog's 2025 data shows Google Cloud Run used by 70% of its Google Cloud customers, AWS Lambda by 65% of AWS customers, and Azure App Service by 56% of Azure customers ⁷. A third of organizations using serverless functions run no container orchestration at all in that cloud ⁷. Its 2023 report found 46% of container organizations already running serverless containers, up from 31% two years earlier ⁶.

The ecosystem's components retire too

Ingress NGINX, 2025 to 2026. Ingress NGINX is the add-on that routed outside web traffic into a large share of Kubernetes clusters. The Kubernetes steering and security committees said about half of cloud native environments relied on it, citing Datadog research, and that one or two people had maintained it in their spare time for years ⁹. On November 11, 2025 the project announced its retirement: best-effort maintenance until March 2026, then no releases, bug fixes or security patches ⁸. The committees warned that none of the alternatives are drop-in replacements and that existing installations would keep working, so a later compromise might be the first sign of trouble ⁹. Users had about four months between the announcement and the end of maintenance.

IngressNightmare, 2025. The same component carried the year's most serious Kubernetes vulnerability. In March 2025 Wiz disclosed a chain of flaws, including CVE-2025-1974, rated 9.8 out of 10, that let an unauthenticated attacker run code inside the controller and read every secret in every namespace, which can lead to full cluster takeover ¹⁰. Wiz estimated about 43% of cloud environments were vulnerable and found more than 6,500 clusters exposing the vulnerable component to the internet ¹⁰.

Gitpod, 2024. In October 2024 Gitpod, a cloud development environment company with about 1.5 million users, published why it was leaving Kubernetes after six years ¹¹. Its workload, interactive developer machines that need root access, bursty CPU and fast startup, fought the platform at every layer, and the team built extensive custom machinery for CPU, storage, networking and security before replacing it with its own system ¹¹. The authors were explicit that the lesson is about fit, writing that for application workloads Kubernetes "continues to be a fine choice" ¹¹.

Platforms help large organizations most

Google's 2024 DORA research found internal developer platforms raise developer productivity, are more common in larger organizations, and often cause a temporary drop in performance before the gains appear ¹². The best results came from platforms run as products, designed around their users ¹². A platform needs enough users to be worth building and a team to run it as a product.

Why the Usual Approach Fails

Kubernetes is often chosen as a résumé standard. Engineers want experience with it, hiring managers ask for it, and architecture reviews treat it as the safe choice. The business case covers the migration and stops there.

The recurring work is invisible at approval. Three upgrades a year per cluster, API removals, add-on lifecycles, node image updates, certificate rotation, and on-call for the control plane all land on the same few people. When those people leave, the knowledge goes with them.

Managed Kubernetes reduces the work without removing it. EKS, AKS and GKE run the control plane. The customer still owns the version, the add-ons, the workload configuration and the upgrade timing, and pays more for falling behind ⁴⁵.

Add-ons are treated as part of the product. Ingress controllers, certificate managers, service meshes and monitoring agents come from separate projects with separate maintainers. Ingress NGINX showed that a component used by half the ecosystem can be retired with months of notice ⁸⁹.

The Framework: Three Thresholds

Adopt Kubernetes when all three of these hold. If one fails, a managed container or serverless runtime is the better default.

Workload count. Enough independently deployed services that a shared scheduling and deployment layer saves real effort. In the author's experience that starts around 15 to 20 services, or fewer when several have unusual needs such as GPUs, stateful workloads, or strict placement across regions and providers.

Team size. Enough engineers that two or three of them can own the platform full time without starving product work. As a rough guide, an engineering organization of 40 or more can carry that team. Below that, the platform competes with features for the same people.

Release frequency. Enough deployments that consistent, automated rollout matters. Teams shipping several times a day across many services gain the most. Teams releasing monthly gain little.

flowchart LR
    A[15+ services<br/>or special needs] --> B[40+ engineers<br/>platform team funded]
    B --> C[Frequent releases<br/>across many services]
    C --> D[Adopt Kubernetes<br/>as a funded platform]
    A -->|no| E[Managed containers<br/>or serverless]
    B -->|no| E

Portability alone does not pass the test. Kubernetes runs on every major cloud and on-premises, but applications still depend on each provider's databases, identity and storage. If multi-cloud is a requirement, price it separately.

What the standing cost looks like

The following illustrative model shows a mid-size company running six managed clusters (production, staging and development in two regions).

The control plane fee is small. People are the cost, and they do not scale down when the workload is small. A company with six services pays nearly the same $660,000 as one with sixty.

Costs, Risks, and Tradeoffs

Managed runtimes have their own lifecycle. Language runtimes on Lambda or App Service retire on the provider's schedule, and request limits, cold starts and per-request pricing can bite at high steady load. The difference is the size of the team needed to keep up.

How to Act

Questions to Ask Your Team

1. How many services run on our clusters, and how many engineers own the platform full time?
2. When does each cluster's Kubernetes version leave support, and who has the upgrade on their calendar?
3. Are we paying extended support fees on any cluster today?
4. Which add-ons do we run, who maintains each one, and which have announced retirement?
5. What share of the CPU and memory we reserve do our workloads use?
6. Which of our services would run more cheaply on a managed container or serverless runtime?
7. If our two most experienced platform engineers left, who could perform the next upgrade?

Closing

Kubernetes is a sound platform for organizations with many services, many engineers and frequent releases. For everyone else, managed runtimes deliver most of the benefit without a standing team. Score your workload against the three thresholds before adopting. If you adopt, carry the platform team and the upgrade cycle in the operating budget every year, the way you would any other system the business depends on.