1 Description du problème
Dès que le pod de k8s commence à fonctionner, il se bloque et meurt immédiatement. Chaque fois que je tape kubeclt log -n XXX à la hâte, avant d'avoir le temps de le voir, le pod raccroche et je ne vois pas le journal .
2 solutions
2.1 Lorsque le pod est en cours d'exécution, n'exécutez pas d'abord la commande d'origine, mais exécutez sleep pendant 3 600 secondes pour maintenir le pod en vie.
2.2 Recherchez la commande que le pod a exécutée auparavant, entrez dans le pod et entrez directement la commande en cours d'exécution, vérifiez explicitement le journal en cours d'exécution et recherchez la cause de l'erreur.
3 Pratique
3.1 Obtenir la commande d'exécution du conteneur
La nouvelle version de l'environnement k8s utilise containersd au lieu de docker. Comment puis-je vérifier les commandes en cours d'exécution dans le conteneur ? Docker est obtenu en utilisant docker inspect img_id. L'idée de fonctionnement dans l'environnement containersd est la même. Recherchez d'abord le nœud sur lequel le pod qui vous intéresse s'exécute, puis obtenez l'identifiant de l'image sur le nœud, puis utilisez crictl inpecti XXXX pour obtenir le commande en cours d'exécution au démarrage du pod.
3.1.1 Rechercher le pod en cours d'exécution du pod
[root@node1 ingress_down]# kubectl get pod -n com-pre -owide|grep test test
-service-7cbddfccdc-zvtmw 2/2 Exécution 0 23h 10.244.33.139 node5
3.1.2 Accédez au nœud correspondant et utilisez les images crictl pour obtenir l'ID d'image utilisé par le pod :
[root@node5 ~]# images crictl |grep test
harbour.myserver.com/data-sec/test 1.0.4 44c4651ee5970 327 Mo
3.1.3 Utilisez crictl inspecti image_id pour obtenir la commande de démarrage dans l'image empaquetée
[root@node5 ~]# crictl inspecti 44c4651ee5970
…
…
{ "créé": "2022-07-11T01:45:32.489102244Z", "created_by": "/bin/sh -c #(nop) ENTRYPOINT ["java" "-Djava.security.egd=file:/dev/./urandom " "-jar" "/test.jar"]", "empty_layer" : true }
Grâce aux opérations ci-dessus, la commande exécutée dans l'image de test est :
java -Djava.security.egd=file:/dev/./urandom -jar test.jar
3.2 Modifier le fichier test.yaml
…
- nom : image du service de test
: harbour.myserver.com/data-sec/test:1.0.6
#command : ["/bin/sh", "-c", "touch /tmp/test ; sleep 30 ; rm -f /tmp/test; sleep 3600"] #Utilisez cette phrase de veille pour remplacer la commande en cours d'exécution par défaut
imagePullPolicy : IfNotPresent
ressources :
limites :
…
3.3 Appliquez le nouveau fichier yaml, entrez dans le conteneur, exécutez la commande obtenue en 3.1.3 et observez le journal en cours d'exécution pour résoudre les erreurs.
3.3.1 appliquer un nouveau fichier yaml
[root@node1 ingress_down]# kubectl apply -f test.yaml
3.3.2 Entrer dans le pod
[root@node1 ingress_down]# kubectl exec -it -n my_ns test-service-7cbddfccdc-zvtmw -c test-service – /bin/bash
3.3.3 Entrez la ligne de commande à l'intérieur du pod
Exécutez ensuite directement la ligne de commande obtenue ci-dessus dans le pod : java -Djava.security.egd=file:/dev/./urandom -jar test.jar, observez la sortie du journal et déboguez [root
@kms-pm-service- 7cbddfccdc -zvtmw /]# java -Djava.security.egd=file:/dev/./urandom -jar test.jar
3.3.4 Déboguer calmement et observer le journal de sortie
De cette façon, vous pouvez observer les journaux et les déboguer calmement, et vous n'avez pas à vous soucier du fait que le pod raccroche après qu'une erreur soit signalée et ne puisse pas voir le journal de sortie.
4 Résumé
Pour la plupart des erreurs, vous pouvez directement utiliser kubectl log pour voir le journal des erreurs. Si vous rencontrez une erreur dès son exécution et que vous ne pouvez pas voir la sortie du journal, vous pouvez essayer la solution ci-dessus. J'espère que cette note pourra être utile à tout le monde.