A new cluster must schedule 60000 pods. The only free allocation inside the corporate 10.0.0.0/8 is one /20, and the network team will not issue more. The platform team requires per-pod firewall rules and flow logs from the cloud provider's own networking. Which address strategy fits?
Show the full answer Hide the answer
The deciding property
The stem contains the constraint that settles it: per-pod firewall rules and provider flow logs. Those are properties of pods holding real addresses in the provider's network. Any design that hides pods behind an encapsulation layer trades them away, so the question becomes where the addresses come from, not whether pods get them.
The arithmetic
A /20 is 4096 addresses. Cloud providers reserve about five per subnet, and the range has to be cut across three availability zones, so roughly 1360 usable addresses per zone. 60000 pods needs a /16, and a rolling update that briefly doubles a deployment needs headroom on top, so realistically a /15.
The usual answer is to attach a secondary range from the shared address space in 100.64.0.0/10 (RFC 6598, reserved for carrier-grade NAT) to the VPC and allocate pods from it. That space is 4 million addresses, it is conventionally not routed on corporate networks, and it stays inside the provider's networking, so security groups and flow logs still apply to each pod. Node-level translation handles traffic leaving for on-premises.
Why the other options fail
- The overlay. Technically correct and widely used, and it gives up precisely what the stem demands. Encapsulation also costs MTU: a tunnel header shrinks the usable packet, and a path that silently drops oversized packets produces the signature where small requests succeed and large transfers hang.
- Two subnets in the /20. Subnets subdivide a range; they do not create addresses. 8192 was never available and 4096 is still 4096. This is the arithmetic error the question exists to catch.
- Fewer pods per node. Pod count is driven by the workload. Lowering density raises node count, and each node still needs its own addresses, so the pressure moves rather than falls.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| On-premises systems must reach individual pods | Real routable space, negotiated | Translation hides the pod identity the other side needs |
| Pod churn is low and density is modest | Prefix delegation on the primary range | Per-node blocks waste less than per-pod allocation |
| The security model is service-mesh identity rather than network rules | An overlay | The per-pod firewall requirement disappears |
When not to do this
If the fleet is a few thousand pods, ask for a bigger primary range and stop. Secondary ranges add a second address plan, a translation boundary and a class of confusing routing tickets. Carry that complexity only when the arithmetic says the simple allocation cannot work, which here it does by more than an order of magnitude.