Eviction bedeutet in Kubernetes, dass ein Pod kontrolliert beendet und von seinem Controller (etwa einem Deployment oder ReplicaSet) neu gestartet wird. Die Eviction API ist der saubere Weg, eine solche Beendigung anzustoßen: Sie prüft vorher, ob dadurch Verfügbarkeitsregeln verletzt würden.
Zwei Wege zur Eviction
Es gibt zwei Auslöser. API-initiiert fordert jemand (Mensch oder Werkzeug) die Eviction eines bestimmten Pods an. Node-Pressure-Eviction übernimmt das Kubelet selbst, wenn auf einem Knoten Ressourcen knapp werden.
So funktioniert die API-Eviction
Der Aufrufer sendet ein Eviction-Objekt (API-Gruppe policy/v1) an die eviction-Subresource des Pods. Das kube-apiserver prüft dann, ob ein PodDisruptionBudget (PDB) für den Pod existiert. Würde die Eviction das Budget verletzen, antwortet die API mit HTTP 429 Too Many Requests, und der Aufrufer muss es später erneut versuchen.
Genau deshalb nutzt kubectl für kubectl drain die Eviction API statt eines direkten Löschens: Der Descheduler und Wartungswerkzeuge bleiben so im Rahmen der Budgets.
Node-Pressure-Eviction
Das Kubelet überwacht Eviction-Signale wie memory.available, nodefs.available, imagefs.available und Inodes. Es kennt zwei Schwellenarten: evictionHard (Eviction sofort) und evictionSoft (Eviction erst nach einer Grace Period). Die Messwerte stammen aus den cgroup-Statistiken des Knotens.
Welche Pods zuerst dran sind, bestimmt eine Rangfolge: zuerst Pods, die über ihren Request verbrauchen, dann nach PriorityClass, zuletzt nach aktuellem Verbrauch. Dabei gilt die Reihenfolge der QoS-Klassen: BestEffort vor Burstable vor Guaranteed.
Abgrenzung
Eviction ist nicht OOM-Kill (der Linux-Kernel beendet Prozesse) und nicht Preemption (der Scheduler verdrängt Pods zugunsten höherpriorer Workloads). Die Eviction API ist der geordnete, vorhersehbare Weg, den auch Taints mit NoExecute nutzen: Sie stößt Pods über eine Eviction ab, wenn keine passende Toleration existiert.
Verwandte Grundlagen: Kubernetes Node, Kubelet, Descheduler.