PerfectScale

Der ultimative Guide zu Node Affinity: Beispiele, Use Cases & Profi-Tipps

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Aug 30, 202612 min read

About Josh Palmer

Head of Content

I'm Josh Palmer, Head of Content at DoiT, where I split my time across multiple business units including DoiT Cloud Intelligence, PerfectScale (Kubernetes cost optimization), and SELECT (Snowflake, Databricks, and BigQuery cost optimization). Before DoiT, I spent four and a half years at OnBoard building content for a board intelligence platform used by 6,000+ organizations, and before that, two years as Content Marketing Manager at Zylo, a SaaS management platform.

My personal page

TLDR: Node Affinity legt anhand von Node-Labels fest, auf welchen Nodes ein Pod ausgeführt werden darf – über harte (requiredDuringSchedulingIgnoredDuringExecution) oder weiche (preferredDuringSchedulingIgnoredDuringExecution) Regeln. Sie ist ausdrucksstärker als nodeSelector und wird häufig eingesetzt, um GPU-/SSD-Nodes gezielt anzusteuern, Workloads in einer bestimmten Zone zu halten oder Produktions- von Entwicklungsumgebungen zu trennen. Standardisieren Sie Ihre Node-Labels, bevorzugen Sie weiche Regeln, sofern die Platzierung nicht zwingend erforderlich ist, und stimmen Sie Affinity-Regeln mit Autoscaling und Workload-Sizing ab, damit Pods nicht im Status Pending hängen bleiben.

In diesem Artikel:

So funktioniert Node Affinity in Kubernetes
Node-Affinity-YAML-Syntax: Harte vs. weiche Regeln
Typische Use Cases für Node Affinity
Node Affinity vs. Node Selector vs. Pod Affinity
Profi-Tipps für den effektiven Einsatz von Node Affinity

Was ist Node Affinity in Kubernetes?

Node Affinity ist in Kubernetes ein Regelwerk, das anhand von Node-Labels einschränkt, auf welchen Nodes ein Pod eingeplant werden kann. Es ermöglicht eine deutlich ausdrucksstärkere und komplexere Scheduling-Logik als nodeSelector und unterstützt sowohl weiche als auch harte Regeln, um Pods gezielt auf entsprechend gelabelter Hardware wie SSDs oder GPUs zu platzieren.

Besonders nützlich ist diese Funktion in mandantenfähigen, hybriden oder heterogenen Kubernetes-Clustern, in denen Workloads unterschiedliche Hardware- oder Standortanforderungen haben können. Mit Node Affinity optimieren Sie die Ressourcenauslastung, isolieren sensible Workloads und verbessern die Anwendungsperformance, indem Sie Workloads den Nodes mit den passendsten Eigenschaften zuordnen.

Die wichtigsten Arten von Node Affinity:

Harte Regeln (requiredDuringSchedulingIgnoredDuringExecution): Der Scheduler muss einen passenden Node finden, um den Pod zu platzieren; andernfalls bleibt dieser im Status Pending.
Weiche Regeln (preferredDuringSchedulingIgnoredDuringExecution): Der Scheduler versucht, einen passenden Node zu finden; ist keiner verfügbar, wird der Pod dennoch anderswo eingeplant.

Beispiel (YAML):

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd

Dieser Artikel ist Teil einer Serie über Kubernetes-Scheduling.

So funktioniert Node Affinity in Kubernetes

Hier sind die wichtigsten technischen Bausteine hinter Node Affinity.

Node-Labels

Node-Labels sind Schlüssel-Wert-Paare, die Kubernetes-Nodes zugewiesen werden, um deren Eigenschaften zu beschreiben. Labels sind frei wählbar und können Merkmale wie Instanztyp, Region, Availability Zone oder benutzerdefinierte Metadaten abbilden, die für das Workload-Scheduling relevant sind. Beispielsweise können Sie Nodes mit disktype=ssd oder gpu=true labeln, um Nodes mit SSD-Speicher oder GPU-Beschleunigung zu kennzeichnen.

