Is Kubernetes Still Worth It in 2026? v1.37, 82% in Production, Real Costs

People ask me some version of "should we be on Kubernetes?" about once a week, usually right after a team has either spent a quarter building a cluster they did not need or spent a year hand-rolling deploy scripts that Kubernetes would have given them for free. Is Kubernetes still worth it in 2026? It depends on far fewer things than the internet suggests. This post covers what the last four releases (v1.34 to v1.37) actually changed, what the CNCF's 82% production number does and does not tell you, what the managed "autopilot" modes from AWS, Google and Azure cost, where ECS, Cloud Run, Nomad and Fly are the better answer, and the decision framework I use.

What changed in Kubernetes 1.34, 1.35, 1.36 and 1.37?

Kubernetes ships a minor release roughly every four months, and the last four have been unusually substantive. The headline features are no longer about running stateless web apps, which was solved years ago. They are about hardware, identity and making long-running workloads less disruptive.

• v1.34 (27 August 2025): 58 enhancements, 23 to stable. The core of Dynamic Resource Allocation (DRA), the API for requesting GPUs, TPUs and NICs as first-class devices, graduated to GA with resource.k8s.io/v1. Linux swap support and VolumeAttributesClass also went stable.
• v1.35 (17 December 2025): 60 enhancements, 17 stable. In-place Pod resize went GA, so you can change CPU and memory on a running Pod without restarting it. The same release deprecated kube-proxy's ipvs mode and made the kubelet refuse to start on cgroup v1 nodes by default.
• v1.36 (22 April 2026): 70 enhancements, 18 stable. User namespaces, fine-grained kubelet API authorization, mutating admission policies and PSI metrics went GA. Service externalIPs was deprecated with removal planned for v1.43, and the old gitRepo volume was removed.
• v1.37 (26 August 2026): 67 enhancements, 16 stable. HPA scale to zero is now beta and on by default for object and external metrics, gang scheduling reached beta, Pod certificates and ClusterTrustBundles went stable, and Pod-level checkpoint and restore arrived as alpha.

Two things stand out. First, the project is spending its effort on AI and batch workloads (DRA, gang scheduling, workload-aware scheduling, scale to zero) and on security defaults (user namespaces, Pod certificates). That is where the platform is going, and I covered the agent side of it in Kubernetes as the agent control plane. Second, every release also removes or deprecates something. If you run Kubernetes, you are signing up to read release notes three times a year.

What the CNCF survey's 82% actually measures

The CNCF's annual survey, published 20 January 2026, reports that 82% of container users run Kubernetes in production, up from 66% in 2023. It also says 66% of organisations hosting generative AI models use Kubernetes for some or all of their inference, and that the top challenges are cultural change in the development team (47%), lack of training (36%), security (36%) and complexity (34%).

Read the denominator carefully: that is 82% of container users who answered a CNCF survey. It is a good signal that Kubernetes won the orchestrator war among organisations already invested in cloud native tooling. It is not evidence that a five-person startup with one web app and a Postgres database should run a cluster. Notice also that the top challenges are people problems, not technology problems. Nobody lists "the scheduler is bad". They list "our developers do not know how to use this" and "we do not have the training".

That matches what I see. Kubernetes rarely fails on technical grounds. It fails when an organisation adopts it without the platform discipline to make it boring: version upgrades, a paved path for deploys, someone who owns the cluster add-ons, and observability good enough to answer "why did this Pod restart?" at 3 a.m. If you want a worked example of that last question, my sibling guide on fixing CrashLoopBackOff is exactly that.

What does Kubernetes cost to operate in 2026?

The bill has three parts, and only one of them is on the invoice.

The control plane fee is the easy part. EKS and GKE both charge $0.10 per cluster-hour, roughly $73 a month. Google's free tier credits $74.40 a month per billing account, which covers one zonal or Autopilot cluster. AKS has a free control plane tier without an uptime SLA, and the Standard tier costs $0.10 an hour according to Azure's retail price list.

