Node-Selektoren und Affinität

Standardmäßig plant Kubernetes Pods auf jedem verfügbaren Node ein. Was aber, wenn Sie mehr Kontrolle benötigen?

Manchmal müssen Pods auf bestimmten Nodes ausgeführt werden. Vielleicht verfügen diese Nodes über spezielle Hardware oder Lizenzen oder befinden sich in bestimmten Verfügbarkeitszonen.

In dieser Lektion erfahren Sie, wie Sie den Scheduler von Kubernetes mithilfe von Node Selectors und Node Affinity steuern.

Stellen Sie sich vor, Sie haben einen Datenbank-Pod, der auf einem Node mit leistungsstarken SSDs ausgeführt werden muss, oder eine GPU-intensive Anwendung, die spezielle Hardware benötigt.

Vielleicht möchten Sie bestimmte Pods aus Gründen der Fehlertoleranz voneinander getrennt halten oder sicherstellen, dass sie auf Nodes mit bestimmten Betriebssystemen ausgeführt werden.

Kubernetes stellt Werkzeuge bereit, mit denen Sie solche Planungspräferenzen ausdrücken können.

Bevor wir Pods an bestimmte Orte schicken können, benötigen Nodes Identitäten! Kubernetes verwendet Labels, um Nodes anhand ihrer Eigenschaften zu identifizieren.

• Labels sind Schlüssel-Wert-Paare wie disk=ssd oder gpu=true.
• Sie können Ihren Nodes mithilfe von kubectl label nodes <node-name> <key>=<value> benutzerdefinierte Labels hinzufügen.
• Anhand dieser Labels wählen wir bestimmte Nodes für die Platzierung von Pods aus.

Die einfachste Möglichkeit, einen Pod auf eine bestimmte Gruppe von Nodes zu beschränken, ist die Verwendung von nodeSelector.

Dieses Feld in der Spezifikation Ihres Pods enthält eine Zuordnung von Schlüssel-Wert-Paaren. Der Pod wird nur auf Nodes eingeplant, die alle diese Labels besitzen.

Das ist, als würden Sie sagen: „Ich benötige einen Node, der genau diese Eigenschaften hat.“

Nehmen wir an, unsere Nodes sind mit disk=ssd gekennzeichnet. So lassen Sie einen Pod nur auf diesen Nodes ausführen:

nodeSelector ist zwar unkompliziert, aber sehr strikt. Was ist, wenn Sie „bevorzugte“ Nodes oder komplexere Regeln für die Übereinstimmung benötigen?

Node Affinity bietet mehr Flexibilität. Damit können Sie „weiche“ oder „harte“ Anforderungen formulieren, damit Pods auf Nodes mit bestimmten Labels platziert werden.

Dafür wird eine leistungsfähigere Syntax mit Operatoren wie In, NotIn, Exists, DoesNotExist, Gt und Lt verwendet.

Node Affinity gibt es in zwei Hauptformen:

• requiredDuringSchedulingIgnoredDuringExecution: Der Pod muss auf einem Node eingeplant werden, der die Regeln erfüllt. Wenn kein solcher Node existiert, wird der Pod nicht eingeplant.
• preferredDuringSchedulingIgnoredDuringExecution: Der Scheduler versucht, einen Node zu finden, der die Regeln erfüllt. Wenn kein solcher Node verfügbar ist, wird der Pod trotzdem an anderer Stelle eingeplant. Dies ist ein „Best Effort“-Ansatz.

Hier ist ein Pod, der einen Node mit dem Label env=production voraussetzt. Wenn kein solcher Node existiert, bleibt der Pod im Status „Pending“.

Was ist, wenn Sie Pods danach einplanen möchten, wo andere Pods ausgeführt werden?

• Pod Affinity: Zieht Pods zu Nodes, auf denen andere Pods mit bestimmten Labels bereits ausgeführt werden. Das ist nützlich, um Dienste gemeinsam zu platzieren, die häufig miteinander kommunizieren.
• Pod Anti-affinity: Hält Pods von Nodes fern, auf denen andere Pods mit bestimmten Labels ausgeführt werden. Das eignet sich hervorragend, um Replikate für eine hohe Verfügbarkeit über mehrere Nodes zu verteilen.

Dieses Manifest stellt sicher, dass keine zwei Pods mit dem Label app=my-web auf demselben Node eingeplant werden können. Das verbessert die Fehlertoleranz.

Der topologyKey legt den Bereich fest, für den die Anti-affinity gilt (z. B. Node oder Zone).

Sie möchten sicherstellen, dass Ihre kritischen Datenbank-Pods nicht auf Nodes mit dem Label zone=dev eingeplant werden. Welche Art von Planungsregel würden Sie für diesen strikten Ausschluss anhand von Node-Labels verwenden?

Sehr gut! Sie haben leistungsfähige Möglichkeiten kennengelernt, zu steuern, wo Ihre Pods ausgeführt werden:

• Node Labels: Schlüssel-Wert-Paare zur Identifizierung von Node-Eigenschaften.
• Node Selectors: Einfache, strikte Übereinstimmung, um Pods auf Nodes mit bestimmten Labels einzuplanen.
• Node Affinity: Flexiblere Regeln (erforderlich oder bevorzugt) für die Auswahl von Nodes mithilfe von Operatoren.
• Pod Affinity/Anti-affinity: Gemeinsame Platzierung oder Trennung von Pods anhand der Standorte anderer Pods.

Diese Werkzeuge sind entscheidend, um die Ressourcennutzung zu optimieren, Fehlertoleranz sicherzustellen und bestimmte Anforderungen von Anwendungen zu erfüllen.