Kubernetes Tolerations: Beispiele, Use Cases und Best Practices

Kubernetes Taint-Effekte

Werfen wir einen Blick auf die Taint-Effekte, die Kubernetes bietet und die sich mit Tolerations außer Kraft setzen lassen.

NoSchedule

Der Effekt NoSchedule verhindert, dass neue Pods ohne passende Toleration auf einem Node eingeplant werden. Pods, die beim Hinzufügen des Taints bereits auf dem Node laufen, werden nicht entfernt. Damit eignet sich NoSchedule, um Nodes für bestimmte Workloads zu reservieren, ohne bestehende Pods zu beeinträchtigen.

Das Hinzufügen eines Taints hardware=gpu:NoSchedule verhindert beispielsweise, dass Pods ohne passende Toleration neu auf dem GPU-Node eingeplant werden. Dort bereits laufende Pods können weiterlaufen.

PreferNoSchedule

Der Effekt PreferNoSchedule ist eine weiche Scheduling-Einschränkung. Kubernetes versucht, Pods ohne passende Toleration nicht auf dem Node mit Taint zu platzieren, kann sie dort bei Bedarf aber trotzdem einplanen. Anders als NoSchedule blockiert er das Scheduling nicht strikt.

Dieser Effekt ist nützlich, wenn Administratoren Nodes bevorzugt für bestimmte Workloads reservieren möchten, der Scheduler diese Nodes aber dennoch nutzen soll, wenn andere Platzierungsoptionen begrenzt sind. Bestehende Pods werden beim Hinzufügen eines PreferNoSchedule-Taints nicht entfernt.

NoExecute

Der Effekt NoExecute wirkt sich sowohl auf das Scheduling als auch auf bereits laufende Pods aus. Neue Pods ohne passende Toleration können dort nicht eingeplant werden, während bestehende Pods, die den Taint nicht tolerieren, entfernt werden.

Eine Toleration kann tolerationSeconds enthalten, damit ein Pod nach dem Auftreten eines passenden NoExecute-Taints vorübergehend auf dem Node bleiben darf. Nach Ablauf dieser Frist wird der Pod entfernt, sofern der Taint weiterhin besteht. Wird tolerationSeconds weggelassen, darf der Pod mit passender Toleration bleiben, solange der Taint vorhanden ist.

Beispiele für Kubernetes Tolerations

Beispiel 1: Einfache NoSchedule-Toleration

Angenommen, ein Node hat den Taint workload=analytics:NoSchedule. Ein Pod benötigt eine passende Toleration, um für das Scheduling auf diesem Node infrage zu kommen. Der folgende Pod toleriert genau diesen Taint:

apiVersion: v1
kind: Pod
metadata:
  name: analytics-pod
spec:
  containers:
    - name: web
      image: nginx:latest
  tolerations:
    - key: "workload"
      operator: "Equal"
      value: "analytics"
      effect: "NoSchedule"

Der Equal-Operator verlangt, dass sowohl key als auch value mit dem Taint übereinstimmen. Diese Toleration erlaubt dem Pod das Scheduling auf Nodes mit dem angegebenen Taint, verpflichtet den Scheduler aber nicht, den Pod auf einem dieser Nodes zu platzieren.

Beispiel 2: Beliebige Values eines Taints tolerieren

Der Exists-Operator kommt zum Einsatz, wenn ein Pod einen Taint-Key unabhängig von dessen Value tolerieren soll. Die folgende Konfiguration toleriert beispielsweise jeden NoSchedule-Taint mit dem Key workload:

apiVersion: v1
kind: Pod
metadata:
  name: compute-pod
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "workload"
      operator: "Exists"
      effect: "NoSchedule"

Bei Exists wird kein Value angegeben. Dieser Pod kann daher Taints wie workload=database:NoSchedule und workload=batch:NoSchedule tolerieren. Andere Taint-Keys oder Effects erfordern weiterhin eigene passende Tolerations.

Beispiel 3: NoExecute mit tolerationSeconds

Eine NoExecute-Toleration kann tolerationSeconds enthalten, um zu steuern, wie lange ein Pod nach dem Setzen eines passenden Taints auf einem Node verbleibt. Der folgende Pod toleriert einen Taint maintenance-window=active:NoExecute für 100 Sekunden:

apiVersion: v1
kind: Pod
metadata:
  name: maintenance-worker
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "maintenance-window"
      operator: "Equal"
      value: "active"
      effect: "NoExecute"
      tolerationSeconds: 100

Wird der Taint hinzugefügt, während der Pod läuft, darf der Pod bis zu 100 Sekunden auf dem Node bleiben. Besteht der Taint nach Ablauf dieser Frist weiterhin, entfernt Kubernetes den Pod. Wird der Taint vorher entfernt, kann der Pod weiterlaufen.

Best Practices für Kubernetes Tolerations

Tolerations nur für Workloads einsetzen, die sie benötigen

