Kubernetes Taints anzeigen: So geht's!

Einführung

Kubernetes, die beliebte Container-Orchestrierungsplattform, bietet eine leistungsstarke Funktion namens "Taints" (dt. "Markierungen") zur Steuerung der Planung von Pods auf Nodes. In diesem Tutorial werden wir untersuchen, wie man die auf Kubernetes-Nodes angewendeten Taints anzeigen kann, was eine wesentliche Fähigkeit für die effektive Verwaltung Ihres Kubernetes-Clusters ist.

Taints ermöglichen es Ihnen, Nodes mit spezifischen Attributen zu markieren, die bestimmte Pods abstoßen können, wodurch sichergestellt wird, dass Workloads basierend auf den Node-Fähigkeiten und -Ressourcen angemessen geplant werden. Das Verständnis, wie man mit Taints arbeitet und diese anzeigt, hilft Ihnen, eine optimale Ressourcenzuweisung in Ihrer Kubernetes-Umgebung aufrechtzuerhalten.

Einrichten einer Kubernetes-Umgebung für Tests

Bevor wir Taints auf Kubernetes-Nodes anzeigen können, benötigen wir eine funktionierende Kubernetes-Umgebung. Für dieses Tutorial verwenden wir Minikube, das einen leichten, lokalen Kubernetes-Cluster für Entwicklungs- und Testzwecke bereitstellt.

Beginnen wir mit der Installation von Minikube:

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
rm minikube-linux-amd64

Nachdem Minikube installiert ist, starten wir einen Kubernetes-Cluster:

minikube start --driver=docker

Sie sollten eine ähnliche Ausgabe wie diese sehen:

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Using the docker driver based on user configuration
📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.26.1 on Docker 23.0.1 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: default-storageclass, storage-provisioner
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Überprüfen wir, ob der Cluster läuft, indem wir den Node-Status überprüfen:

kubectl get nodes

Sie sollten eine ähnliche Ausgabe wie diese sehen:

NAME       STATUS   ROLES           AGE    VERSION
minikube   Ready    control-plane   1m     v1.26.1

Großartig! Wir haben jetzt eine funktionierende Kubernetes-Umgebung, um Taints zu erkunden. Der Befehl kubectl ist bereits so konfiguriert, dass er mit unserem Minikube-Cluster funktioniert.

Kubernetes Taints verstehen

Bevor wir beginnen, Taints anzuzeigen, wollen wir verstehen, was sie sind und wie sie in Kubernetes funktionieren.

Was sind Taints?

Taints sind Eigenschaften, die auf Kubernetes-Nodes angewendet werden und es einem Node ermöglichen, bestimmte Pods abzuwehren. Stellen Sie sich Taints als Labels vor, die Nodes als ungeeignet für bestimmte Arten von Workloads kennzeichnen.

Taints arbeiten zusammen mit einem Konzept namens "Tolerations" (dt. "Toleranzen"). Während Taints auf Nodes angewendet werden, werden Tolerations auf Pods angewendet. Ein Pod mit einer Toleration, die mit dem Taint eines Nodes übereinstimmt, kann auf diesem getainteten Node geplant werden.

Taint-Struktur

Taints bestehen aus drei Komponenten:

Key (Schlüssel): Eine Zeichenkette, die den Taint identifiziert (z. B. gpu, disk, network)
Value (Wert): Eine optionale Zeichenkette, die dem Schlüssel zugewiesen wird (z. B. true, high-performance)
Effect (Effekt): Definiert, wie Pods ohne passende Tolerations behandelt werden

Die gebräuchlichsten Taint-Effekte sind:

NoSchedule: Neue Pods ohne passende Tolerations werden nicht auf dem Node geplant
PreferNoSchedule: Das System wird versuchen, Pods ohne passende Tolerations nicht auf dem Node zu platzieren, aber es ist nicht garantiert
NoExecute: Neue Pods ohne passende Tolerations werden nicht auf dem Node geplant, und bestehende Pods ohne passende Tolerations werden entfernt

Hier ist die Syntax für einen Taint:

Mit einem Wert: key=value:effect
Ohne einen Wert: key:effect

