About this scenario
inventory runs one replica on each worker. Zone eu-west-1a has two workers, worker-1 and worker-4; eu-west-1b and eu-west-1c have one each. The client Pod on worker-1 calls the inventory Service, and kube-proxy spreads those calls over every replica, so half of them leave the zone.
A Service's trafficDistribution asks kube-proxy to prefer close endpoints. In Kubernetes 1.35 it gained PreferSameNode, and the older PreferClose was renamed PreferSameZone. Try both.
Objectives
- Measure where client's calls land
- Keep the calls in client's zone with PreferSameZone
- Keep them on client's node with PreferSameNode
- Find the hints kube-proxy follows in the EndpointSlice
What you'll practice
- By default kube-proxy spreads a Service's traffic over every ready endpoint, wherever it runs.
trafficDistribution: PreferSameZone keeps traffic in the caller's zone, and PreferSameNode (new in 1.35) on the caller's node. Both fall back to other endpoints when none are close: they're preferences, not rules.- The EndpointSlice controller writes the preference as hints on each endpoint,
forZones and forNodes, and kube-proxy on each node follows them. PreferClose still works as the old name of PreferSameZone. Keep enough replicas per zone: preferring close endpoints sends a zone's whole load to its local replicas.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.