Fügen Sie Tolerations nur hinzu, wenn es für einen Workload einen klaren Grund gibt, auf Nodes mit Taints zu laufen. Breit gefasste oder unnötige Tolerations schwächen die Isolation, die Taints eigentlich bieten sollen, und können Workloads auf Nodes zulassen, die für andere Zwecke reserviert sind. Das kann zu Ressourcenkonflikten führen und die Node-Platzierung weniger vorhersehbar machen.

Überprüfen Sie Tolerations, wenn sich die Anforderungen der Workloads ändern. Vermeiden Sie generische Exists-Tolerations, sofern der Pod nicht tatsächlich eine große Bandbreite an Taints tolerieren muss. Bevorzugen Sie eng gefasste Keys, Values und Effects, damit jeder Workload nur die Scheduling-Berechtigungen erhält, die er benötigt.

Es empfiehlt sich außerdem, Tolerations auf Ebene des Workload-Controllers zu verwalten, etwa in einem Deployment, StatefulSet oder DaemonSet. So bleibt das Scheduling-Verhalten konsistent, wenn Pods neu erstellt oder skaliert werden.

Tolerations mit Node Affinity kombinieren

Eine Toleration macht einen Pod lediglich für Nodes mit Taints zulässig, lenkt ihn aber nicht dorthin. Soll ein Workload gezielt auf einem bestimmten Node-Pool laufen, kombinieren Sie Tolerations mit Node Affinity oder Node-Selektoren.

Ein GPU-Workload kann beispielsweise den Taint der GPU-Nodes tolerieren und gleichzeitig per Node Affinity Nodes mit dem passenden GPU-Typ-Label verlangen. Der Taint hält gewöhnliche Workloads fern, während die Affinity den GPU-Workload zu kompatiblen Nodes lenkt.

Wählen Sie zwischen Required- und Preferred-Node-Affinity, je nachdem, wie strikt die Platzierung sein muss. Required Affinity verhindert das Scheduling auf nicht passenden Nodes, während Preferred Affinity dem Scheduler mehr Flexibilität lässt, wenn keine geeigneten Nodes verfügbar sind.

Taints und Tolerations über Node-Pools hinweg konsistent halten

Verwenden Sie ein einheitliches Namensschema für Taint-Keys und -Values über alle Node-Pools hinweg. Inkonsistente Werte wie workload=gpu, type=gpu und node=gpu für denselben Zweck erschweren die Pflege der Pod-Konfigurationen und erhöhen das Risiko von Scheduling-Fehlern.

Definieren Sie Standard-Taints für gängige Node-Rollen und wenden Sie sie über Cluster- oder Infrastruktur-Automatisierung an. Workload-Manifeste können dann über Development, Staging und Produktion hinweg vorhersehbare Tolerations verwenden – ohne unnötige Konfigurationsunterschiede.

Konsistenz ist besonders wichtig, wenn Nodes automatisch von Cluster-Autoscaling-Systemen erstellt oder ersetzt werden. Neue Nodes sollten bereits beim Provisioning die erwarteten Taints und Labels erhalten, damit sich Workloads unabhängig von der jeweiligen Node-Instanz gleich verhalten.

Spezialisierte und teure Nodes schützen

Nutzen Sie Taints, um zu verhindern, dass allgemeine Pods spezialisierte Ressourcen wie GPUs, Instanzen mit viel Arbeitsspeicher oder andere teure Hardware belegen. Nur Workloads, die für diese Ressourcen ausgelegt sind, sollten die entsprechenden Tolerations erhalten.

Tolerations allein stellen nicht sicher, dass ein Pod die spezialisierte Ressource tatsächlich anfordert. Konfigurieren Sie für GPU-Workloads beispielsweise neben der Toleration auch die passenden Resource Requests oder Limits. Node Affinity bietet zusätzliche Kontrolle über die Platzierung, wenn mehrere Hardware-Typen verfügbar sind.

Dieser Ansatz verhindert, dass Workloads mit niedriger Priorität Kapazitäten belegen, die spezialisierte Anwendungen benötigen. Er kann zudem die Infrastrukturkosten senken, indem teure Nodes für Workloads verfügbar bleiben, die von ihrer Hardware profitieren.

Scheduling-Ergebnisse überwachen – nicht nur die Konfiguration

Eine gültige Toleration garantiert nicht, dass ein Pod erfolgreich eingeplant wird. Ressourcenverfügbarkeit, Node Affinity, Topologie-Beschränkungen, Pod Affinity und Anti-Affinity sowie andere Scheduler-Regeln können die Platzierung weiterhin verhindern.

Überwachen Sie Pods im Status Pending, Scheduler-Events, Node-Taints und die tatsächliche Pod-Platzierung, um zu überprüfen, ob sich die Scheduling-Richtlinien wie beabsichtigt verhalten. Befehle wie kubectl describe pod und kubectl describe node helfen dabei, Taint-Unstimmigkeiten und andere Scheduling-Beschränkungen zu identifizieren.

Das Monitoring sollte auch unerwartete Platzierungen erkennen – nicht nur Pods, die im Status Pending verbleiben. Ein Workload, der erfolgreich auf dem falschen Node-Pool läuft, kann auf zu breit gefasste Tolerations oder fehlende Affinity-Regeln hindeuten. Regelmäßige Prüfungen stellen sicher, dass die Scheduling-Richtlinien auch bei Veränderungen im Cluster und bei den Workloads weiterhin funktionieren.

