Mit Topology Spread Constraints verteilt Kubernetes die Pods eines Workloads gleichmäßig über Topologie-Domänen. Eine Domäne ist durch einen Label-Key definiert – typisch sind Nodes (kubernetes.io/hostname), Verfügbarkeitszonen (topology.kubernetes.io/zone) oder selbst gesetzte Labels wie rack. Die Regeln stehen im Feld spec.topologySpreadConstraints.
Die wichtigsten Felder
maxSkew– die maximal erlaubte Differenz der Pod-Anzahl zwischen zwei Domänen (Standard: 1).topologyKey– der Label-Key der Domänen-Ebene.whenUnsatisfiable–DoNotSchedule(hart: nicht planen) oderScheduleAnyway(weich: trotzdem planen und die Abweichung klein halten).labelSelector– wählt die Pods, die mitgezählt werden.
Beispiel
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: web-frontend
Dieses Beispiel stellt sicher, dass die Replikate möglichst gleichmäßig über die Zonen des Clusters verteilt werden – wichtig für Ausfallsicherheit und für Cluster, die mit mehreren Nodes und Zonen arbeiten. Beim automatischen Skalieren kann eine Regel nach dem Entfernen von Pods kurz verletzt sein; die Verteilung wird dann beim nächsten Scheduling wieder ausgeglichen.
Abgrenzung zu Affinitäten
Während die Pod-Affinität Pods anzieht und die Pod-Anti-Affinität sie gezielt trennt, gleichen Topology Spread Constraints die Verteilung über ganze Domänen aus. Sie ersetzen dadurch viele Anti-Affinitäts-Konstrukte und funktionieren auch mit Deployments, Services und dem kube-scheduler zusammen. Mehr zur Auswahl von Pods nach Labels steht im Artikel zum Kubernetes-Selector.