Labels werden von Cluster-Administratoren oder Automatisierungsskripten gesetzt – entweder beim Hinzufügen von Nodes zum Cluster oder dynamisch bei Infrastrukturänderungen. Eine konsistente und aussagekräftige Labeling-Strategie ist entscheidend für effektive Node Affinity, denn Affinity-Regeln stützen sich auf diese Labels, um geeignete Nodes für die Pod-Platzierung auszuwählen. Sauberes Labeling stellt sicher, dass der Scheduler Ihre Platzierungsrichtlinien korrekt interpretieren und durchsetzen kann.

Node-Affinity-Operatoren

Node-Affinity-Regeln nutzen Operatoren, um festzulegen, wie Pods mit Node-Labels abgeglichen werden. Die gängigsten Operatoren sind In, NotIn, Exists und DoesNotExist. Mit In und NotIn definieren Sie zulässige oder unzulässige Werte für ein bestimmtes Label, während Exists und DoesNotExist prüfen, ob ein Label-Schlüssel vorhanden ist oder fehlt – unabhängig von seinem Wert.

Diese Operatoren bieten die nötige Flexibilität, um komplexe Scheduling-Anforderungen auszudrücken. So können Sie beispielsweise festlegen, dass Pods nur auf Nodes mit environment=production laufen, oder Nodes mit dedicated=backup meiden. Durch die Kombination verschiedener Operatoren und Label-Selektoren lässt sich die Pod-Platzierung exakt auf Workload-Anforderungen und Unternehmensrichtlinien abstimmen.

Verhalten des Schedulers

Der Kubernetes-Scheduler wertet Node-Affinity-Regeln aus, wenn er entscheidet, wo ein Pod platziert wird. Dabei gleicht er die Labels der verfügbaren Nodes mit den Affinity-Kriterien in der Pod-Spezifikation ab. Erfüllt ein Node die erforderlichen Affinity-Regeln, kommt er für das Scheduling des Pods infrage; andernfalls wird der Pod so lange nicht eingeplant, bis ein passender Node verfügbar ist.

Es gibt zwei Arten von Node Affinity: required (hart) und preferred (weich). Harte Regeln müssen erfüllt sein, damit der Pod eingeplant wird, während weiche Regeln die Entscheidung des Schedulers beeinflussen, das Scheduling aber nicht verhindern, wenn keine bevorzugten Nodes verfügbar sind. Diese Unterscheidung ermöglicht sowohl strikte als auch flexible Platzierungsstrategien und bringt betriebliche Anforderungen mit der Ressourcenverfügbarkeit in Einklang.

Node-Affinity-YAML-Syntax: Harte vs. weiche Regeln

1. RequiredDuringSchedulingIgnoredDuringExecution

requiredDuringSchedulingIgnoredDuringExecution definiert harte Affinity-Regeln, die erfüllt sein müssen, bevor ein Pod auf einem Node eingeplant werden kann. Der Scheduler berücksichtigt nur Nodes, deren Labels allen angegebenen Bedingungen entsprechen. Ist kein passender Node verfügbar, verbleibt der Pod im Status Pending, bis ein geeigneter Node verfügbar wird.

Diese Art von Affinity kommt häufig bei Workloads mit strikten Infrastrukturanforderungen zum Einsatz. Eine Machine-Learning-Anwendung benötigt beispielsweise Nodes mit GPUs, oder ein compliance-kritischer Workload darf nur in einer bestimmten Region oder Availability Zone laufen.

Der Zusatz IgnoredDuringExecution bedeutet, dass Kubernetes den Pod nicht vom Node entfernt, wenn sich Node-Labels nach dem Scheduling ändern. Wird ein Node-Label später entfernt oder geändert, läuft der Pod weiter auf diesem Node, sofern kein anderer Mechanismus ein Rescheduling auslöst.

Codebeispiel:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: disktype
              operator: In
              values:
                - ssd

