Hochverfügbarkeit, die keine war

Wir hatten 3 Replicas auf 3 Nodes. Wir hielten uns für hochverfügbar. Waren wir nicht.

Das Setup:

• 3 Replicas pro Service
• 3 Kubernetes-Nodes
• Pod-Anti-Affinity: über Nodes verteilt — erledigt
• Alle Nodes: us-east-1a — der Teil, den niemand geprüft hat

Der Incident:

• Partieller Ausfall in AWS us-east-1a
• Alle 3 Nodes betroffen
• Alle Pods evicted
• Keine Kapazität in der Zone
• Kompletter Serviceausfall

Warum es passierte:

• Günstigere Instanzen in us-east-1a
• Der Auto-Provisioner stand per Default auf einer einzigen AZ
• Niemand prüfte die Node-Verteilung

Der Fix:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: my-service

Constraints auf Pod-Ebene helfen nur, wenn tatsächlich Nodes in mehreren Zonen existieren: Wir haben zusätzlich die Node Groups und den Cluster Autoscaler auf drei AZs umkonfiguriert, damit der Scheduler überhaupt etwas hatte, worauf er verteilen konnte. Zu prüfen, dass Redundanz auf jeder Ebene hält — Pod, Node, Zone — ist ein Standard-Checkpoint in unseren Cloud-Architektur-Reviews.

Lektion: Replicas ohne Zonenverteilung sind keine Hochverfügbarkeit.

---

Incidents wie dieser sind vermeidbar. Unser Team für AWS Managed Services überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.