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.
  • whenUnsatisfiableDoNotSchedule (hart: nicht planen) oder ScheduleAnyway (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.