In diesem Beispiel kann der Pod nur auf Nodes mit dem Label disktype=ssd laufen.

2. PreferredDuringSchedulingIgnoredDuringExecution

preferredDuringSchedulingIgnoredDuringExecution definiert weiche Affinity-Regeln, die Scheduling-Entscheidungen beeinflussen, ohne verpflichtend zu sein. Der Scheduler versucht, Pods auf Nodes zu platzieren, die den bevorzugten Bedingungen entsprechen, kann den Pod bei Bedarf aber auch auf anderen Nodes einplanen.

Weiche Affinity-Regeln arbeiten mit einem Gewichtungssystem. Jeder Präferenz wird ein Gewicht zwischen 1 und 100 zugewiesen. Nodes, die höher gewichtete Präferenzen erfüllen, erhalten beim Scheduling eine höhere Punktzahl und werden dadurch mit größerer Wahrscheinlichkeit ausgewählt.

Dieser Ansatz eignet sich, wenn Platzierungspräferenzen die Performance oder Kosteneffizienz verbessern, aber nicht zwingend erforderlich sind. Beispielsweise können Sie Workloads bevorzugt auf SSD-basierten Nodes oder in einer bestimmten Zone laufen lassen, um die Latenz zu reduzieren, und bei Ressourcenengpässen dennoch andere Nodes zulassen.

Codebeispiel:

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 50
        preference:
          matchExpressions:
            - key: disktype
              operator: In
              values:
                - ssd

In diesem Beispiel bevorzugt Kubernetes Nodes mit dem Label disktype=ssd, der Pod kann aber auch auf anderen Nodes laufen, wenn keine SSD-basierten Nodes verfügbar sind.

Typische Use Cases für Node Affinity

GPU-Workloads auf GPU-Nodes ausführen

Node Affinity kommt zum Einsatz, wenn GPU-Workloads in einem Kubernetes-Cluster ausgeführt werden. Indem Sie GPU-fähige Nodes mit einem Schlüssel wie gpu=true labeln, stellen Sie sicher, dass Pods mit GPU-Bedarf nur auf kompatibler Hardware eingeplant werden. Das verhindert Ressourcenkonkurrenz bei GPU-abhängigen Workloads.

Weiche Affinity kann genutzt werden, wenn in unkritischen Szenarien ein Ausweichen auf CPU-Nodes akzeptabel ist.

Datenbanken auf SSD-Nodes einplanen

Datenbanken benötigen oft eine hohe I/O-Performance, die SSD-basierte Nodes liefern können. Indem Sie Nodes mit disktype=ssd labeln und für Datenbank-Pods eine harte Node Affinity festlegen, sichern Sie hohe Speicherperformance und niedrigere Latenz für zustandsbehaftete Workloads.

Sobald neue SSD-Nodes hinzugefügt und gelabelt werden, kommen sie für das Scheduling der Datenbank-Pods infrage.

Workloads in einer bestimmten Availability Zone halten

Das Ausführen von Workloads in einer bestimmten Availability Zone kann die Latenz senken, die Fehlertoleranz verbessern oder regulatorische Anforderungen erfüllen. Indem Sie Nodes mit einer Zonenkennung wie zone=us-west1-b labeln und Node Affinity in den Pod-Spezifikationen festlegen, steuern Sie die Verteilung der Pods über Zonen hinweg.

Mit einer weichen Affinity lenken Sie den Scheduler in die gewünschte Zone, erlauben aber bei knappen Ressourcen das Ausweichen auf andere Zonen.

Produktions- und Entwicklungs-Workloads trennen

Die Trennung von Produktions- und Entwicklungsumgebungen in einem gemeinsam genutzten Cluster ist ein klassischer Use Case für Node Affinity. Indem Sie Nodes als env=prod oder env=dev labeln, setzen Sie Platzierungsrichtlinien durch, die verhindern, dass Entwicklungs-Workloads auf Produktions-Nodes laufen – und umgekehrt.

