Kubernetes Pod Anti-Affinity: Pods getrennt platzieren – einfach erklärt

Die Pod Anti-Affinity (Pod-Anti-Affinität) ist das Gegenstück zur Pod-Affinität: Sie hält einen Pod von Pods mit bestimmten Labels fern, statt ihn anzuziehen. Konfiguriert wird sie im Feld spec.affinity.podAntiAffinity mit derselben Syntax.

Replikate über Nodes verteilen

Der häufigste Einsatz ist Hochverfügbarkeit: Replikate einer Anwendung sollen nicht alle auf demselben Node oder in derselben Zone liegen, damit ein einzelner Ausfall nicht die gesamte Anwendung trifft.

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: web-frontend
          topologyKey: kubernetes.io/hostname

Mit topologyKey: kubernetes.io/hostname sorgt die Regel dafür, dass höchstens ein Replikat pro Node läuft; mit topology.kubernetes.io/zone wird auf Zonen-Ebene getrennt. Wie bei der Affinität unterscheidet Kubernetes zwischen der harten Variante requiredDuringSchedulingIgnoredDuringExecution und der weichen preferredDuringSchedulingIgnoredDuringExecution mit weight.

Vorsicht bei harten Regeln

Eine required-Anti-Affinität kann Pods dauerhaft im Zustand Pending lassen, wenn nicht genügend Nodes oder Zonen vorhanden sind. Bewährt ist sie etwa für Stateful-Dienste wie Datenbanken, die ihre Knoten auf verschiedene Nodes verteilen müssen – ein Muster, das auch DaemonSets und ReplicaSets betrifft. Wer eine gleichmäßige Verteilung über mehrere Domänen braucht, nutzt besser Topology Spread Constraints; die Anbindung an Labels beschreibt der Kubernetes-Selector. Grundlagen liefert der Artikel über Kubernetes.