Kubernetes Failure-Domain-Scheduling — Topology Spread Constraints & Pod Anti-Affinity

Dieses 100-Minuten-Modul schließt eine Lücke, die zwei Vorgängermodule dieses Repos jeweils ausdrücklich als Ausblick ohne eigenen Kurs benannt haben: “Kubernetes Administration” und “Kubernetes Hochverfügbarkeit — Multi-Master Control-Plane” nennen beide die Verteilung von Worker-Nodes über Failure-Domains als offenen Punkt, ohne ihn selbst zu vertiefen. Ihr startet mit der Einordnung, die im Ernstfall den Unterschied macht: Kubernetes plant Pods nicht automatisch failure-domain-bewusst – ohne explizite Konfiguration kann der Scheduler sechs Replicas einer Anwendung problemlos alle in derselben Verfügbarkeitszone platzieren, und der Ausfall genau dieser einen Zone reißt dann die komplette Anwendung mit. Im ersten Hands-on vergebt ihr topology.kubernetes.io/zone -Labels an die drei Nodes eures kind-Clusters – und wir sagen von Anfang an ehrlich: Das sind simulierte Zonen, keine physisch getrennten Rechenzentren. Alle Nodes laufen als Docker-Container auf demselben Host; die Labels lösen dasselbe Scheduling-Verhalten aus wie echte Cloud-AZs, aber keine echte physische Redundanz. Im zweiten, größten Hands-on konfiguriert ihr topologySpreadConstraints mit maxSkew und vergleicht live, was der Unterschied zwischen whenUnsatisfiable: DoNotSchedule (hart, neue Pods bleiben Pending, bis der Skew wieder passt) und ScheduleAnyway (weich, der Scheduler platziert trotzdem, auch wenn der Skew dabei wächst) am eigenen Cluster tatsächlich bedeutet – inklusive einer bewusst provozierten ungleichen Verteilung, die ihr anschließend korrigiert. Im dritten Hands-on stellt ihr Pod-Anti-Affinity daneben: den älteren, binären Mechanismus (“niemals zwei Pods in derselben Zone”), der keine Skew-Feinsteuerung kennt, dafür aber Fälle abdeckt, in denen Topology Spread Constraints allein nicht reichen. Den Abschluss bildet ein bewusster Ausblick ohne eigenes Hands-on: wie ein Cluster-Autoscaler auf Pending-Pods durch Skew-Verletzungen reagiert, und was sich an echten Cloud-AZs gegenüber unseren simulierten Labels unterscheidet. Voraussetzung sind beide Module “Kubernetes Administration” und “Kubernetes Hochverfügbarkeit — Multi-Master Control-Plane” gleichzeitig. Die Session läuft weiterhin vollständig lokal über kind, ohne Cloud-Account und ohne Kostenwirkung.