Mit harter Node Affinity erzwingen Sie eine strikte Trennung, während weiche Affinity in Situationen mit knappen Ressourcen Flexibilität erlaubt.

Node Affinity vs. Node Selector vs. Pod Affinity

Node Affinity, Node Selectors und Pod Affinity sind allesamt Scheduling-Mechanismen in Kubernetes, lösen aber unterschiedliche Platzierungsprobleme und bieten unterschiedliche Grade an Flexibilität.

Ein Node Selector ist die einfachste Option. Er erlaubt einem Pod, nur auf Nodes mit bestimmten Labels zu laufen. Die Konfiguration ist unkompliziert und nutzt exakte Schlüssel-Wert-Übereinstimmungen wie disktype=ssd. Allerdings unterstützt nodeSelector nur einfache Gleichheitsprüfungen und kann komplexere Bedingungen wie mehrere Werte oder Ausschlussregeln nicht abbilden.

Node Affinity erweitert die Möglichkeiten von nodeSelector durch fortgeschrittene Matching-Operatoren wie In, NotIn, Exists und DoesNotExist. Sie unterstützt außerdem sowohl required- als auch preferred-Scheduling-Regeln und gibt Administratoren mehr Kontrolle über die Pod-Platzierung. Node Affinity wird typischerweise eingesetzt, wenn Workloads gezielt auf Nodes mit bestimmter Hardware, in bestimmten Regionen oder mit bestimmten Betriebsrollen laufen müssen.

Pod Affinity funktioniert anders, da sie sich auf Beziehungen zwischen Pods statt auf Node-Labels konzentriert. Sie ermöglicht es, Pods in der Nähe anderer Pods mit bestimmten Labels einzuplanen – üblicherweise auf demselben Node oder in derselben Availability Zone. Das ist nützlich, um die Netzwerklatenz zwischen eng gekoppelten Services zu reduzieren. Kubernetes unterstützt zudem Pod Anti-Affinity, die Pods gezielt verteilt, um Verfügbarkeit und Fehlertoleranz zu verbessern.

Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen:

Merkmal	Node Selector	Node Affinity	Pod Affinity
Ziel	Node-Labels	Node-Labels	Andere Pods
Komplexität	Einfach	Fortgeschritten	Fortgeschritten
Unterstützte Operatoren	Nur Gleichheit	Mehrere Operatoren	Label-Selektoren
Harte und weiche Regeln	Nein	Ja	Ja
Haupteinsatzgebiet	Einfache Node-Auswahl	Flexible Node-Platzierung	Pods gemeinsam platzieren oder trennen

Profi-Tipps für den effektiven Einsatz von Node Affinity

1. Node-Labels standardisieren, bevor Sie Affinity-Regeln schreiben

Node Affinity basiert auf Node-Labels – inkonsistentes Labeling kann daher zu Scheduling-Fehlern oder unvorhersehbarer Pod-Platzierung führen. Definieren Sie eine klare Labeling-Strategie, bevor Sie Affinity-Richtlinien erstellen. Verwenden Sie einheitliche Namenskonventionen für Labels wie Umgebung, Hardware-Typ, Region, Workload-Rolle oder Storage-Klasse.

Standardisieren Sie beispielsweise auf Labels wie env=prod, disktype=ssd oder workload=batch. Vermeiden Sie mehrere Labels für dasselbe Konzept, etwa gpu=true und accelerator=gpu.

Automatisieren Sie das Label-Management, wo immer möglich. Cloud-Anbieter und Cluster-Provisionierungstools unterstützen oft automatisches Labeling für Instanztypen, Zonen und Node-Pools. Automatisierung reduziert manuelle Konfigurationsfehler und stellt sicher, dass neue Nodes mit bestehenden Affinity-Richtlinien kompatibel sind.

2. Weiche Regeln bevorzugen, sofern die Platzierung nicht zwingend ist

