Infrastructure & Reliability · Reliability, operations & platforms · Chapter 18 of 33
Managed Kubernetes, and whether you should run it at all
Where the three providers genuinely differ, the pricing myth about the serverless tier, and the honest threshold for adopting any of it.
Comparisons of the managed offerings usually become feature tables, which are useless because the features converge. Four axes actually decide it.
Upgrade behaviour — the biggest real difference
| Model | In one line | |
|---|---|---|
| AWS | ~14 months standard support, then a further year at six times the control-plane price, then forced upgrade at 26 months | Bills you until you upgrade |
| Release channels — rapid, regular, stable, extended. It auto-upgrades; you control the maintenance window, not whether | Upgrades you | |
| Azure | Auto-upgrade channels, but opt-in rather than default | Lets you rot — which is why those fleets drift furthest behind |
The networking model, which is where portability actually breaks
- AWS gives every Pod a real VPC (Virtual Private Cloud) address from a network interface. Excellent for security groups and native routing; the failure mode is address exhaustion and per-instance Pod density limits, which is the single most common scaling surprise. Many mature teams replace the default plugin with Cilium.
- Google uses secondary ranges for Pods and Services, sized at cluster creation. The cleanest model of the three — and the trap is that the range is fixed at creation and undersizing it cannot be fixed in place.
- Azure historically offered a NAT-based mode that was cheap on addresses and awkward, and a VPC-native mode that was address-hungry. An overlay mode is now the sane default, and the trap is the legacy clusters still on the old path.
The pricing myth: the serverless tier does not remove the cluster fee.
It is widely repeated that Google's Autopilot mode has no cluster management charge. The per-cluster hourly fee applies to every cluster, Autopilot included. What confuses people is a monthly free-tier credit that usually covers one zonal or Autopilot cluster — and which does not apply to regional clusters.
The cost-shape difference that does matter is what you are billed for. Autopilot prices Pod resource requests; the others price nodes.
That changes your entire FinOps posture. Where you pay for requests, over-requesting is billed directly and right-sizing pays immediately. Where you pay for nodes, over-requesting shows up as low utilisation you have to go and find — which is why the tooling worth buying differs by provider.
One more shape to know: the fully-managed node modes impose constraints. One enforces a maximum node lifetime measured in weeks, which is good hygiene and a poor fit for anything that cannot be evicted — long training runs, for instance.
Is Kubernetes over-adopted?
Survey data puts production Kubernetes use among container users in the low eighties percent, up sharply over two years. Treat that number carefully: the survey publishes no sample size, no field dates and no methodology, and its respondents are self-selected from a cloud-native community. It measures penetration among people who answer cloud-native surveys.
More interesting is what the same survey says about difficulty: the top challenge is cultural change within the development team, ahead of training, security and complexity — and complexity ranked last of those four, with all four falling year on year. That cuts against the ‘everyone regrets it’ narrative.
The threshold is organisational, not technical
The question is not “how many services do we have?” It is “do we have, or will we fund, two engineers whose job is the platform?”
Industry sizing conventions put a platform engineer at roughly one per eight to twelve product engineers, with two to three as a minimum viable team. Fully loaded, the floor cost of “we run Kubernetes” is around two engineers before a single cloud bill. That is the number to compare against, and it is the one that never appears in the migration business case.
If you have that: Kubernetes is now the safest bet in infrastructure. Every vendor targets it, the hiring pool is deep, and recent releases are stability work rather than new surface area.
If you do not: a container platform — the managed serverless-container products from any major cloud — will beat it on every dimension you care about. The lock-in objection is weak, because you were never going to exercise the portability.
The one genuinely new argument for adopting it at smaller scale is accelerators. Dynamic Resource Allocation reached general availability in 2025 and there is no comparable open scheduling story for GPUs anywhere else. If you are doing serious inference or training, that changes the calculation.
And be honest about the evidence on the other side: the studies claiming most platform teams are drowning in Kubernetes complexity are commissioned by companies selling Kubernetes abstraction layers. They establish that it is hard. None of them attempts the counterfactual, and no independent data on who should not have adopted it appears to exist.
The strongest evidence of over-adoption is not a survey. It is that a component running in roughly half of all clusters was maintained by one or two people in their spare time until it had to be retired for safety. That is what an ecosystem looks like when consumption vastly outruns contribution — and it is a better answer to “what does running Kubernetes really involve?” than any adoption statistic.
Check yourself