k8wiz
Playground

Spread replicas across zones so one outage can't take them all

Intermediate · Kubernetes · about 12 min

checkout has 6 replicas, and all of them run on worker-1 in zone eu-west-1a. If that node or zone goes down, the shop can't take payments.

Loading the playground...

About this scenario

checkout has 6 replicas, and all of them run on worker-1 in zone eu-west-1a. If that node or zone goes down, the shop can't take payments.

The workers are in three zones: worker-1 in eu-west-1a, worker-2 in eu-west-1b, worker-3 in eu-west-1c. Make the scheduler keep the replicas balanced across zones, then simulate an outage with sim node stop.

Objectives

  1. See where the replicas run
  2. Spread checkout evenly over the three zones
  3. Stop a node and keep serving from the other zones
  4. checkout still asks for 6 replicas

What you'll practice

  • A nodeSelector or required node affinity left in a template quietly decides where every replica goes. Check kubectl get pods -o wide before you trust a Deployment to survive a node failure.
  • A topology spread constraint keeps the difference between the busiest and the emptiest zone at maxSkew or less. DoNotSchedule makes that a rule; ScheduleAnyway only a preference.
  • The selector counts every matching Pod, old ones included. matchLabelKeys: [pod-template-hash] spreads each rollout on its own.
  • A zone that's down still counts as a domain with zero Pods, so replacements under DoNotSchedule can stay Pending. nodeTaintsPolicy: Honor leaves out nodes the Pod can't tolerate.

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.