Einige Nodes in einem Kubernetes-Cluster haben Standard-Taints. Beispielsweise werden Control-Plane-Nodes oft mit node-role.kubernetes.io/control-plane:NoSchedule getaintet, um zu verhindern, dass reguläre Workloads auf ihnen geplant werden, wodurch Ressourcen für Systemkomponenten erhalten bleiben.

Untersuchen wir unseren Minikube-Node, um zu sehen, ob er Standard-Taints hat:

kubectl describe node minikube | grep -A3 Taints

Sie werden wahrscheinlich eine ähnliche Ausgabe wie diese sehen:

Taints:             node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable:      false
Lease:
  HolderIdentity:  minikube

Diese Ausgabe zeigt, dass unser Minikube-Node einen Taint hat, der verhindert, dass reguläre Pods auf ihm geplant werden, da es sich um einen Control-Plane-Node handelt.

Taints auf Kubernetes-Nodes anzeigen

Nachdem wir verstanden haben, was Taints sind, wollen wir die verschiedenen Methoden zur Anzeige von Taints, die auf Kubernetes-Nodes angewendet werden, untersuchen.

Methode 1: Verwendung von kubectl describe

Der detaillierteste Weg, Taints auf einem Node anzuzeigen, ist die Verwendung des Befehls kubectl describe node:

kubectl describe node minikube

Dieser Befehl gibt umfassende Informationen über den Node aus. Um sich nur auf Taints zu konzentrieren, können Sie grep verwenden:

kubectl describe node minikube | grep -A1 Taints

Beispielausgabe:

Taints:             node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable:      false

Methode 2: Verwendung von kubectl get mit benutzerdefinierten Spalten

Sie können den Befehl kubectl get nodes mit benutzerdefinierten Ausgabespalten verwenden, um nur die Taints anzuzeigen:

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

Beispielausgabe:

NAME       TAINTS
minikube   [map[effect:NoSchedule key:node-role.kubernetes.io/control-plane]]

Methode 3: Verwendung von kubectl get mit JSONPath

Ein weiterer Ansatz ist die Verwendung von JSONPath, um Taint-Informationen zu extrahieren:

kubectl get nodes minikube -o jsonpath='{.spec.taints}'

Beispielausgabe:

[{"effect":"NoSchedule","key":"node-role.kubernetes.io/control-plane"}]

Für eine bessere Lesbarkeit können Sie die Ausgabe als JSON formatieren:

kubectl get nodes minikube -o jsonpath='{.spec.taints}' | jq .

Wenn Sie jq nicht installiert haben, können Sie es mit folgendem Befehl installieren:

sudo apt-get update && sudo apt-get install -y jq

Beispiel für eine formatierte Ausgabe:

[
  {
    "effect": "NoSchedule",
    "key": "node-role.kubernetes.io/control-plane"
  }
]

Methode 4: Verwendung von kubectl get mit YAML-Ausgabe

Sie können auch die vollständige Node-Spezifikation im YAML-Format anzeigen und nach Taints suchen:

kubectl get node minikube -o yaml | grep -A5 taints:

Beispielausgabe:

  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/control-plane
  unschedulable: false
status:
  addresses:

Jede dieser Methoden liefert die gleichen Informationen in unterschiedlichen Formaten. Wählen Sie diejenige, die Ihren Bedürfnissen am besten entspricht, basierend auf der Lesbarkeit und wie Sie die Informationen verwenden möchten.

Taints hinzufügen und entfernen

Nachdem wir wissen, wie man Taints anzeigt, wollen wir lernen, wie man sie hinzufügt und entfernt. Dies ist eine gängige Operation, wenn Sie die Pod-Planung steuern oder Nodes für die Wartung vorbereiten müssen.

Taints zu Nodes hinzufügen

Die Syntax zum Hinzufügen eines Taints zu einem Node lautet:

kubectl taint nodes <node-name> <key>=<value>:<effect>

Fügen wir unserem Minikube-Node einen Taint hinzu, um ihn als mit einer GPU versehen zu kennzeichnen:

kubectl taint nodes minikube gpu=true:NoSchedule

Sie sollten eine Ausgabe wie diese sehen:

node/minikube tainted

Überprüfen wir nun, ob der Taint hinzugefügt wurde:

