Kubernetes bloccato su ContainerCreating

100

Un pod nel mio cluster Kubernetes è bloccato su "ContainerCreating" dopo aver eseguito una creazione. Come posso vedere i registri per questa operazione al fine di diagnosticare perché è bloccato? kubectl logsnon sembra funzionare poiché il contenitore deve trovarsi in uno stato non in sospeso.

kubernetes

— four43
fonte

kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/… è la documentazione sulle possibili fasi. Purtroppo non include ContainerCreating...

— Xiong Chiamiov

Risposte:

126

kubectl describe podselencherà tutti gli eventi associati al pod, incluso il pull delle immagini, l'avvio dei container. Potrebbe essere di aiuto.

— Sreekanth Pothanis
fonte

cosa succede se il contenitore si blocca su ContainerCreating senza eventi? per me gli eventi sono indicati come "Nessun evento".

— Bob,

Alcuni eventi sembrano richiedere del tempo per presentarsi. Ad esempio, un timeout che tenta di montare un disco per me richiede circa 2 minuti prima che venga visualizzato come evento.

— jwadsack,

Succede quando stai usando segreti che non vengono trovati (come un refuso nello yaml o hai dimenticato di crearlo prima). Per quasi tutti gli altri possibili errori che ottiene gli stati CrashLoopback o Error ma con i segreti si blocca in ContainerCreating, se descrivi il pod vedrai alla fine un messaggio che dice che il segreto non è stato trovato, ma a malapena dice nulla del problema.

— danius

Sì, di solito non hai eventi prima che inizi a fare qualcosa.

— erikbwork,

Mi è successo questa mattina ed è stato un refuso in un hostPath per un volume. Yay tastiera adesiva.

— Joe Block,

Nel mio caso, l'accesso alla finestra mobile di Internet è stato bloccato. È stato risolto usando un proxy ( usando il commento di sandylss ):

minikube stop
minikube delete
export http_proxy=http://user:pass@ip:port
export https_proxy=http://user:pass@ip:port
export no_proxy=192.168.99.0/24

minikube start --logtostderr --v=0 --bootstrapper=localkube --vm-driver hyperv 
  --hyperv-virtual-switch "Primary Virtual Switch" --docker-env HTTP_PROXY=$http_proxy \
  --docker-env HTTPS_PROXY=$https_proxy --docker-env NO_PROXY=$no_proxy

export no_proxy=$no_proxy,$(minikube ip)
export NO_PROXY=$no_proxy,$(minikube ip)

Quindi, per verificare se la finestra mobile ha accesso a Internet, eseguire:

$ docker pull tutum/hello-world

nel cluster (connettersi al cluster usando minikube ssh); interrompere il processo se inizia il download.

Il mio secondo problema era la connessione internet lenta. Poiché le immagini della finestra mobile richieste sono dell'ordine di 100 MB, entrambi i contenitori della finestra mobile e i contenitori Kubernetes sono rimasti dentro \pausee indicano ContainerCreatingper 30 minuti.

Per verificare se la finestra mobile sta scaricando le immagini, eseguire:

$ ls -l /var/lib/docker/tmp

nel cluster, che mostra i file di immagine temporanei che vengono scaricati, altrimenti vuoti.

Se stai sviluppando in minikube e stai usando VPN, la finestra mobile può usare la tua VPN tramite il violinista . Cioè, la finestra mobile sarà connessa all'ip: port di fiddler e il fiddler è connesso alla VPN. Altrimenti, la VPN non è condivisa tra l'host e la VM minikube.

— user477273
fonte

Oggi sono stato colpito da questo bug. Non so ancora cosa l'abbia causato. Le cose stavano andando bene un minuto e poi, questo problema è emerso. Grazie per la correzione. Ha funzionato per me.

— Jim,

L'unica volta che l'ho colpito è stato perché le mie dichiarazioni sulle risorse erano casualmente molto ridotte.

risorse: limiti: cpu: memoria 1000m: 1024M richieste: cpu: memoria 1000m: 1024M

risorse: limiti: cpu: memoria 1000m: 1024m richieste: cpu: memoria 1000m: 1024m

capitalizzare che m fa una differenza molto grande nell'uso delle risorse. Ero bloccato su ContainerCreating perché non avevo dato abbastanza memoria al mio contenitore.

— Luis Felipe Moura Pereira De S
fonte