Un pod dans mon cluster Kubernetes est bloqué sur "ContainerCreating" après l'exécution d'une création. Comment puis-je voir les journaux de cette opération afin de diagnostiquer pourquoi il est bloqué? kubectl logs ne semble pas fonctionner car le conteneur doit être dans un état non en attente.
Que se passe-t-il si le conteneur reste bloqué en état de "ContainerCreating" sans aucun événement ? Pour moi, les événements sont affichés comme "Pas d'événements."
Certains événements semblent mettre du temps à apparaître. Par exemple, un délai lors de la tentative de montage d'un disque pour moi prend environ 2 minutes avant de s'afficher comme un événement.
Il se produit lorsque vous utilisez des secrets et qu'ils ne sont pas trouvés (comme une faute de frappe dans le fichier YAML ou que vous avez oublié de le créer avant). Pour presque toutes les autres erreurs possibles, cela entraîne des états CrashLoopback ou Erreur, mais avec les secrets, il reste simplement bloqué en création du conteneur, si vous décrivez le pod, vous verrez à la toute fin un message disant que le secret n'a pas été trouvé, mais il ne dit presque rien sur le problème.
Plus d'informations pourraient être fournies dans les événements.
kubectl get events --all-namespaces --sort-by='.metadata.creationTimestamp'Cependant, veuillez noter que le tri des événements pourrait ne pas fonctionner correctement en raison de ce bogue : https://github.com/kubernetes/kubernetes/issues/29838
Alternativement :
À partir de Kubernetes 1.18, tous les nouveaux objets ont des métadonnées pour l'application côté serveur, ce qui nous donne une nouvelle façon de trier les événements :
kubectl get events --sort-by=".metadata.managedFields[0].time"
De : https://github.com/kubernetes/kubernetes/issues/29838#issuecomment-789660546
Dans mon cas, j'avais un événement concernant un 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]
Merci pour cela! J'essayais d'utiliser les journaux des conteneurs en utilisant les requêtes fournies par GKE, mais je soupçonne que mes filtres étaient trop stricts. Cette commande m'a aidé à isoler ce qui se passait exactement. (J'oubliais de construire le configmap, derp.)
Dans mon cas, l'accès de docker à internet était bloqué. Cela a été résolu en utilisant un proxy (en utilisant le commentaire de 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)
Ensuite, pour vérifier si docker a accès à internet, exécutez :
$ docker pull tutum/hello-worlddans le cluster (connectez-vous au cluster en utilisant minikube ssh) ; arrêtez le processus s'il commence à télécharger.
Mon deuxième problème était une connexion internet lente. Comme les images docker requises sont de l'ordre de 100 Mo, à la fois les conteneurs docker et les pods Kubernetes restaient dans les états \pause et ContainerCreating pendant 30 minutes.
Pour vérifier si docker est en train de télécharger les images, exécutez :
$ ls -l /var/lib/docker/tmpdans le cluster, qui montre le(s) fichier(s) image temporaire(s) qui sont en cours de téléchargement, sinon vide.
Si vous développez dans minikube et utilisez un VPN, docker peut utiliser votre VPN via fiddler. Autrement dit, docker sera connecté à l'ip:port de fiddler, et fiddler est connecté au VPN. Sinon, le VPN n'est pas partagé entre votre hôte et la VM minikube.
Dans mon cas, une capsule était bloquée à 'ContainerCreating' car un tirage d'image Docker était bloqué (certains niveaux ont été téléchargés, certains étaient bloqués en "téléchargement").
$ kubectl get events --all-namespaces --sort-by='.metadata.creationTimestamp'a montré un événement "Pulling image".
Essayé de tirer cette image en utilisant docker image pull... et j'ai vu qu'elle était bloquée.
Il s'est avéré qu'il y avait un bogue dans les tirages concurrents de couches. Changer la configuration de docker pour limiter la concurrence a résolu le problème.
Je l'ai ajouté à la configuration de docker (sur Windows, interface utilisateur de docker-desktop, paramètres, Docker Engine) pour limiter la concurrence:
"max-concurrent-downloads": 1,
"max-concurrent-uploads": 1
La seule fois où j'ai rencontré ce problème, c'était parce que mes déclarations de ressources étaient accidentellement très très petites.
ressources : limites : cpu : 1000m mémoire : 1024M demandes : cpu : 1000m mémoire : 1024M
vs
ressources : limites : cpu : 1000m mémoire : 1024m demandes : cpu : 1000m mémoire : 1024m
Le fait de capitaliser ce "m" fait une très grande différence dans l'utilisation des ressources. J'étais bloqué sur ContainerCreating car je n'avais pas donné assez de mémoire à mon conteneur.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
0 votes
kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/… est la documentation sur les phases possibles. Malheureusement, elle n'inclut pas
ContainerCreating...3 votes
Généralement, lorsque j'ai ce problème, c'est parce que les secrets appropriés ne sont pas créés -
kubectl describe pods *nom_du_pod*révélera si c'est la cause - regardez les 'événements' répertoriés en bas de la sortie. Astuce - pour obtenir le nom_du_pod, utilisezkubectl get pods, et copiez le nom du pod que vous souhaitez inspecter.