☰

Kubernetes bleibt bei ContainerCreating hängen

tag-icon • tag-icon kubernetes
Kubernetes bleibt bei ContainerCreating hängen

Ein Pod in meinem Kubernetes-Cluster bleibt nach dem Ausführen einer Erstellung bei „ContainerCreating“ hängen. Wie kann ich Protokolle für diesen Vorgang anzeigen, um zu diagnostizieren, warum er hängen bleibt? kubectl logsscheint nicht zu funktionieren, da sich der Container in einem nicht ausstehenden Zustand befinden muss.

Antwort1

kubectl describe podswird auflistenmanche(wahrscheinlich die meisten, aber nicht alle) der mit dem Pod verbundenen Ereignisse, einschließlich des Abrufens von Bildern und Startens von Containern.

Antwort2

Nähere Infos hierzu können bei den Veranstaltungen gegeben werden.

kubectl get events --all-namespaces  --sort-by='.metadata.creationTimestamp'

Beachten Sie jedoch, dass das Sortieren von Ereignissen aufgrund des folgenden Fehlers möglicherweise nicht richtig funktioniert:https://github.com/kubernetes/kubernetes/issues/29838

Alternative:

Ab Kubernetes 1.18 verfügen alle neuen Objekte über Metadaten zur serverseitigen Anwendung, was uns eine neue Möglichkeit zum Sortieren von Ereignissen bietet:

kubectl get events --sort-by=".metadata.managedFields[0].time"

Aus:https://github.com/kubernetes/kubernetes/issues/29838#issuecomment-789660546

In meinem Fall hatte ich ein Ereignis im Zusammenhang mit einem Pod:

default       13s         Warning   FailedMount               Pod          Unable to mount volumes for pod "restore-db-123-1-5f24s_default(9b7df264-2976-11ea-bb8f-42010a9a002c)": timeout expired waiting for volumes to attach or mount for pod "default"/"restore-db-123-1-5f24s". list of unmounted volumes=[nfsv]. list of unattached volumes=[nfsv default-token-hxrng]

Antwort3

In meinem Fall war der Internetzugriff von Docker blockiert. Das Problem wurde mithilfe eines Proxys gelöst (mit sandylss' Kommentar):

  1. minikube stop
  2. minikube delete
  3. export http_proxy=http://user:pass@ip:port
  4. export https_proxy=http://user:pass@ip:port
  5. export no_proxy=192.168.99.0/24
  6. 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
  7. export no_proxy=$no_proxy,$(minikube ip)
  8. export NO_PROXY=$no_proxy,$(minikube ip)

Um dann zu überprüfen, ob Docker Zugriff auf das Internet hat, führen Sie Folgendes aus:

$ docker pull tutum/hello-world

im Cluster (stellen Sie über eine Verbindung zum Cluster her minikube ssh); stoppen Sie den Vorgang, wenn der Download beginnt.

Mein zweites Problem war die langsame Internetverbindung. Da die erforderlichen Docker-Images etwa 100 MB groß sind, blieben sowohl Docker-Container als auch Kubernetes-Pods 30 Minuten lang in den Zuständen \pause.ContainerCreating

Um zu überprüfen, ob Docker die Images herunterlädt, führen Sie Folgendes aus:

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

im Cluster, der die heruntergeladenen temporären Image-Dateien anzeigt, andernfalls leer.

Wenn Sie in Minikube entwickeln und VPN verwenden, kann Docker Ihr VPN überGeiger. Das heißt, Docker wird mit Fiddlers IP:Port verbunden und Fiddler ist mit dem VPN verbunden. Andernfalls wird das VPN nicht zwischen Ihrem Host und der Minikube-VM geteilt.

Antwort4

Das eine Mal, als mir dies passierte, lag es daran, dass meine Ressourcendeklarationen versehentlich sehr, sehr klein waren.

Ressourcen: Grenzen: CPU: 1000 m Speicher: 1024 M Anfragen: CPU: 1000 m Speicher: 1024 M

Gegen

Ressourcen: Grenzen: CPU: 1000 m Speicher: 1024 m Anfragen: CPU: 1000 m Speicher: 1024 m

Die Großschreibung von m macht einen sehr großen Unterschied bei der Ressourcennutzung. Ich blieb bei ContainerCreating hängen, weil ich meinem Container nicht genügend Speicher zugewiesen hatte.

verwandte Informationen