Harte Affinity-Regeln können dazu führen, dass Workloads nicht mehr eingeplant werden können, wenn keine passenden Nodes verfügbar sind. Ein übermäßiger Einsatz von requiredDuringSchedulingIgnoredDuringExecution kann die Flexibilität des Clusters bei Skalierungsereignissen, Wartungsfenstern oder Node-Ausfällen einschränken.

Weiche Affinity-Regeln sorgen für ein robusteres Scheduling-Verhalten. Sie erlauben es Kubernetes, ideale Nodes zu priorisieren und Workloads bei Bedarf dennoch anderswo zu platzieren.

Setzen Sie harte Affinity nur ein, wenn die Platzierung zwingend erforderlich ist – etwa bei GPU-abhängigen Anwendungen, Workloads mit Lizenzbeschränkungen, compliance-kritischen Systemen oder Anwendungen, die bestimmte Hardware-Features benötigen.

3. Node Affinity mit dem Node-Autoscaling abstimmen

Node Affinity sollte auf die Autoscaling-Richtlinien des Clusters abgestimmt sein. Benötigen Workloads Nodes mit bestimmten Labels, muss der Autoscaler passende Node-Gruppen bereitstellen können. Andernfalls bleiben Pods womöglich im Status Pending hängen, obwohl Autoscaling aktiviert ist.

GPU-Workloads sollten beispielsweise auf Node-Pools mit dedizierten GPU-Instanzen abzielen, während speicherintensive Workloads zu SSD-basierten Node-Gruppen passen sollten.

Prüfen Sie, ob die Limits des Autoscalers das erwartete Workload-Wachstum abdecken. Kann der Autoscaler aufgrund von Quota-Limits oder Konfigurationseinschränkungen keine zusätzlichen passenden Nodes erstellen, können Affinity-Regeln Deployments blockieren.

4. Affinity mit Workload-Right-Sizing kombinieren

Node Affinity entfaltet ihre volle Wirkung erst bei richtig dimensionierten Workloads. Überdimensionierte CPU- oder Memory-Requests können die Scheduling-Optionen einschränken, selbst wenn geeignete Nodes den Affinity-Regeln entsprechen.

Ein Pod mit strikten Affinity-Anforderungen und überhöhten Memory-Requests wird beispielsweise womöglich nicht eingeplant, obwohl passende Nodes existieren.

Überprüfen Sie Ressourcen-Requests und -Limits der Workloads zusammen mit den Affinity-Richtlinien. Monitoring-Tools und Kubernetes-Metriken helfen dabei, Workloads zu identifizieren, die dauerhaft weniger Ressourcen verbrauchen als angefordert.

5. Affinity-Richtlinien regelmäßig überprüfen, wenn sich Workloads weiterentwickeln

Infrastruktur- und Anwendungsanforderungen ändern sich im Laufe der Zeit – Node-Affinity-Richtlinien sollten daher regelmäßig überprüft werden. Einst sinnvolle Labels können nach Cluster-Upgrades, Migrationen oder Architekturänderungen veraltet sein.

Regelmäßige Reviews helfen, unnötige Einschränkungen, ungenutzte Labels oder Scheduling-Richtlinien zu identifizieren, die die Cluster-Effizienz mindern.

In operative Reviews sollten sowohl Plattform- als auch Anwendungsteams eingebunden werden, um sicherzustellen, dass Affinity-Regeln weiterhin den Workload-Anforderungen entsprechen, ohne das Scheduling unnötig zu verkomplizieren.

Node-Platzierung und Ressourceneffizienz mit PerfectScale optimieren

Node Affinity gibt Ihnen die Kontrolle darüber, wo Workloads laufen – doch selbst optimal platzierte Pods können Kapazität verschwenden oder unnötiges Node-Scaling auslösen, wenn ihre Ressourcen-Requests und -Limits nicht stimmen. Überprovisionierte Container zwingen den Autoscaler, mehr Nodes als nötig hochzufahren, unterprovisionierte Container verursachen OOM-Kills und Evictions auf genau den Nodes, die Ihre Affinity-Regeln sorgfältig ausgewählt haben, und ineffizientes Bin-Packing lässt gelabelte Nodes ungenutzt. PerfectScale steigert die Kubernetes-Effizienz durch autonomes Right-Sizing von Workloads und tiefe Transparenz auf Node-Ebene – damit Ihre Affinity-Richtlinien Pods auf Nodes platzieren, die bereits für maximale Effizienz konfiguriert sind.

