ContainerCreating hängt: Mount, Sandbox, CNI

TL;DR

ContainerCreating heißt: der Scheduler hat einen Node gewählt, der Container existiert noch nicht. Logs gibt es nicht. Die Events am Pod nennen den blockierenden Schritt:

kubectl describe pod POD

FailedMount ist Volume, Secret oder ConfigMap als Datei. FailedCreatePodSandBox ist CNI, Pause-Image oder die Runtime. Pulling ohne Ende ist doch das Image, auch wenn der Status noch nicht ImagePullBackOff heißt. Die Weiche davor: Pod startet nicht.

Schon geschedult, noch nicht gestartet

kubectl get pod POD -o wide zeigt einen Node. Damit sind Requests, Taints und Quota für diesen Versuch erledigt. Wer jetzt an nodeSelector dreht, ändert einen Pod, der den Node schon hat. Erst die Event-Zeile.

Mehrere Events können sich abwechseln: erst Mount, dann Sandbox, dann wieder Mount. Die jüngste Zeile mit Warning ist der aktuelle Blocker. Ältere Pulled heißen, dass das Image schon da ist und nicht mehr verdächtig.

FailedMount

Der häufigste Text: Secret oder ConfigMap „not found“, PVC „not bound“, oder der CSI-Attach läuft in einen Timeout.

Ein fehlendes Secret als Volume bleibt hier hängen. Dasselbe Secret als Env wird CreateContainerConfigError. Prüfen Sie volumeMounts gegen volumes im Spec, dann ob das Objekt im Namespace des Pods liegt.

Ein PVC auf Pending hält den Pod in ContainerCreating oder selbst auf Pending, je nachdem ob der Claim schon gebunden sein muss. volumeBindingMode: WaitForFirstConsumer ist normal, solange kein Pod da ist. Sobald dieser Pod da ist und der Claim Pending bleibt, weiter bei PVC Pending: Klasse, Provisioner, Zone.

FailedAttachVolume mit einer Zonen-Meldung heißt: das Volume liegt nicht in der Zone des Nodes. Der Pod muss auf einen Node dieser Zone, oder das Volume neu entstehen, nachdem der Pod dort geplant ist.

FailedCreatePodSandBox

Die Sandbox ist der Pause-Container plus das Netz des Pods. failed to setup network und CNI im Text: das CNI-Plugin auf diesem Node ist nicht bereit. Vergleichen Sie den Node mit einem, auf dem Pods laufen.

kubectl get pods -n kube-system -o wide

Calico, Cilium oder das Cloud-CNI müssen auf genau diesem Node Running sein. Ein Node ohne CNI-Pod produziert Sandbox-Fehler für jeden neuen Workload. Das ist ein Node-Problem, auch wenn der Node noch Ready sagt, weil die Bedingung nachzieht.

sandbox image und pull im Text: das Pause-Image kommt nicht von der Registry. Dieselbe Ursache wie ImagePull, nur für das Infrastruktur-Image. Rate-Limit, Proxy, falscher Mirror.

Wie lange ist „hängt“

Ein CSI-Volume braucht oft eine Minute, ein Cloud-Disk länger. Unter zwei Minuten ohne neues Event ist noch kein Defekt. Dieselbe Warning über mehrere Minuten, mit steigendem count in der Event-Zeile, ist einer. Events verschwinden nach etwa einer Stunde. Wer zu spät schaut, sieht einen ruhigen Pod, der trotzdem nicht startet. describe dann wiederholen, nachdem Sie einen neuen Versuch ausgelöst haben.

Quellen

• Volumes und FailedMount
• CNI und Pod-Netz