The version treadmill is the expensive part. Upstream supports each minor release for about 14 months: the releases page currently lists 1.34 reaching end of life on 27 October 2026. EKS gives you 14 months of standard support and 12 of extended support, but extended support costs $0.60 per cluster-hour, six times the base fee, and when it ends AWS upgrades your control plane for you with no notification. GKE's Extended channel charges the same $0.50 surcharge. Those prices exist to make standing still painful, and they work.

The add-on tax is the part teams forget. A useful cluster needs an ingress or Gateway API controller, DNS and certificate automation, a secrets integration, metrics, logs, autoscaling and policy. Each has its own release cycle and its own CVEs. The clearest recent example: Ingress NGINX, probably the most widely deployed controller, stopped receiving any fixes after March 2026 because one or two volunteers could no longer maintain it. Every cluster running it now has a migration project, which I cover in what replaces Ingress NGINX.

Here is the small script I run against any EKS account before I give an opinion about its Kubernetes estate. It answers the only question that matters for the treadmill: how many months until someone has to do an upgrade?

#!/usr/bin/env bash
# Show which EKS versions are in standard vs extended support, and what your
# clusters run. Requires AWS CLI v2 (tested with 2.x) and kubectl >= 1.34.
set -euo pipefail

# Support dates straight from the EKS API (documented in the EKS user guide)
aws eks describe-cluster-versions \
  --query 'clusterVersions[].[clusterVersion,status,endOfStandardSupportDate,endOfExtendedSupportDate]' \
  --output table

# Every cluster in the region and its control plane version
for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  v=$(aws eks describe-cluster --name "$c" --query 'cluster.version' --output text)
  echo "${c}: control plane ${v}"
done

# Node kubelet versions for the current context (skew beyond 3 minors is unsupported)
kubectl get nodes -o custom-columns=NODE:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion

EKS Auto Mode vs GKE Autopilot vs AKS Automatic

All three clouds now sell a mode where they run the nodes, the autoscaler and the core add-ons for you. They differ in what you pay for and how much control you keep.

