Analyse des pannes | Processus de diagnostic des pannes Kubernetes

1. Présentation et principaux termes de cet article

1.1 Présentation

Cet article est divisé en fonction des trois modules de Pod, Service et Ingress Pour les éventuelles défaillances quotidiennes de Kubernetes, il fournit des étapes de dépannage plus spécifiques et joint des solutions ou des références pertinentes.

1.2 Termes clés

1. Pod : la plus petite unité informatique déployable créée et gérée dans Kubernetes. est un groupe (un ou plusieurs) de conteneurs ; ces conteneurs partagent le stockage, la mise en réseau et une déclaration sur la façon de les exécuter.

2. Redirection de port : mapper le port local au port d'application spécifié via la redirection de port.

3. Service : un service Kubernetes est une abstraction qui définit une collection logique de pods et une politique pour y accéder - parfois appelée microservice.

4. Ingress : assure le routage des communications depuis l'extérieur du cluster vers les services HTTP et HTTPS internes. Le routage du trafic est contrôlé par des règles définies sur la ressource Ingress.

2. Processus de diagnostic des pannes

2.1 Vérification du module Pods

• Si le processus suivant réussit, continuez vers le bas et s'il échoue, sautez selon l'invite.

2.1.1 Vérifier si un pod est dans l'état PENDING

1. kubectl get pods : s'il y a un pod dans l'état PENDING, regardez vers le bas, sinon passez à 2.1.5.

[root@10-186-65-37 ~]# kubectl get pods
NOM STATUT PRÊT REDÉMARRAGE ÂGE
myapp-deploy-55b54d55b8-5msx8 0/1 En attente 0 5m
 

2 kubectl describe pod <pod-name> : si les informations détaillées d'une ou plusieurs ressources spécifiées sont correctement sorties, alors il sera jugé si les ressources du cluster sont insuffisantes, sinon, développez-les, sinon passez à 2.1.2.

2.1.2 Vérifier si la limite ResourceQuota est déclenchée

1. kubectl describe resourcequota -n <espace de noms> :

 

2 S'il existe des restrictions, libérez ou développez les ressources correspondantes, reportez-vous à : https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources

Sinon passez au 2.1.3

2.1.3 Vérifier s'il y a un PVC dans l'état PENDING

1. Un volume persistant (PersistentVolume, PV) est un élément de stockage dans le cluster, qui peut être provisionné à l'avance par l'administrateur, ou provisionné dynamiquement à l'aide d'une classe de stockage (Storage Class) ; une demande de volume persistant (PersistentVolumeClaim, PVC) exprime la demande de stockage d'un utilisateur.

2. kubectl describe pvc <pvc-name> : si STATUS est en attente

 

Reportez-vous au lien suivant pour le résoudre : https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/

Sinon, passez à 2.1.4.

2.1.4 Vérifier si le pod est affecté au nœud

1. kubectl get pods -o wide : s'il a été affecté au nœud

 

C'est un problème avec le Scheduler, veuillez vous référer au lien suivant pour le résoudre : https://kubernetes.io/zh/docs/concepts/scheduling-eviction/kube-scheduler/

Sinon c'est un problème Kubectl.

2.1.5 Vérifier si les pods sont en état RUNNING

1. kubectl get pods -o wide : si les pods sont à l'état RUNNING, passez à 2.1.10, sinon passez à 2.1.6.

2.1.6 Vérifier les journaux du pod

1. kubectl logs <pod-name> :

Si le journal peut être obtenu correctement, corrigez les problèmes associés en fonction du journal.

1. Si le journal ne peut pas être obtenu, évaluez si le conteneur s'arrête rapidement. S'il s'arrête rapidement, exécutez : kubectl logs <pod-name> --previous

2. Si le journal ne peut pas être obtenu et que le conteneur n'est pas arrêté rapidement, passez à 2.1.7

2.1.7 Si l'état du pod est ImagePullBackOff

1. kubectl describe pod <pod-name> : vérifiez si le statut est ImagePullBackOff ? Si ce n'est pas ImagePullBackOff, passez à 2.1.8.

2. Vérifiez si le nom de l'image est correct et corrigez l'erreur.

3. Vérifiez si la balise d'image existe et est validée.

4. Voulez-vous extraire les miroirs du registre privé ? Si c'est le cas, confirmez que les informations de configuration sont correctes.

5. Si l'image n'est pas extraite d'un registre privé, le problème peut provenir de CRI (Container Runtime Interface) ou de kubectl.

2.1.8 Si l'état du pod est CrashLoopBackOff

1. kubectl describe pod <pod-name> : vérifiez si l'état est CrashLoopBackOff ? Sinon, passez à 2.1.9.

2. Si tel est le cas, consultez les journaux et corrigez le plantage de l'application.

3. Il vous manque une commande CMD dans le Dockerfile ? Docker history < image-id > (vous pouvez ajouter --no-trunc pour afficher la sortie complète)

 

 

