Node NotReady: Kubelet, CNI, Pressure

TL;DR

NotReady heißt: die Control Plane hat zu lange kein gesundes Lebenszeichen von diesem Node. Neue Pods sollen dort nicht landen. Laufende Pods werden nach der Grace-Zeit evicted oder hängen. Zuerst die Bedingungen, nicht ein einzelnes Deployment:

kubectl describe node NODE
kubectl get nodes

Unter Conditions: Ready False, plus der Grund. KubeletNotReady und ein Text wie container runtime is down oder cni plugin not initialized. MemoryPressure und DiskPressure sind voll, nicht tot. Pods, die deshalb gehen: Pod Evicted. Übersicht, wenn nur ein Pod klemmt: Pod startet nicht.

Ready kommt vom Kubelet

Der Node bleibt Ready, solange das Kubelet die Node-Lease erneuert und seine Conditions meldet. Stoppt das Kubelet, wird Ready nach node-monitor-grace-period (Default 40 Sekunden, in der Praxis oft etwa eine Minute bis der Status kippt) False. Der Node ist dann noch in der Liste. Er ist nur nicht benutzbar.

Auf dem Node selbst: systemctl status kubelet und der Journal. Häufig stirbt das Kubelet, weil die Container-Runtime nicht antwortet, das Zertifikat des Kubelets abgelaufen ist, oder die Platte so voll ist, dass es seinen Status nicht mehr schreiben kann. Ein volles /var erklärt NotReady und Eviction gleichzeitig.

Von außen, ohne SSH, sehen Sie nur die letzte Condition und Unschedulable. Reicht der Text Kubelet stopped posting node status, ist der nächste Schritt Zugang zum Node, nicht ein weiteres kubectl delete pod.

CNI und die Runtime

Network plugin returns error: cni plugin not initialized macht den Node NotReady oder lässt Pods in ContainerCreating mit FailedCreatePodSandBox. Das CNI-Pod auf diesem Node muss laufen, bevor Workload-Pods ein Netz bekommen. Nach einem Node-Neustart ist die Reihenfolge: Runtime, Kubelet, CNI, dann erst Ihre Deployments.

container runtime is down ist containerd oder CRI-O, nicht das Deployment. systemctl status containerd auf dem Node. Solange die Runtime tot ist, hilft kein Image-Pull und kein neues Replica.

Pressure ist Ready oder nicht

DiskPressure und MemoryPressure können True sein, während Ready noch True ist. Der Scheduler meidet den Node für neue Pods, das Kubelet evicted welche. Erst wenn das Kubelet selbst nicht mehr meldet, kippt Ready. Wer nur auf NotReady wartet, übersieht die Evictions eine Stufe vorher.

kubectl top node braucht metrics-server. Ohne ihn bleiben die Conditions der Beleg. Allocatable gegen Allocated im describe zeigt die Reservierung, nicht die volle Platte. Die volle Platte steht in der Condition DiskPressure und im Text dahinter.

Pods von einem toten Node

Ein Pod bleibt Running in der API, obwohl der Node weg ist, bis das Kubelet das Gegenteil meldet oder die Control Plane ihn abreißt. kubectl delete pod --force --grace-period=0 ist hier der Fall aus Pod Terminating: der Node kommt nicht zurück, das API-Objekt muss weg, damit das Replica woanders entsteht. Auf einem Node, der gleich wieder Ready wird, löscht dasselbe Kommando einen Pod, dessen Prozess noch schreibt.

Quellen

• Node-Status und Conditions
• Node-Pressure Eviction