Option	Fixed fee	How compute is billed	What it manages	Source
EKS (standard)	$0.10/cluster-hr; $0.60 in extended support	EC2 you provision	Control plane only	AWS EKS pricing
EKS Auto Mode	$0.10/cluster-hr	EC2 plus a per-instance fee (about 12% of on-demand in AWS's worked example)	Nodes, scaling, core add-ons	AWS EKS pricing
GKE Autopilot	$0.10/cluster-hr, $74.40/month credit	Per Pod resource requests, per second	Nodes, scaling, security defaults	GKE pricing
AKS Automatic	$0.16/hr hosted control plane	VMs plus a small hourly surcharge by VM family	Nodes, scaling, preconfigured add-ons	AKS pricing, Azure retail price API
Amazon ECS	None	EC2 or Fargate	Scheduling, no Kubernetes API	ECS pricing
Cloud Run	None	$0.000024 per vCPU-second active; 180,000 vCPU-seconds free	Everything; you ship a container	Cloud Run pricing

GKE Autopilot is the most opinionated: you pay for what your Pods request, which pushes teams to set requests properly (a habit worth having anyway, see requests and limits explained). EKS Auto Mode keeps the EC2 mental model and adds a management fee on top, so it rewards teams already fluent in instance types and Savings Plans. AKS Automatic reached general availability in September 2025 and is the newest of the three.

My view: if you are going to run Kubernetes and you have fewer than two people who would describe themselves as platform engineers, start on one of these modes. The extra fee is cheaper than the engineer-weeks you would otherwise spend on node AMIs, CNI upgrades and cluster autoscaler tuning. Move to self-managed node groups only when a specific constraint (GPU scheduling, a kernel feature, a compliance control) forces it.

Is Kubernetes overkill for a small team?

Often, yes. The honest test is not team size but how many of these you actually need:

1. More than a handful of services that deploy independently, with different scaling profiles.
2. Portability across clouds or into customer environments (on-premises installs, air-gapped regions). The Kubernetes API is the closest thing the industry has to a universal deployment target.
3. Specialised scheduling: GPUs, gang-scheduled training jobs, bin-packing batch work. DRA and gang scheduling are now in the core, and nothing else matches them.
4. An ecosystem dependency: you want Argo CD, operators for your databases, a service mesh, or a vendor whose product ships as a Helm chart.
5. Someone who owns it: a person or team whose job includes the upgrade treadmill.

If you tick zero or one of these, Kubernetes is probably overhead. If you tick three or more, the alternatives start to need their own glue code, and you end up rebuilding a worse Kubernetes. The middle is where managed autopilot modes earn their fee.

Kubernetes alternatives in 2026: ECS, Cloud Run, Nomad and Fly

Amazon ECS has no orchestration charge, integrates tightly with IAM, ALB and CloudWatch, and has far fewer moving parts. The cost is lock-in: task definitions are not portable, and the ecosystem of operators and charts does not exist. For an AWS-only company running a dozen services, it is often the right call.

Google Cloud Run removes the cluster entirely. You give it a container, it scales on requests, including to zero, and you pay per vCPU-second while it is active. It struggles with long-lived background workers, heavy stateful workloads and anything that needs a sidecar-rich topology. The sibling post on serverless in 2026 goes deeper on where it breaks.

HashiCorp Nomad is a single binary that schedules containers, VMs and raw executables, and it is still actively released (v2.0.7 shipped in September 2026). Two caveats: it is under the Business Source License, not an open source licence, and HashiCorp has been part of IBM since 27 February 2025. The community and hiring pool are a fraction of Kubernetes'.

Fly.io runs Fly Machines, fast-launching VMs you start and stop through a REST API. It suits globally distributed apps and per-user or per-session compute. I am biased here: PandaStack, my company, is also a Firecracker microVM platform, so I like the model. For untrusted code and AI agent sandboxes a VM boundary is a better fit than a shared-kernel Pod, a trade-off I covered in container vs microVM vs gVisor. For a normal web backend, either works.

A decision framework for 2026

This is the order I walk through with a team:

• One to five services, one cloud, no GPUs: Cloud Run, ECS on Fargate, or a PaaS. Revisit in a year.
• Five to thirty services, one cloud, a small platform function: managed Kubernetes in autopilot mode (GKE Autopilot, EKS Auto Mode, AKS Automatic) with GitOps and a short list of add-ons.
• Multiple clouds, customer-hosted installs, GPU or batch scheduling, or a dedicated platform team: Kubernetes, standard mode where you need control, and a real upgrade calendar.
• Untrusted code, per-tenant isolation, agent sandboxes: microVMs, either alongside Kubernetes (Kata Containers, the Agent Sandbox project) or on a dedicated platform.

Whatever you choose, cost the treadmill, not the control plane. The $73 a month is noise. Three upgrades a year, each touching your CNI, ingress, CSI drivers and every Helm chart, is the real number, and only you can estimate it. The Kubernetes cost optimisation post covers the compute side once you are in.

FAQ

Is Kubernetes still relevant in 2026?

Yes. The CNCF's 2025 survey found 82% of container users run it in production, and the project shipped 67 enhancements in v1.37 alone. Its direction has shifted towards AI and batch workloads, with GPU allocation (DRA) GA since v1.34 and gang scheduling in beta.

What is the latest Kubernetes version?

As of October 2026 the latest minor release is v1.37, released 26 August 2026, with patch v1.37.1. Upstream supports 1.37, 1.36 and 1.35, and 1.34 reaches end of life on 27 October 2026.

Is EKS Auto Mode cheaper than managing nodes yourself?

On the invoice, no: it adds a per-instance management fee on top of EC2, about 12% of the on-demand price in AWS's own example. Whether it is cheaper overall depends on how many engineer-hours you currently spend on node images, autoscaling and add-on upgrades.

Should a startup use Kubernetes?

Usually not on day one. A startup with a few services on one cloud is better served by Cloud Run, ECS or a PaaS, and can move to managed Kubernetes when it needs portability, specialised scheduling or the ecosystem.

This quarter, if I were advising a team already on Kubernetes, I would do three things: check every cluster against the support calendar with the script above, budget the next two upgrades as real projects, and move any cluster without a dedicated owner onto an autopilot mode. If I were advising a team not yet on it, I would ask them to name which of the five needs above they actually have. Most of the time, the answer saves them a quarter.

Related: Kubernetes as the Agent Control Plane in 2026, Infrastructure as Code in 2026 and DevOps Still Matters in 2026.