Un pod de mon cluster Kubernetes est bloqué sur "ContainerCreating" après avoir exécuté une création. Comment puis-je voir les journaux de cette opération afin de diagnostiquer pourquoi elle est bloquée ? kubectl logs ne semble pas fonctionner puisque le conteneur doit être dans un état non actif.
Que se passe-t-il si le conteneur reste bloqué à ContainerCreating sans aucun événement ? pour moi, les événements sont affichés comme "Aucun événement".
Certains événements semblent mettre du temps à se manifester. Par exemple, un délai d'attente lors de la tentative de montage d'un disque prend environ 2 minutes avant de s'afficher comme un événement.
Cela se produit lorsque vous utilisez des secrets et qu'ils ne sont pas trouvés (comme une faute de frappe dans le yaml ou que vous avez oublié de les créer auparavant). Pour la quasi-totalité des autres erreurs possibles, il obtient CrashLoopback ou Error states, mais avec les secrets, il reste bloqué dans ContainerCreating, 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'Notez toutefois que le tri des événements peut ne pas fonctionner correctement en raison de ce bogue : https://github.com/kubernetes/kubernetes/issues/29838
Alternativement :
Depuis Kubernetes 1.18, tous les nouveaux objets ont des métadonnées pour les applications côté serveur. appliquer, 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'ai eu un événement relatif à 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 à l'aide des requêtes fournies par GKE, mais je pense que mes filtres étaient trop serrés. Cette commande m'a aidé à isoler ce qui se passait exactement. (J'avais oublié de construire le configmap, derp.)
Dans mon cas, l'accès de Docker à Internet a été bloqué. Il 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 la lenteur de la connexion Internet. Étant donné que les images docker requises sont de l'ordre de 100 Mo, les conteneurs docker et les pods Kubernetes sont restés dans les limites de l'espace disponible. \pause y ContainerCreating états pendant 30 minutes.
Pour vérifier si docker télécharge les images, exécutez :
$ ls -l /var/lib/docker/tmpdans le cluster, qui montre le(s) fichier(s) image temporaire(s) en cours de téléchargement, vide sinon.
Si vous développez dans minikube et utilisez un VPN, docker peut utiliser votre VPN via violoniste . C'est-à-dire que 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, un pod était bloqué à ' ContainerCréation parce que le téléchargement d'une image docker a été interrompu (certaines couches ont été téléchargées, d'autres sont restées bloquées au stade du "téléchargement").
$ kubectl get events --all-namespaces --sort-by='.metadata.creationTimestamp'a montré un événement "Tirer l'image".
J'ai essayé de tirer cette image en utilisant docker image pull... et j'ai vu qu'elle était suspendue.
Il s'est avéré qu'il y a un bug dans le tirage simultané des couches. En modifiant la configuration de docker pour limiter la concurrence, le problème a été résolu.
Ajouté à la configuration de docker (sur Windows, interface utilisateur docker-desktop, paramètres, moteur Docker) 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
La capitalisation de ce m fait une très grande différence dans l'utilisation des ressources. J'étais bloqué sur ContainerCreating parce que 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 ne comprend pas
ContainerCreating...3 votes
Habituellement, lorsque j'obtiens ce problème, c'est parce que les secrets appropriés ne sont pas créés -
kubectl describe pods *pod_name*révélera si c'est la cause - regardez les 'événements' listés en bas de la sortie. Conseil - pour obtenir le nom_de_pod 使い道kubectl get podset copiez le nom du module que vous voulez inspecter.