Die wichtigsten Funktionen von PerfectScale:

Autonomes Workload-Right-Sizing: Analysiert Workloads kontinuierlich und passt CPU- und Memory-Requests und -Limits auf Basis der tatsächlichen Nutzung an, damit über Affinity-Regeln eingeplante Pods ihre Ressourcen effizient nutzen.
Transparenz und Optimierung auf Node-Ebene: Bietet einen ganzheitlichen Überblick über Ihre Nodes und Node-Pools, validiert Node Affinities und Taints anhand tatsächlicher Workload-Scheduling-Muster und hilft Ihnen, für jeden Workload den optimalen Node-Typ auszuwählen.
Proaktive Konfigurationskorrekturen: Identifiziert Konfigurationsfehler – etwa CPU Request Not Set, Memory Request Not Set und Memory Limit Not Set –, die zu Evictions, Node-Überbelegung und ineffizientem Scheduling auf Ihren sorgfältig gelabelten Nodes führen.
Effizientes Autoscaling: Optimiert Workload-Konfigurationen, damit Autoscaler wie Karpenter und der Cluster Autoscaler die richtigen Node-Typen und -Größen bereitstellen – so bleibt die Affinity-gesteuerte Platzierung vorhersehbar und kosteneffizient.

Sie möchten sicherstellen, dass Ihr Affinity-gesteuertes Scheduling auf effizienten, richtig dimensionierten Nodes landet? Erfahren Sie mehr über PerfectScale.

FAQ

Was ist der Unterschied zwischen harter und weicher Node Affinity? Harte Regeln (requiredDuringSchedulingIgnoredDuringExecution) müssen erfüllt sein, sonst bleibt der Pod im Status Pending. Weiche Regeln (preferredDuringSchedulingIgnoredDuringExecution) sind eine Präferenz – der Scheduler versucht, sie zu berücksichtigen, platziert den Pod bei Bedarf aber anderswo.

Worin unterscheidet sich Node Affinity von nodeSelector? nodeSelector unterstützt nur einfache Label-Regeln mit exakter Übereinstimmung. Node Affinity unterstützt umfangreichere Operatoren (In, NotIn, Exists, DoesNotExist) sowie sowohl required- als auch preferred-Scheduling-Logik.

Worin unterscheidet sich Node Affinity von Pod Affinity? Node Affinity gleicht Pods mit Node-Labels ab. Pod Affinity (und Anti-Affinity) gleicht Pods mit der Platzierung anderer Pods ab – typischerweise, um zusammengehörige Workloads gemeinsam zu platzieren oder gezielt zu verteilen.

Warum hängt mein Pod trotz gesetzter Node Affinity im Status Pending? Meist, weil kein Node einer harten (required) Regel entspricht – prüfen Sie die Node-Labels, stellen Sie sicher, dass der Autoscaler passende Nodes bereitstellen kann, und vergewissern Sie sich, dass die Ressourcen-Requests des Pods für die passenden Nodes nicht überdimensioniert sind.

Wann sollte ich harte statt weicher Regeln verwenden? Nur wenn die Platzierung wirklich zwingend erforderlich ist – bei GPU-abhängigen Workloads, Lizenzbeschränkungen oder Compliance-/Datenresidenz-Anforderungen. Ansonsten sind weiche Regeln vorzuziehen, um das Scheduling flexibel zu halten.

Wirkt sich das Ändern von Node-Labels auf bereits laufende Pods aus? Nein. Da die Regeln "IgnoredDuringExecution" sind, wird ein laufender Pod nicht vom Node entfernt, wenn sich die Labels des Nodes nach dem Scheduling ändern.