Cluster Design — Architect Track›06 · Cluster networking

Lesson 06 of 13 · Architecture

Cluster networking

Produce ParcelPath's IP address plan: node, pod and service ranges for every cluster that never overlap with each other or the corporate network, per-node pod blocks, CNI routing mode (overlay vs native/BGP), MTU, DNS and default-deny network policy.

Architect
Key wordsIPAM plannode subnetspod CIDRservice CIDRnode CIDR masknon-overlapping rangesoverlay vs native routingBGPdual-stackMTUdefault-deny

The IPAM plan

ParcelPath's corporate network uses 10.0.0.0/12 (10.0.0.0–10.15.255.255) for offices, 10.16.0.0/12 (10.16.0.0–10.31.255.255) for data-centre server networks, and VPN users get 172.16.0.0/16. Kubernetes gets its own block: 10.64.0.0/10 (10.64.0.0–10.127.255.255), carved per cluster:

Cluster Node subnet (VLAN) Pod CIDR Service CIDR LB/VIP pool
prod-a 10.20.10.0/24 10.64.0.0/16 10.96.0.0/20 10.20.11.0/26
prod-b 10.30.10.0/24 10.65.0.0/16 10.96.16.0/20 10.30.11.0/26
nonprod 10.30.20.0/24 10.66.0.0/16 10.96.32.0/20 10.30.21.0/26
mgmt 10.30.30.0/26 10.67.0.0/18 10.96.48.0/22 10.30.31.0/28
reserved — 10.68.0.0/14 … 10.96.64.0/18 … —

(Node subnets and VIP pools come from the data-centre server range 10.16.0.0/12: 10.20.x in DC-A, 10.30.x in DC-B.)

An IP plan is like house numbers for a whole city planned before building. Each neighbourhood (cluster) gets its own range of numbers, so two houses never share an address, and the post office (routers) always knows where to deliver. Renumbering a city after people move in is a nightmare, so you plan it once, with room to grow.

Checking the math

  • Pod CIDR /16, /24 per node → 256 node blocks; each /24 has 256 addresses for ≤ 110 pods (default max pods), leaving room for churn. ParcelPath's 18-month maximum is ~25 nodes per cluster: plenty.
  • Service CIDR /20 → 4,096 ClusterIPs per cluster; ParcelPath will have a few hundred Services. (Many clusters use /16 or /12 by default; smaller ranges are fine if planned.)
  • VIP pool /26 → 64 addresses for the API VIP and LoadBalancer Services per cluster.
  • Your CNI's IPAM may allocate differently: Calico hands out /26 blocks by default (borrowing more as needed); Cilium's cluster-pool mode uses a per-node mask (default /24). Align the plan with the CNI's settings.

Routing mode

Overlay (VXLAN/Geneve) Native routing + BGP
Setup Self-contained Peer nodes with ToR switches (network team)
Overhead ~50 bytes per packet; MTU lower None
Pod IPs reachable from DC No (SNAT at nodes) Yes (if advertised)
Troubleshooting Encapsulation layer Plain routing

ParcelPath decision (ADR-003): native routing with BGP in production (performance, and the network team is on board), overlay in nonprod for simplicity. Both use Cilium (eBPF dataplane, network policy, observability); see Networking Deep Dive, lesson 05.

MTU, DNS, IPv6

  • MTU: 9000 (jumbo) on the DC fabric if every hop supports it; otherwise 1500 with overlay MTU reduced accordingly. Test end to end (see Networking Deep Dive, lesson 01).
  • DNS: CoreDNS with NodeLocal DNSCache for latency and resilience; forwarders to corporate DNS for internal names.
  • IPv6/dual-stack: plan ranges now even if enabled later; ParcelPath defers (recorded as a consequence in the ADR).

Default-deny network policy

Start every application namespace with deny all ingress and allow only what's needed; egress restrictions for sensitive namespaces (payments/orders). Policies are part of each service's deployment, reviewed like code.

Try it: plan and verify

  1. Extend the table with a future prod-c cluster and a new DC without overlapping anything.
  2. Use ipcalc or Python's ipaddress module to verify no ranges overlap (a 10-line script is a good CI check).
  3. Create a kind cluster with custom podSubnet and serviceSubnet in its config and verify pod/Service IPs.
  4. Install Cilium in a lab with native routing (or overlay) and check cilium status and the pod CIDR per node.
  5. Write ADR-003 (routing mode) with consequences for troubleshooting and the network team.

Going deeper: networks that last

  • Keep the IPAM plan in Git as data (YAML), with a CI check for overlaps; generate cluster configs from it.
  • Leave large reserved ranges for future clusters and sites; IP space regret is common.
  • For multi-cluster service discovery or mesh (see Service Mesh — Istio & Linkerd), unique CIDRs are a prerequisite.

Recap

  • One global IPAM plan: node, pod, service and VIP ranges per cluster, never overlapping each other or corporate/VPN ranges, with reserves.
  • Check the math: nodes per pod CIDR, Services per service CIDR, CNI allocation block sizes.
  • Choose overlay vs native/BGP per environment and record it.
  • Plan MTU, DNS and IPv6; start with default-deny policies.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.