kubectl describe node minikube | grep -A3 Taints

Beispielausgabe:

Taints:             gpu=true:NoSchedule
                    node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable:      false
Lease:

Wie Sie sehen können, hat unser Node jetzt zwei Taints: den ursprünglichen Control-Plane-Taint und unseren neuen GPU-Taint.

Taints von Nodes entfernen

Um einen Taint zu entfernen, fügen Sie ein Minuszeichen (-) an dieselbe Taint-Definition an:

kubectl taint nodes <node-name> <key>=<value>:<effect>-

Entfernen wir den GPU-Taint, den wir gerade hinzugefügt haben:

kubectl taint nodes minikube gpu=true:NoSchedule-

Sie sollten eine Ausgabe wie diese sehen:

node/minikube untainted

Überprüfen wir, ob der Taint entfernt wurde:

kubectl describe node minikube | grep -A3 Taints

Beispielausgabe:

Taints:             node-role.kubernetes.io/control-plane:NoSchedule
Unschedulable:      false
Lease:
  HolderIdentity:  minikube

Jetzt hat unser Node wieder nur den Control-Plane-Taint.

Wann Taints verwenden?

Taints sind in verschiedenen Szenarien besonders nützlich:

Spezialisierte Hardware: Tainting von Nodes mit spezieller Hardware (wie GPUs), um sicherzustellen, dass nur Workloads, die diese Hardware benötigen, dort geplant werden
Node-Wartung: Hinzufügen eines Taints, bevor die Wartung durchgeführt wird, um zu verhindern, dass neue Pods geplant werden
Sicherheitsisolation: Bestimmte Workloads aus Sicherheitsgründen von anderen getrennt halten
Ressourcenoptimierung: Nodes bestimmten Workload-Typen zuordnen, um eine optimale Ressourcenauslastung zu erzielen

Indem Sie verstehen, wie man Taints anzeigt, hinzufügt und entfernt, haben Sie grundlegendes Wissen für die Verwaltung der Pod-Planung in Ihrem Kubernetes-Cluster erworben.

Arbeiten mit Toleranzen

Nachdem wir verstanden haben, wie Taints funktionieren, wollen wir Toleranzen untersuchen – den Mechanismus, der es Pods ermöglicht, auf Nodes mit passenden Taints geplant zu werden.

Toleranzen verstehen

Toleranzen werden in Pod-Spezifikationen angegeben und ermöglichen es, Pods auf Nodes mit passenden Taints zu planen. Eine Toleranz besteht aus:

key: Passt zum Taint-Schlüssel
operator: Entweder Equal (gleicht Schlüssel und Wert ab) oder Exists (gleicht nur den Schlüssel ab)
value: Der abzugleichende Wert (bei Verwendung des Equal-Operators)
effect: Der abzugleichende Effekt, oder leer, um alle Effekte abzugleichen
tolerationSeconds: Optionale Dauer, für die der Pod auf einem Node mit einem passenden NoExecute-Taint verbleiben kann

Erstellen eines Pods mit Toleranzen

Erstellen wir einen Pod, der unseren Control-Plane-Taint toleriert. Erstellen wir zuerst eine YAML-Datei für unseren Pod:

nano ~/project/toleration-pod.yaml

Fügen Sie nun den folgenden Inhalt in die Datei ein:

apiVersion: v1
kind: Pod
metadata:
  name: toleration-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
  tolerations:
    - key: "node-role.kubernetes.io/control-plane"
      operator: "Exists"
      effect: "NoSchedule"

Diese Pod-Spezifikation enthält eine Toleranz, die mit dem Control-Plane-Taint auf unserem Node übereinstimmt. Speichern und beenden Sie die Datei (in nano drücken Sie Ctrl+O, Enter und dann Ctrl+X).

Erstellen wir nun den Pod:

kubectl apply -f ~/project/toleration-pod.yaml

Sie sollten eine Ausgabe wie diese sehen:

pod/toleration-pod created

Überprüfen wir, ob der Pod auf unserem Node geplant wurde:

kubectl get pods -o wide

Beispielausgabe:

NAME             READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
toleration-pod   1/1     Running   0          12s   10.244.0.5   minikube   <none>           <none>

