Kubernetes Node-Placement & Taints — nodeSelector, Pod Anti-Affinity und Toleration auf dem Multi-Node-Cluster

In diesem 90-Minuten-Modul verlasst ihr den Single-Node-Minikube-Kreis der bisherigen Module und schedult zum ersten Mal gezielt auf einem echten Multi-Node-Cluster. Los geht es mit der Einordnung, welches der drei Werkzeuge zu welchem Anwendungsfall passt: nodeSelector als starres “Alles-oder-Nichts”-Matching auf Node-Labels, Node Affinity mit einer harten Bedingung (requiredDuringSchedulingIgnoredDuringExecution, Must-Have) und einer weichen Präferenz ( preferredDuringSchedulingIgnoredDuringExecution, Nice-to-Have), und Pod-(Anti-)Affinity, die sich nicht an Node-Eigenschaften, sondern an anderen Pods orientiert. Im ersten Hands-on vergebt ihr per kubectl label nodes ein Label an einen Worker-Node eures k3d-Clusters, schedult einen Pod per nodeSelector exakt dorthin und lasst einen zweiten Pod per podAntiAffinity mit topologyKey: kubernetes.io/hostname automatisch auf den Node ausweichen, auf dem noch kein Pod mit demselben Label läuft – verifiziert live per kubectl get pods -o wide. Danach wechselt die Perspektive von Anziehung zu Abweisung: die drei Taint-Effekte NoSchedule, PreferNoSchedule und NoExecute. Im zweiten Hands-on durchlauft ihr den vollständigen Positivzyklus, den viele Teams nur aus der Theorie kennen: einen Node per kubectl taint versehen, einen Pod mit passender Toleration trotzdem erfolgreich dort laufen lassen, den Taint anschließend wieder entfernen und alle angelegten Objekte aufräumen. Voraussetzung ist das abgeschlossene Modul “Kubernetes Pod-Fundamentals” (Labels sind bereits bekannt) sowie k3d-Grundvertrautheit aus “Kubernetes Fortgeschritten — k3d Multi-Node, OpenLens & Ingress” – ausdrücklich nicht die Module “Kubernetes Administration” oder “Kubernetes Hochverfügbarkeit”. Die komplette Session läuft vollständig lokal über k3d, ohne Cloud-Account und ohne Kostenwirkung.