FAQ

Was ist eine Kubernetes Toleration? Eine Toleration ist eine Einstellung in der Spezifikation eines Pods, die es dem Pod erlaubt, auf Nodes mit passenden Taints eingeplant zu werden. Sie erlaubt das Scheduling lediglich. Sie garantiert nicht, dass der Pod auf einem Node mit Taint landet, da Ressourcenanforderungen und Node Affinity weiterhin gelten.

Was ist der Unterschied zwischen einem Taint und einer Toleration? Taints werden auf Nodes angewendet und halten Pods fern, die keine passende Toleration haben. Tolerations werden auf Pods angewendet und erlauben das Scheduling auf Nodes mit passenden Taints, erzwingen es aber nicht.

Was ist der Unterschied zwischen den Operatoren Equal und Exists? Equal verlangt, dass Key, Value und Effect der Toleration mit dem Taint übereinstimmen, und ist der Standard, wenn kein Operator gesetzt ist. Exists gleicht nur anhand des Keys ab – der Value muss weggelassen werden – und toleriert jeden Value für diesen Key.

Was bewirken die Effekte NoSchedule, PreferNoSchedule und NoExecute? NoSchedule blockiert neue Pods ohne passende Toleration, lässt laufende Pods aber unangetastet. PreferNoSchedule ist eine weiche Variante, bei der der Scheduler versucht, den Node zu meiden. NoExecute entfernt zusätzlich laufende Pods, die den Taint nicht tolerieren.

Was bewirkt tolerationSeconds? Bei einer NoExecute-Toleration legt tolerationSeconds fest, wie lange ein Pod nach dem Auftreten eines passenden Taints auf einem Node bleiben darf. Ist diese Zeit abgelaufen und der Taint besteht weiterhin, entfernt Kubernetes den Pod. Wird der Wert weggelassen, bleibt der Pod, solange der Taint vorhanden ist.

Sorgt eine Toleration dafür, dass ein Pod auf einem Node mit Taint läuft? Nein. Eine Toleration macht den Pod lediglich für solche Nodes zulässig. Um einen Pod gezielt auf einen bestimmten Node-Pool zu lenken, kombinieren Sie die Toleration mit Node Affinity oder einem Node-Selektor.

Toleration-basiertes Scheduling mit PerfectScale effizienter machen

Taints und Tolerations entscheiden, wo Pods laufen dürfen – sie sagen aber nichts darüber aus, ob diese Nodes richtig dimensioniert sind oder ob die dort landenden Workloads die passende Menge an CPU und Arbeitsspeicher anfordern. PerfectScale ist eine Plattform für Kubernetes-Optimierung und -Governance, die sich mit einem einzigen Helm-Befehl bereitstellen lässt und anschließend umsetzbare Erkenntnisse sowie autonome Optimierung über den gesamten K8s-Stack liefert – Workloads, Nodes und Autoscaler –, damit reservierte, spezialisierte und teure Node-Pools tatsächlich effizient genutzt werden.

Die wichtigsten Funktionen von PerfectScale:

• Autonomes Workload-Right-Sizing: Podfit bietet einen granularen Blick auf Zustand und Kosten des Clusters, deckt verschwendete Ressourcen und Resilienzprobleme auf und optimiert Workloads autonom mit datenbasierten Right-Sizing-Empfehlungen, die sich automatisieren lassen.
• Auslastungs-Insights auf Node-Ebene: Infrafit macht ungenutzte Node-Kapazität sichtbar und empfiehlt die richtigen Node-Typen für Ihre Workloads – so liefern dedizierte, GPU- und andere Node-Pools mit Taints Spitzenleistung, ohne dass Sie für ungenutzte Kapazität zahlen.
• Autoscaler-Optimierung: PerfectScale lässt sich mit HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning und Google Autopilot integrieren und maximiert so die Effektivität der Systeme, die Ihre Nodes mit Taints bereitstellen und ersetzen.
• Echtzeit-Alerts mit automatischer Priorisierung: Resilienzrisiken und Kostenanomalien werden nach Auswirkung priorisiert und direkt an Slack, Datadog, MS Teams oder PagerDuty gemeldet – bevor sie Ihre Nutzer oder Ihre Cloud-Rechnung erreichen.
• Trends, Governance und Prognosen: Der Trends-Report bietet detaillierte Einblicke in Kosten-, Waste- und Risikometriken im Zeitverlauf – über Cluster, Node-Gruppen, Namespaces und Workloads hinweg – und unterstützt Root-Cause-Analysen sowie eine präzise Budgetplanung.
• Jede Kubernetes-Umgebung: PerfectScale läuft sowohl auf On-Premise- als auch auf Cloud-Clustern, einschließlich OpenShift, EKS, GKE, AKS und hybriden Setups, und unterstützt Windows-Container sowie kurzlebige oder ML-Workloads wie Airflow- und Spark-Jobs.

Erfahren Sie mehr über die PerfectScale-Plattform