Der Pod wird auf unserem Minikube-Node ausgeführt, da er eine Toleranz hat, die mit dem Control-Plane-Taint übereinstimmt.

Testen mit einem Pod ohne Toleranzen

Zum Vergleich erstellen wir einen Pod ohne Toleranzen:

nano ~/project/no-toleration-pod.yaml

Fügen Sie den folgenden Inhalt hinzu:

apiVersion: v1
kind: Pod
metadata:
  name: no-toleration-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest

Speichern und beenden Sie die Datei und erstellen Sie dann den Pod:

kubectl apply -f ~/project/no-toleration-pod.yaml

Überprüfen wir nun den Pod-Status:

kubectl get pods -o wide

Möglicherweise stellen Sie fest, dass der Pod im Status "Pending" verbleibt:

NAME               READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
no-toleration-pod  0/1     Pending   0          12s   <none>       <none>     <none>           <none>
toleration-pod     1/1     Running   0          2m    10.244.0.5   minikube   <none>           <none>

Überprüfen wir, warum der Pod aussteht:

kubectl describe pod no-toleration-pod

Im Abschnitt "Events" sollten Sie so etwas sehen:

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  45s   default-scheduler  0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.

Dies bestätigt, dass der Pod nicht geplant werden konnte, da er den Control-Plane-Taint nicht toleriert.

Bereinigung

Bereinigen wir die Pods, die wir erstellt haben:

kubectl delete pod toleration-pod no-toleration-pod

Sie sollten Folgendes sehen:

pod "toleration-pod" deleted
pod "no-toleration-pod" deleted

Herzlichen Glückwunsch! Sie verstehen jetzt, wie Taints und Toleranzen zusammenarbeiten, um die Pod-Planung in Kubernetes zu steuern.

Zusammenfassung

In diesem praktischen Lab haben Sie gelernt, wie man mit Kubernetes Taints und Toleranzen arbeitet, den Schlüsselfunktionen zur Steuerung der Pod-Planung in Ihrem Cluster. Folgendes haben Sie erreicht:

Einrichten einer Kubernetes-Umgebung mit Minikube
Verständnis des Konzepts von Taints und deren Auswirkungen auf die Pod-Planung
Erkundung verschiedener Methoden zur Anzeige von Taints auf Kubernetes-Nodes
Hinzufügen und Entfernen von Taints von Nodes mithilfe von kubectl-Befehlen
Erstellen von Pods mit und ohne Toleranzen, um zu sehen, wie sie mit getainteten Nodes interagieren

Diese Fähigkeiten sind unerlässlich für die Verwaltung der Workload-Platzierung und der Ressourcenzuweisung in Kubernetes-Clustern. Durch die korrekte Verwendung von Taints und Toleranzen können Sie sicherstellen, dass Pods auf geeigneten Nodes geplant werden, basierend auf Hardwareanforderungen, Workload-Eigenschaften und Ressourcenbeschränkungen.

Wenn Sie Ihre Kubernetes-Reise fortsetzen, können Sie auf diesem Wissen aufbauen, um anspruchsvollere Planungsstrategien wie Node-Affinität und Anti-Affinität zu implementieren, um Ihre Cluster-Ressourcen weiter zu optimieren.

So zeigen Sie die auf einen Kubernetes-Node angewendeten Taints an

Einführung

Einrichten einer Kubernetes-Umgebung für Tests

Kubernetes Taints verstehen

Was sind Taints?

Taint-Struktur

Taints auf Kubernetes-Nodes anzeigen

Methode 1: Verwendung von kubectl describe

Methode 2: Verwendung von kubectl get mit benutzerdefinierten Spalten

Methode 3: Verwendung von kubectl get mit JSONPath

Methode 4: Verwendung von kubectl get mit YAML-Ausgabe

Taints hinzufügen und entfernen

Taints zu Nodes hinzufügen

Taints von Nodes entfernen

Wann Taints verwenden?

Arbeiten mit Toleranzen

Toleranzen verstehen

Erstellen eines Pods mit Toleranzen

Testen mit einem Pod ohne Toleranzen

Bereinigung

Zusammenfassung