Pod Evicted: Node-Druck, nicht das Container-Limit

TL;DR

Evicted heißt: das Kubelet hat den Pod vom Node geworfen, weil dem Node eine Ressource ausgegangen ist. Die Meldung steht am Pod:

kubectl describe pod POD

The node was low on resource: ephemeral-storage ist Disk, inklusive emptyDir und Container-Schreibschicht. memory ist Node-RAM, nicht das Limit des Containers. Limit-Überschreitung eines einzelnen Containers ist OOMKilled, Exit 137. Die Status-Übersicht: Pod startet nicht.

Was evicted wird, und was nicht

Das Kubelet räumt ab, wenn eine Eviction-Schwelle reißt: verfügbarer Speicher, nodefs.available, imagefs.available, Inodes. Es wählt Pods, die über ihrem Request liegen, und Pods ohne Request zuerst. Der Pod geht auf Failed, Reason Evicted. Ein Deployment baut ein neues Replica. Landet das auf demselben vollen Node, fliegt es wieder.

kubectl get pods -A --field-selector=status.phase=Failed
kubectl describe node NODE | sed -n '/Conditions/,/Addresses/p'

DiskPressure oder MemoryPressure True am Node ist die Bestätigung. Der Pod-Text sagt, welche Ressource. Beides zusammen lesen, nicht nur den Pod löschen.

ephemeral-storage ist meist die Platte

Logs, leere Verzeichnisse und das beschreibbare Layer des Containers zählen auf ephemeral-storage, nicht auf ein PVC. Eine Anwendung, die nach /tmp oder in ein emptyDir ohne SizeLimit schreibt, füllt nodefs. Das PVC der Datenbank kann dabei noch Luft haben.

resources:
  requests:
    ephemeral-storage: 1Gi
  limits:
    ephemeral-storage: 2Gi

Das Limit hält diesen Pod, bevor er den Node füllt. Es ersetzt nicht das Aufräumen: alte Images (crictl rmi über die Runtime des Nodes), gestorbene Logs, emptyDirs ohne Grenze. Auf dem Node zeigt df -h /var/lib/kubelet und df -h /var/lib/containerd, welches Dateisystem voll ist. Die Pfade hängen von der Distribution ab. describe node nennt Allocated gegen die Kapazität, nicht den freien Block.

Memory-Eviction ist nicht OOMKilled

OOMKilled tötet einen Container, der sein eigenes Limit reißt. Der Pod kann neu starten und wieder in den CrashLoop laufen. Eviction wegen Memory entfernt den ganzen Pod, weil der Node unter der Schwelle liegt. Andere Pods auf dem Node sind mitbetroffen, auch welche, die ihr Limit einhalten.

Wer nur das Limit des evicted Pods anhebt, verschiebt den Druck. Wer den Request an den echten Verbrauch anpasst, gibt dem Scheduler die Information, diesen Pod nicht auf einen schon vollen Node zu legen. Danach Pod Pending, wenn kein Node die Reservierung mehr hat. Das ist der ehrliche Zustand.

Der Ersatz muss woanders landen

Solange DiskPressure auf dem Node steht, soll der Scheduler ihn meiden. Tut er das nicht, fehlt die Condition oder sie ist veraltet. Pods von diesem Node nehmen: Workload verschieben, Druck lösen, dann zurück. Evicted-Pods im Status Failed bleiben als Leichen liegen, bis Sie sie löschen oder das Limit des ReplicaSet sie ersetzt. Sie verbrauchen keinen Speicher mehr. Sie verwirren die Liste.

Quellen

• Node-Pressure Eviction
• Ephemeral-Storage für Container