1. L'état du pod est-il fréquemment redémarré et l'état bascule entre Running et CrashLoopBackOff ? Si c'est le cas, vous devez réparer la sonde de vivacité (sonde de survie), veuillez vous référer au lien suivant : https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

2.1.9 Si l'état du pod est RunContainerError

1. kubectl describe pod <pod-name> : vérifiez si l'état est RunContainerError.

2. Si le statut est RunContainerError, le problème peut être causé par le montage du volume (volume), veuillez vous référer au lien suivant : https://kubernetes.io/zh/docs/concepts/storage/volumes/

3. Sinon, demandez de l'aide sur des sites tels que StackOverflow.

2.1.10 Vérifier si les pods sont à l'état PRÊT

1. S'il est dans l'état PRÊT, continuez à exécuter les paramètres de mappage

 

S'il n'y a pas de pods à l'état PRÊT, passez à 2.1.11.

2. transfert de port kubectl <pod-name> 8080 :<pod-port> 

3. Le mappage passe avec succès à 2.2.

a) cartographier

 b) Vérifier que le mappage a réussi

 

En cas d'échec, vous devez confirmer que le programme peut être surveillé par toutes les adresses. La déclaration de réglage est la suivante

 

S'il ne peut pas être surveillé par toutes les adresses, il est dans un état inconnu (état inconnu).

2.1.11 Vérification de l'état de préparation (Readiness Probe)

1. kubectl describe pod <pod-name>

2. Pour une sortie normale, corrigez le problème correspondant selon le journal et reportez-vous au lien suivant https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

3. L'échec est un état inconnu (état inconnu).

2.2 Contrôle du module de service

2.2.1 Vérification de l'état actuel du service

1. La sortie réussie de kubectl describe service <service-name> est la suivante

 

2 Pouvez-vous voir la colonne Endpoints et avoir une sortie normale ? Pour une sortie anormale, passez à 2.2.2.

3 kubectl port-forward service/<service-name> 8080 :<service-port> La sortie réussie est la suivante

 

4 En cas de succès, passez à 2.3 et en cas d'échec, passez à 2.2.4.

2.2.2 Comparaison des étiquettes du sélecteur et du pod

1. Afficher les informations d'étiquette du pod kubectl describe pod <pod-name>

 

2 Affichez les informations de sélecteur du service kubectl describe service <service-name>

3 Comparez les deux pour voir s'ils correspondent correctement, corrigez-les s'ils sont faux et passez à 2.2.3 s'ils sont corrects.

2.2.3 Vérifier si le Pod a reçu une adresse IP

1. Afficher les informations IP du pod kubectl describe pod <pod-name>

2. L'adresse IP est correctement attribuée, alors le problème est dû à kubectl.

 

 

3 Si l'adresse IP n'est pas attribuée, le problème est causé par le gestionnaire de contrôleur.

2.2.4 Vérifier Service TargetPort et Pod ContainerPort

1. Affichez les informations TargetPort du service : kubectl describe service <service-name>

 

2 Affichez les informations ContainerPort du pod : kubectl describe pod <pod-name>

 

3 Si les deux éléments ci-dessus sont cohérents, le problème est causé par kube-proxy, et s'ils ne sont pas cohérents, corrigez les informations.

2.3 Vérification du module d'entrée

2.3.1 Vérification de l'état du courant d'entrée

1. La sortie réussie de kubectl describe ingress <ingress-name> est la suivante :

 

2 Pouvez-vous voir la colonne backends et avoir une sortie normale ? La sortie normale passe à 2.3.4, sinon passe à 2.3.2.

2.3.2 Vérifier ServiceName et ServicePort

1. kubectl describe ingress <nom-entrée>

2. kubectl describe service <service-name>

 

3 Vérifiez si le ServiceName et le ServicePort des deux premiers sont corrects, s'ils sont corrects, passez à 2.3.3, veuillez corriger l'erreur.

2.3.3 Documentation du contrôleur d'entrée

1. Le problème est causé par le contrôleur Ingress, veuillez vous référer à la documentation pour trouver une solution : https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

2.3.4 Vérifier l'entrée de redirection de port

1. kubectl port-forward <ingress-pod-name> 8080:<ingress-port> Testez s'il est accessible normalement : curl localhost:8080

Pour un accès normal, passez à 2.3.5, sinon passez à 2.3.3.

2.3.5 Vérifier s'il est accessible via Ingress sur le réseau externe

1. Il est possible d'y accéder avec succès à partir du réseau externe et le dépannage est terminé.

2. S'il n'est pas accessible depuis le réseau externe, le problème est dû à l'exposition de l'infrastructure ou du cluster. Veuillez résoudre le problème.

les références 

Analyse des pannes | Processus de diagnostic des pannes Kubernetes (qq.com)