All three major clouds sell managed Kubernetes and the differences are larger than the marketing suggests — particularly in what happens when you fall behind on versions and in how quickly you run out of IP addresses.

The asymmetry in that table is under-discussed. One provider gives away the control plane and charges only for an availability guarantee; another charges six times list to let you stay on an old version. Both are pricing decisions expressing a product opinion, and knowing them is worth real money at scale.

All three have moved toward the same model: instead of pre-declaring node groups and letting an autoscaler pick from them, a controller looks at the pending pods and provisions individual nodes shaped to fit them.

• Two of the three clouds now run the same open-source project for this, one as a managed mode and one as a managed add-on. The vocabulary is identical, which is unusually convenient for anyone moving between them.
• The third expresses it declaratively as an ordered list of preferences — try this machine family, then that one, then spot, then on-demand — with a policy for what to do when every option is exhausted. That is the cleanest expression of a fallback capacity strategy of the three, and it is worth knowing about even if you are not on that cloud.
• The advantage over group-based autoscaling is real: faster scale-up because it bypasses the scaling-group machinery, cheaper nodes because it picks the best fit rather than the nearest declared template, and active consolidation that repacks workloads onto fewer nodes.
• The failure mode to know: pod disruption budgets can block consolidation entirely. A workload with a restrictive budget prevents the controller from moving it, so expensive nodes persist and you pay for capacity the system wanted to reclaim.

There are three networking models and the choice determines your address plan permanently.

The flat model gives every pod a real, routable address from the same network as your other resources. Pods are directly reachable from peered networks and from on-premises, which is genuinely useful. The cost is that maximum pods per node becomes a property of the instance type rather than of Kubernetes: a mid-size instance with three network interfaces at ten addresses each tops out around 29 pods, with most of its CPU and memory unused.

The mitigation is prefix delegation — hand each interface slot a block of sixteen addresses instead of one, multiplying density roughly sixteenfold. It is also faster, because it makes far fewer control-plane calls when starting pods. Two cautions: it is close to a one-way door, since you cannot downgrade the networking plugin afterwards without replacing every node; and mixing prefix-enabled and non-prefix nodes produces inconsistent advertised capacity, so the clean path is new node groups rather than rolling existing ones.

The overlay model puts pods on a separate address range and translates on the way out. Address space stops being a constraint entirely — hundreds of pods per node become routine — and the trade is that pods are not directly reachable from peered networks. Communication is pod-initiated only. For most workloads that is fine; for anything where an on-premises system must call into a pod, it is disqualifying.

This is where the three genuinely differ in philosophy, and it is worth knowing before you choose, because it determines how much of your year is spent on upgrades.

The characters are clear. One is transactional: pay six times list to defer, then get upgraded without warning. One is opinionated: upgrades happen, exclusions are bounded, and you are on a channel. One is permissive in a way that creates false comfort — you keep running past end of support, which feels fine, and you have quietly stopped receiving security patches for Kubernetes components.

That third case is the one to name in an interview, because it is the failure that does not announce itself. A cluster that still works is not a cluster that is still supported, and the gap between those two is where a vulnerability lives.

• One provider only: genuinely serverless pods with no nodes at all; on-premises machines joining a cloud-hosted control plane; buying explicit control-plane scaling tiers; and version rollback within a week.
• Another only: a free control plane; long-term support as a purchasable tier; the richest networking matrix of the three; and unusually, an SLA on pod readiness rather than just on the API server — a novel guarantee shape.
• The third only: per-pod billing rather than per-node; declarative ordered capacity fallback with active migration to better node types as capacity frees; release channels as a first-class subscription; and a global network that makes multi-region clusters share one address space.