Kubernetes: Pods bloqués avec le statut ContainerCreating

Créé le 6 août 2016  ·  3Commentaires  ·  Source: kubernetes/kubernetes

Pour une raison quelconque, aujourd'hui, lorsque j'ai déployé une nouvelle version sur l'un de nos déploiements, le pod s'est bloqué dans ContainerCreating avec ces événements d'erreur :

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]

J'ai ensuite tenté de mettre à l'échelle le cluster et plus de 75 % des pods en cours d'exécution sont passés à ContainerCreating et y sont également restés bloqués. Cela a causé une défaillance généralisée de notre système et j'ai dû créer rapidement un nouveau cluster.

Nous utilisons le moteur de conteneur de Google Cloud Platform et la version du cluster est 1.3.2.

arekubectl kinbug sistorage

Commentaire le plus utile

J'ai vu un problème similaire avec la v1.3.3 mais dans mon cas, la cause première était beaucoup plus piétonne. Mon déploiement nécessite un volume de secrets et j'avais oublié de créer le secret associé pour le cluster sur lequel j'essayais d'effectuer le nouveau déploiement. Je n'ai vu aucune erreur lors de l'utilisation de kubectl describe ou kubectl logs mais j'ai finalement réalisé que le déploiement restait bloqué dans l'état ContainerCreating (sans journalisation) si un volume dont il dépendait était manquant.

Tous les 3 commentaires

@montanaflynn Il y avait un certain nombre de problèmes liés au stockage avec la v1.3.2 qui ont été corrigés avec la v1.3.4 . Vous en avez probablement touché un.

Si vous partagez le /var/log/kubelet log complet d'un nœud avec un déploiement bloqué, je peux jeter un œil et confirmer s'il s'agit d'un problème connu ou non. J'aurais également besoin de votre nom de projet/nom de cluster/zone GKE pour récupérer vos journaux principaux. N'hésitez pas à m'envoyer un e-mail si vous ne souhaitez pas partager publiquement.

J'ai vu un problème similaire avec la v1.3.3 mais dans mon cas, la cause première était beaucoup plus piétonne. Mon déploiement nécessite un volume de secrets et j'avais oublié de créer le secret associé pour le cluster sur lequel j'essayais d'effectuer le nouveau déploiement. Je n'ai vu aucune erreur lors de l'utilisation de kubectl describe ou kubectl logs mais j'ai finalement réalisé que le déploiement restait bloqué dans l'état ContainerCreating (sans journalisation) si un volume dont il dépendait était manquant.

Ce problème est périmé. Fermeture.

Cette page vous a été utile?
0 / 5 - 0 notes