Kubernetes: Pods stecken im Status ContainerCreating fest
Aus irgendeinem Grund blieb der Pod heute, als ich eine neue Version in einer unserer Bereitstellungen einführte, in ContainerCreating mit diesen Fehlerereignissen stecken:
1h 1m 37 some-api-2275263275-01pq7 Pod Warning FailedMount {kubelet gke-cluster-1-default-pool-4399eaa3-os4v} Unable to mount volumes for pod "some-api-2275263275-01pq7_default(afc5ae68-5b5e-11e6-afbb-42010a800105)": timeout expired waiting for volumes to attach/mount for pod "some-api-2275263275-01pq7"/"default". list of unattached/unmounted volumes=[default-token-880jy]
1h 1m 37 some-api-2275263275-01pq7 Pod Warning FailedSync {kubelet gke-cluster-1-default-pool-4399eaa3-os4v} Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "some-api-2275263275-01pq7"/"default". list of unattached/unmounted volumes=[default-token-880jy]
Ich habe dann versucht, den Cluster zu skalieren und mehr als 75% der zuvor laufenden Pods wechselten zu ContainerCreating und blieben auch dort hängen. Dies führte zu weit verbreiteten Fehlern in unserem System und ich musste schnell einen neuen Cluster erstellen.
Wir verwenden die Container-Engine der Google Cloud-Plattform und die Cluster-Version ist 1.3.2.
montanaflynn
Alle 3 Kommentare
@montanaflynn Es gab eine Reihe von speicherbezogenen Problemen mit v1.3.2, die mit v1.3.4 behoben wurden . Sie haben wahrscheinlich einen davon getroffen.
Wenn Sie die vollständigen /var/log/kubelet log von einem Knoten mit einer festgefahrenen Bereitstellung freigeben, kann ich einen Blick darauf werfen und bestätigen, ob es sich um ein bekanntes Problem handelt oder nicht. Ich benötige auch Ihren GKE-Projektnamen/Clusternamen/Ihre Zone, um Ihre Master-Logs abzurufen. Fühlen Sie sich frei, mir eine E-Mail zu senden, wenn Sie nicht öffentlich teilen möchten.
saad-ali
am 6. Aug. 2016
Ich habe ein ähnliches Problem mit v1.3.3 gesehen, aber in meinem Fall war die Ursache viel mehr Fußgänger. Meine Bereitstellung erfordert ein geheimes Volume und ich hatte vergessen, das zugehörige Geheimnis für den Cluster zu erstellen, für den ich die neue Bereitstellung durchführen wollte. Ich habe keine Fehler bei der Verwendung von kubectl describe oder kubectl logs aber schließlich festgestellt, dass die Bereitstellung im Zustand ContainerCreating (ohne Protokolle) stecken blieb, wenn ein Volume fehlt, von dem sie abhängt.
abawany
am 10. Aug. 2016
Dieses Problem ist veraltet. Schließen.
grodrigues3
am 10. März 2017
Verwandte Themen
rhohubbuild
·
3Kommentare
jason-riddle
·
3Kommentare
chowyu08
·
3Kommentare
jadhavnitind
·
3Kommentare
ttripp
·
3Kommentare
Hilfreichster Kommentar
Ich habe ein ähnliches Problem mit v1.3.3 gesehen, aber in meinem Fall war die Ursache viel mehr Fußgänger. Meine Bereitstellung erfordert ein geheimes Volume und ich hatte vergessen, das zugehörige Geheimnis für den Cluster zu erstellen, für den ich die neue Bereitstellung durchführen wollte. Ich habe keine Fehler bei der Verwendung von
kubectl describeoderkubectl logsaber schließlich festgestellt, dass die Bereitstellung im ZustandContainerCreating(ohne Protokolle) stecken blieb, wenn ein Volume fehlt, von dem sie abhängt.