Kubernetes Pod Affinity: Pods gezielt zusammen platzieren – einfach erklärt

Mit der Pod Affinity (Pod-Affinität) legt Kubernetes fest, dass ein Pod in der Nähe bestimmter anderer Pods laufen soll. Die Regel steht im Feld spec.affinity.podAffinity und arbeitet mit den Labels der Ziel-Pods, die ein Kubernetes-Label-Selektor auswählt.

Harte und weiche Regeln

Pod-Affinität gibt es in zwei Ausprägungen:

• requiredDuringSchedulingIgnoredDuringExecution – die Bedingung muss beim Scheduling zwingend erfüllt sein, sonst bleibt der Pod Pending.
• preferredDuringSchedulingIgnoredDuringExecution – eine weiche Präferenz mit weight (1–100): Kubernetes versucht, sie zu erfüllen, findet aber auch einen anderen Platz.

Der Namensbestandteil „IgnoredDuringExecution“ bedeutet: Läuft ein Pod einmal, wird er nicht verschoben, wenn sich später Labels ändern.

Beispiel

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: redis-cache
        topologyKey: kubernetes.io/hostname

Dieses Beispiel platziert den Pod nur auf einem Node, auf dem bereits ein Pod mit dem Label app: redis-cache läuft. Der topologyKey bestimmt die Ebene: kubernetes.io/hostname bedeutet derselbe Node, topology.kubernetes.io/zone dieselbe Verfügbarkeitszone. Als Operatoren sind In, NotIn, Exists, DoesNotExist, Gt und Lt erlaubt.

Wofür ist Pod Affinity da?

Typische Anwendungsfälle sind latenzkritische Paare – etwa eine Anwendung, die auf demselben Node wie ihr Redis-Cache laufen soll – und Datenlokalität, wenn ein Pod nah an anderen Pods arbeiten muss. Die Abgrenzung zur Node-Affinität: Dort entscheiden Labels des Kubernetes-Nodes, bei der Pod-Affinität entscheiden Labels anderer Pods. Das Gegenstück ist die Pod-Anti-Affinität; die gleichmäßige Verteilung übernehmen Topology Spread Constraints. Verwaltet werden die Regeln wie alle Ressourcen mit kubectl.