Container Service for Kubernetes:Troubleshoot pod issues

Message d'erreur

Description

Solution

no nodes available to schedule pods.

Le cluster ne dispose d'aucun nœud disponible pour la planification du pod.

1. Vérifiez si des nœuds du cluster sont à l'état NotReady. Si un nœud est NotReady, inspectez-le et réparez-le.

2. Vérifiez si le pod définit un nodeSelector, une nodeAffinity ou des tolérations. Si aucune contrainte de planification de ce type n'est définie, envisagez d'ajouter davantage de nœuds au pool de nœuds.

• 0/x nodes are available: x Insufficient cpu.

• 0/x nodes are available: x Insufficient memory.

Aucun nœud disponible dans le cluster ne peut satisfaire les demandes de ressources CPU ou mémoire du pod.

Un nœud devient non planifiable lorsque le total des requests allouées atteint la capacité, même si l'utilisation réelle est faible.

Sur la page de détails du cluster cible, accédez à Nodes > Nodes et vérifiez le taux d'allocation des requests CPU ou mémoire pour le nœud cible. Vous pouvez survoler le taux d'allocation pour afficher les valeurs spécifiques d'allocation des ressources.

Pour afficher l'utilisation détaillée des ressources du nœud, consultez Utilisation de kubectl pour afficher l'utilisation des ressources du nœud.

• Optimisez la configuration des ressources :

  • Si l'utilisation des ressources d'un nœud est systématiquement inférieure à ses requests, des ressources sont gaspillées. Réduisez la configuration des requests de la charge de travail. Consultez Définition des limites de ressources CPU et mémoire pour un conteneur.

    Vous pouvez activer le profilage des ressources pour obtenir la configuration recommandée des requests.

  • Activez l'Horizontal Pod Autoscaler (HPA) pour réduire le nombre de réplicas pendant les heures creuses.

• Nettoyez les charges de travail inutiles : Mettez hors service ou réduisez le nombre de pods non essentiels.

• Augmentez la taille du pool de nœuds : Si l'utilisation des ressources sur les nœuds cibles est constamment élevée, les nœuds sont saturés. Vous pouvez augmenter la taille du pool de nœuds.

x node(s) didn't match pod's node affinity/selector.

Les nœuds existants ne correspondent pas à la politique d'affinité de nœud du pod (nodeAffinity/nodeSelector). Consultez Assigning Pods to Nodes.

1. Affichez tous les libellés d'un nœud.

   Console

   1. Sur la page de détails du cluster cible, accédez à Nodes > Nodes.

   2. Sur la page Nodes, repérez le nœud cible et, dans la colonne Actions, cliquez sur More > Manage Labels and Taints pour afficher ses libellés.

   Kubectl

   Remplacez <YOUR_NODE_NAME> par le nom réel de votre nœud.

   kubectl get node <YOUR_NODE_NAME> --show-labels

2. Vérifiez et ajustez la règle d'affinité de nœud pour la charge de travail (deployment).

   Console

   Lors de la création d'une nouvelle charge de travail :

   1. Sur la page Advanced de création d'un Deployment Create, repérez Node Affinity dans la section Scheduling et cliquez sur Add.

   2. Configurez soit Required (affinité stricte), soit Optional (affinité souple) en fonction de vos besoins métier. Plusieurs Selector ont une relation logique ET, tandis que plusieurs Rule ont une relation logique OU.

   Pour les charges de travail existantes :

   1. Sur la page Nodes > Nodes, cliquez sur > Node Affinity dans la colonne Actions du Deployment cible.

   2. La méthode de configuration est identique à celle décrite ci-dessus.

   Exemple YAML

   NodeAffinity

   Les politiques d'affinité incluent l'affinité stricte (requiredDuringSchedulingIgnoredDuringExecution), qui doit être respectée, et l'affinité souple (preferredDuringSchedulingIgnoredDuringExecution), qui exprime une préférence. L'exemple suivant utilise l'affinité stricte.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-node-affinity-deploy
         labels:
           app: demo-node-affinity
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: demo-node-affinity
         template:
           metadata:
             labels:
               app: demo-node-affinity
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             affinity:
               nodeAffinity:
                 # Hard affinity: The rule must be met.
                 requiredDuringSchedulingIgnoredDuringExecution:
                   nodeSelectorTerms:
                   - matchExpressions:
                     - key: disktype
                       operator: In
                       values:
                       - ssd
                       - nvme  # Logic: The node's 'disktype' label must be either 'ssd' or 'nvme'.

   NodeSelector

   Cela fournit une correspondance exacte simple. Le pod est planifié uniquement si les libellés du nœud remplissent les conditions.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-node-selector-deploy
         labels:
           app: demo-node-selector
       spec:
         replicas: 2  
         selector:
           matchLabels:
             app: demo-node-selector  
         template:
           metadata:
             labels:
               app: demo-node-selector
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             # The pod is scheduled only if the node has the label disktype=ssd.
             nodeSelector:
               disktype: ssd

• x node(s) didn't match pod affinity rules.

• x node(s) didn't match pod anti-affinity rules.

• Incompatibilité de la règle d'affinité. Le pod possède une règle d'affinité de pod (par exemple, nécessitant un libellé spécifique), mais aucun nœud n'héberge de pod avec un libellé correspondant, ce qui empêche la planification.

• Conflit d'anti-affinité. Le pod possède une règle d'anti-affinité de pod (par exemple, il ne peut pas coexister avec une autre application), mais tous les nœuds disponibles hébergent déjà un pod conflictuel, ce qui empêche la planification.

1. Affichez les libellés des pods sur un nœud.

   Console

   1. Sur la page de détails du cluster cible, accédez à Nodes > Nodes.

   2. Sur la page Nodes, cliquez sur le nom du nœud cible pour afficher sa page de détails. Faites défiler vers le bas jusqu'à la section Pods pour afficher les valeurs des libellés des différents pods dans la colonne Label.

   Kubectl

   • Afficher les pods et leurs libellés sur un nœud spécifique : Remplacez <YOUR_NAMESPACE> par le nom de votre namespace et <YOUR_NODE_NAME> par le nom réel de votre nœud.

     kubectl get pods -n <YOUR_NAMESPACE> --field-selector spec.nodeName=<YOUR_NODE_NAME> -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels

   • Interroger les pods par libellé : Remplacez <LABEL> par la paire clé-valeur du libellé réel, telle que app=nginx.

     kubectl get pods -A -l <LABEL> -o wide

2. Vérifiez et ajustez la règle d'affinité de pod pour la charge de travail (deployment).

   Console

   1. Lorsque vous créez une nouvelle charge de travail, sur la page Advanced du Deployment Create, repérez Pod Affinity/Pod Anti-affinity dans la section Scheduling et cliquez sur Add.

   2. Configurez soit Required (affinité stricte), soit Optional (affinité souple) en fonction de vos besoins métier. Plusieurs Selector ont une relation logique ET, tandis que plusieurs Add Rule ont une relation logique OU.

   Exemple YAML

   Les politiques d'affinité sont classées en affinité stricte (requiredDuringSchedulingIgnoredDuringExecution) et affinité souple (preferredDuringSchedulingIgnoredDuringExecution). Les règles d'affinité stricte doivent être respectées, tandis que les règles d'affinité souple sont préférées. L'exemple suivant montre une configuration pour une affinité de pod requise.

   Pour configurer l'anti-affinité de pod, remplacez simplement podAffinity par podAntiAffinity.

   apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: app-demo-podaffinity-deploy
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: demo-podaffinity
         template:
           metadata:
             labels:
               app: demo-podaffinity
           spec:
             containers:
             - name: nginx
               image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             affinity:
               podAffinity:
                 # Hard affinity: Pod must be co-located with a pod that has the 'app: nginx' label.
                 requiredDuringSchedulingIgnoredDuringExecution:
                 - labelSelector:
                     matchExpressions:
                     - key: app
                       operator: In
                       values:
                       - nginx
                   # Topology domain scope: host-level isolation.
                   topologyKey: kubernetes.io/hostname

0/x nodes are available: x node(s) had volume node affinity conflict.

La planification échoue en raison d'un conflit d'affinité de nœud de volume. Cela se produit généralement parce qu'un disque cloud ne peut pas être monté entre différentes zones.

• Pour un PV provisionné statiquement, configurez l'affinité de nœud du pod afin de garantir qu'il soit planifié sur un nœud situé dans la même zone que le PV.

• Pour un PV provisionné dynamiquement, définissez le volumeBindingMode de la StorageClass sur WaitForFirstConsumer. Cela garantit que le PV est créé uniquement après que le pod a été planifié sur un nœud, assurant ainsi que le disque cloud est créé dans la même zone que le nœud du pod.

InvalidInstanceType.NotSupportDiskCategory

L'instance ECS ne prend pas en charge le type de disque cloud spécifié.

Consultez Familles d'instances pour confirmer les types de disques cloud pris en charge par votre instance ECS. Lors du montage, mettez à jour le type de disque cloud vers un type pris en charge par l'instance ECS.

0/x nodes are available: x node(s) had taints that the pod didn't tolerate.

Le pod ne peut pas être planifié sur un nœud car il ne possède pas de tolération pour l'une des taints du nœud.

• Si la taint a été ajoutée manuellement, supprimez-la ou configurez une tolération pour le pod. Consultez Taints and Tolerations et Gestion des libellés et des taints de nœud.

• Si la taint a été ajoutée par le système, résolvez le problème sous-jacent ci-dessous et attendez la replanification.

  Afficher les taints ajoutées par le système

  • node.kubernetes.io/not-ready : Le nœud est à l'état NotReady.

  • node.kubernetes.io/unreachable : Le nœud est inaccessible depuis le contrôleur de nœud. Cela équivaut à ce que le statut Ready du nœud soit Unknown.

  • node.kubernetes.io/memory-pressure : Le nœud subit une pression mémoire.

  • node.kubernetes.io/disk-pressure : Le nœud subit une pression disque.

  • node.kubernetes.io/pid-pressure : Le nœud subit une pression PID.

  • node.kubernetes.io/network-unavailable : Le réseau du nœud est indisponible.

  • node.kubernetes.io/unschedulable : Le nœud est marqué comme non planifiable.

0/x nodes are available: x Insufficient ephemeral-storage.

Le nœud ne dispose pas d'un stockage éphémère suffisant.

1. Vérifiez la demande de stockage éphémère du Pod, qui correspond à la valeur de spec.containers.resources.requests.ephemeral-storage dans le YAML du Pod. Si la valeur est trop élevée et dépasse la capacité réelle disponible du nœud, le Pod ne pourra pas être planifié.

2. Vérifiez la capacité totale de stockage éphémère sur chaque nœud avec kubectl describe node | grep -A10 Capacity. Si elle est insuffisante, augmentez le disque du nœud ou ajoutez davantage de nœuds.

0/x nodes are available: pod has unbound immediate persistent volume claims.

Le pod n'a pas réussi à se lier à une revendication de volume persistant (PVC).

Vérifiez si le PVC ou le PV spécifié par le pod a été créé. Exécutez kubectl describe pvc <pvc-name> ou kubectl describe pv <pv-name> pour afficher les événements PVC et PV afin d'effectuer un diagnostic plus poussé. Consultez FAQ sur le stockage - CSI.

Message d'erreur

Description

Solution suggérée

Failed to pull image "xxx": rpc error: code = Unknown desc = Error response from daemon: Get xxx: denied:

L'accès au registre d'images est refusé car aucun imagePullSecret n'a été spécifié lors de la création du pod.

Vérifiez que le Secret spécifié dans le champ spec.imagePullSecrets du fichier YAML de la charge de travail existe.

Lorsque vous utilisez ACR, utilisez un assistant d'identification pour télécharger des images sans mot de passe. Consultez Télécharger des images depuis le même compte.

Failed to pull image "xxxx:xxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host

L'adresse du registre d'images n'a pas pu être résolue lors du téléchargement d'une image via HTTPS.

1. Vérifiez que l'adresse du registre d'images dans spec.containers.image du fichier YAML du pod est correcte. Si ce n'est pas le cas, mettez-la à jour.

2. Si l'adresse est correcte, vérifiez la connectivité réseau entre le nœud sur lequel le pod s'exécute et le registre d'images. Connectez-vous au nœud (pour plus d'informations, consultez Choisir une méthode de connexion à distance ECS) et exécutez la commande curl -kv https://xxxxxx/xxxxx/ pour vérifier si l'adresse est accessible. En cas d'erreur, recherchez d'éventuels problèmes réseau, tels qu'une configuration réseau incorrecte, des règles de pare-feu ou des problèmes de résolution DNS.

Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "xxxxxxxxx": Error response from daemon: mkdir xxxxx: no space left on device

L'espace disque du nœud est insuffisant.

Connectez-vous au nœud (consultez Choisir une méthode de connexion à distance ECS) et exécutez df -h pour vérifier l'espace disque. Si le disque est plein, redimensionnez-le. Consultez Étape 1 : Redimensionner un disque cloud.

Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority

Le registre d'images tiers utilise un certificat signé par une autorité de certification (CA) inconnue ou non sécurisée.

1. Le registre tiers doit utiliser un certificat émis par une CA de confiance.

2. Si vous utilisez un registre d'images privé, consultez Créer une application à partir d'un registre d'images privé.

3. Si vous ne pouvez pas modifier le certificat, vous pouvez configurer le nœud pour autoriser le téléchargement et le push d'images depuis un registre utilisant un certificat non sécurisé. Nous recommandons d'utiliser cette méthode uniquement dans les environnements de test, car elle peut affecter d'autres pods sur le nœud.

Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled

L'opération a été annulée, probablement parce que le fichier image est trop volumineux. Kubernetes dispose d'un délai d'attente par défaut pour le téléchargement des images. Si le téléchargement ne progresse pas pendant une période donnée, Kubernetes suppose que l'opération a échoué ou ne répond pas et annule la tâche.

1. Vérifiez que imagePullPolicy est défini sur IfNotPresent dans le fichier YAML du pod.

2. Connectez-vous au nœud sur lequel le pod s'exécute (pour plus d'informations, consultez Choisir une méthode de connexion à distance ECS) et exécutez docker pull ou crictl pull pour vérifier si l'image peut être téléchargée.

Failed to pull image "xxxxx": rpc error: code = Unknown desc = Error response from daemon: Get https://xxxxxxx: xxxxx/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Impossible de se connecter au registre d'images en raison de problèmes réseau.

1. Connectez-vous au nœud sur lequel le pod s'exécute (pour plus d'informations, consultez Choisir une méthode de connexion à distance ECS) et exécutez la commande curl https://xxxxxx/xxxxx/ pour vérifier si l'adresse est accessible. En cas d'erreur, recherchez d'éventuels problèmes réseau, tels qu'une configuration réseau incorrecte, des règles de pare-feu ou des problèmes de résolution DNS.

2. Vérifiez la politique de réseau public du nœud, y compris les configurations des entrées SNAT et des adresses IP élastiques (EIP) associées.

Failed to pull image "xxxx:xxx": failed to pull and unpack image "xxxx:xxx": failed to resolve reference "xxxx:xxx": failed to do request: Head "xxxx:xxx": dial tcp xxx.xxx.xx.x:xxx: i/o timeout

La connexion a expiré en raison de problèmes réseau lors du téléchargement d'une image depuis un registre situé à l'étranger.

Le téléchargement d'images depuis des registres situés à l'étranger, tels que Docker Hub, peut échouer dans les clusters ACK en raison de l'instabilité des réseaux des opérateurs. Pour résoudre ce problème, envisagez les solutions suivantes :

• Abonnez-vous aux images source situées à l'étranger en utilisant Container Registry. Pour obtenir des instructions, consultez Synchroniser des images à l'aide de l'abonnement aux artefacts.

• Créez une instance Global Accelerator (GA) pour télécharger des images directement en utilisant son réseau d'accélération globale. Pour plus de détails, consultez Accélérer les téléchargements d'images ACK interrégion avec GA.

Too Many Requests.

Docker Hub impose des limites de débit sur les demandes de téléchargement d'images.

Téléchargez l'image vers Container Registry (ACR) et téléchargez-la depuis un registre d'images ACR.

Le statut Pulling image s'affiche constamment

Le mécanisme de limitation du taux de téléchargement d'images du kubelet a peut-être été déclenché.

Ajustez registryPullQPS (QPS maximal pour le registre d'images) et registryBurst (nombre maximal de téléchargements d'images en rafale) à l'aide de la fonctionnalité Personnaliser les configurations kubelet du pool de nœuds.

Message d'erreur

Description

Solution

Bloqué dans l'état Init:N/M

Le pod possède M conteneurs d'initialisation ; N sont terminés, mais les M-N restants n'ont pas pu démarrer.

1. Vérifiez les événements du pod et les problèmes des conteneurs d'initialisation avec kubectl describe pod -n <ns> <pod name>.

2. Consultez les journaux des conteneurs d'initialisation non démarrés avec kubectl logs -n <ns> <pod name> -c <container name>.

3. Examinez la configuration du pod, telle que les paramètres de contrôle de santé, pour vous assurer que les conteneurs d'initialisation sont correctement configurés.

Consultez Déboguer les conteneurs d'initialisation.

Bloqué dans l'état Init:Error

Un conteneur d'initialisation du pod n'a pas pu démarrer.

Bloqué dans l'état Init:CrashLoopBackOff

Un conteneur d'initialisation du pod n'a pas pu démarrer et se trouve dans une boucle de redémarrage.

Message d'erreur

Description

Solution

failed to allocate for range 0: no IP addresses available in range set: xx.xxx.xx.xx-xx.xx.xx.xx

Il s'agit d'un comportement attendu dû à la conception du plugin réseau Flannel.

Mettez à niveau le composant Flannel vers la version v0.15.1.11-7e95fe23-aliyun ou ultérieure. Consultez Flannel.

Dans les clusters exécutant une version de Kubernetes antérieure à la 1,20, une fuite d'adresses IP peut se produire si un pod redémarre à plusieurs reprises ou si les pods d'un CronJob terminent leurs tâches et quittent rapidement.

Mettez à niveau le cluster vers Kubernetes 1.20 ou une version ultérieure (la dernière version est recommandée). Consultez Mettre à niveau manuellement un cluster.

Des défauts dans containerd et runC sont à l'origine de ce problème.

Pour un correctif d'urgence, consultez Pourquoi mon pod ne démarre-t-il pas avec l'erreur « no IP addresses available in range » ?

error parse config, can't found dev by mac 00:16:3e:01:c2:e8: not found

Le plugin réseau Terway maintient une base de données interne sur le nœud pour suivre et gérer les interfaces réseau élastiques (ENI). Cette erreur se produit lorsque l'état de la base de données est incohérent avec la configuration réelle du périphérique réseau, ce qui entraîne l'échec de l'allocation des ENI.

1. Les interfaces réseau se chargent de manière asynchrone. L'interface peut encore être en cours de chargement lors de la configuration CNI, ce qui déclenche une nouvelle tentative automatique CNI. Ce processus n'affecte pas l'allocation finale des ENI. Vérifiez le statut final du pod pour confirmer la réussite.

2. Si la création du pod échoue toujours et que cette erreur persiste, le pilote n'a probablement pas pu charger l'ENI en raison d'une mémoire de haut niveau insuffisante. Redémarrez l'instance ECS pour résoudre ce problème.

• cmdAdd: error alloc ip rpc error: code = DeadlineExceeded desc = context deadline exceeded

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

Le plugin réseau Terway n'a peut-être pas pu demander une adresse IP au vSwitch.

1. Consultez les journaux du conteneur Terway au sein du pod du composant Terway sur le nœud pour vérifier le processus d'allocation des ENI.

2. Consultez les informations ENI pour le pod Terway avec kubectl logs -n kube-system <terwayPodName > -c terway | grep <podName>. Obtenez l'ID de demande et le message d'erreur OpenAPI.

3. Utilisez l'ID de demande et le message d'erreur pour enquêter sur l'échec.

Message d'erreur

Description

Solution

Le journal contient exit(0).

1. Connectez-vous au nœud sur lequel la charge de travail anormale est déployée.

2. Utilisez docker ps -a | grep $podName pour vérifier. Si le conteneur n'a aucun processus persistant, il se termine avec le code d'état 0.

Les événements du pod affichent Liveness probe failed: ....

La sonde de vivacité a échoué, ce qui a provoqué le redémarrage de l'application.

• Configuration de la sonde de vivacité : Sur la page Edit de la Workloads cible, vérifiez que le chemin de la requête de contrôle de santé (par exemple, /healthz) et le port correspondent à ceux fournis par l'application. Augmentez le Initial Delay (s) pour vous assurer que la sonde de vivacité ne démarre qu'après le lancement complet de l'application.

  Vous pouvez désactiver temporairement la sonde Liveness. Ensuite, accédez au terminal du pod ou à son nœud hôte et utilisez une commande, telle que curl, pour vérifier que la méthode de contrôle de santé fonctionne correctement.

• Résoudre les problèmes de l'application : Enquêtez sur le problème en consultant les Events et les Logs du pod. Sélectionnez Show the log of the last container exit.

Les événements du pod affichent Startup probe failed: ....

La sonde de démarrage a échoué, ce qui a provoqué le redémarrage de l'application.

• Configuration de la sonde de démarrage : Sur la page Edit de la Workloads cible, vérifiez que le chemin de la requête de contrôle de santé (par exemple, /healthz) et le port correspondent à ceux fournis par l'application. Si l'application met beaucoup de temps à démarrer, augmentez le Unhealthy Threshold pour éviter les redémarrages prématurés.

  Vous pouvez désactiver temporairement la sonde Startup. Ensuite, accédez au terminal du pod ou à son nœud hôte et utilisez une commande, telle que curl, pour vérifier que la méthode de contrôle de santé fonctionne correctement.

• Résoudre les problèmes de l'application : Enquêtez sur le problème en consultant les Events et les Logs du pod. Sélectionnez Show the log of the last container exit.

Le journal du pod contient no space left on device.

Espace disque cloud insuffisant.

• Redimensionner le disque cloud.

• Nettoyez les images inutiles pour libérer de l'espace disque et configurez imageGCHighThresholdPercent pour définir le seuil de garbage collection des images sur le nœud.

Le démarrage échoue sans information d'événement.

Ce problème se produit lorsqu'un conteneur nécessite plus de ressources que ses limites déclarées, ce qui provoque son échec.

Vérifiez si la configuration des ressources du pod est correcte. Vous pouvez activer le profilage des ressources pour obtenir des configurations Request et Limit recommandées pour le conteneur.

Le journal du pod affiche Address already in use.

Un conflit de port existe entre les conteneurs du même pod.

1. Vérifiez si le pod est configuré avec hostNetwork: true. Ce paramètre amène les conteneurs du pod à partager l'espace de noms réseau et l'espace de ports de l'hôte. Si cela n'est pas nécessaire, remplacez-le par hostNetwork: false.

2. Si le pod nécessite hostNetwork: true, configurez l'anti-affinité des pods pour garantir que les pods du même ensemble de réplicas soient planifiés sur différents nœuds.

3. Vérifiez qu'aucun autre pod sur le même nœud n'utilise le port.

Le journal du pod affiche container init caused "setenv: invalid argument": unknown.

La charge de travail monte un Secret, mais la valeur dans le Secret n'est pas encodée en Base64.

• Créez le Secret dans la console (les valeurs sont automatiquement encodées en Base64). Consultez Gérer les Secrets.

• Créez le Secret à partir d'un fichier YAML et encodez manuellement la valeur en Base64 en exécutant la commande echo -n "xxxxx" | base64.

Problème spécifique à l'application.

Examinez les journaux du pod pour résoudre le problème.

Message d'erreur

Description

Solution

Les événements du pod affichent Readiness probe failed: ....

La sonde de préparation a échoué, empêchant le pod cible de recevoir du trafic.

• Configuration de la sonde de préparation : Sur la page Edit de la Workloads cible, vérifiez que le chemin de contrôle de santé (par exemple, /healthz) et le port correspondent à ceux de l'application. Si l'application démarre lentement, augmentez le Unhealthy Threshold pour éviter les échecs prématurés.

  Désactivez temporairement la sonde Readiness, puis utilisez curl depuis le terminal du pod ou l'hôte pour vérifier le point de terminaison de contrôle de santé.

• Résoudre les problèmes de l'application : Enquêtez sur le problème en consultant les Events et les Logs du pod. Sélectionnez Show the log of the last container exit.

Le statut du pod est identique à celui ci-dessus. Les événements du pod affichent Startup probe failed: ....

L'échec d'une sonde de démarrage provoque le redémarrage du conteneur. Cette erreur ne devrait pas entraîner un état Running/NotReady persistant, mais plutôt un état « CrashLoopBackOff ».

Résolvez ce problème comme décrit dans la section « Échec du démarrage du pod (CrashLoopBackOff) » pour les sondes Startup.

Niveau OOM

Description

Solution recommandée

Niveau OS

Vérifiez les journaux du noyau situés dans /var/log/messages sur le nœud hébergeant le Pod. Si les journaux indiquent qu'un processus a été arrêté mais ne contiennent aucun journal cgroup, l'événement OOM s'est produit au niveau du système d'exploitation.

• Augmentez la mémoire du nœud ou répartissez les charges de travail sur plusieurs nœuds. Consultez les rubriques Mettre à l'échelle les ressources des nœuds et Planifier des applications sur des nœuds spécifiques.

• Identifiez les Pods consommant beaucoup de mémoire sur le nœud et définissez des limites de mémoire appropriées.

Niveau cgroup

Vérifiez les journaux du noyau situés dans /var/log/messages sur le nœud hébergeant le Pod. Si les journaux contiennent un message d'erreur similaire à Task in /kubepods.slice/xxxxx killed as a result of limit of /kubepods.slice/xxxx, l'événement OOM s'est produit au niveau du cgroup.

• Augmentez les limites de mémoire du Pod. Maintenez l'utilisation réelle en dessous de 80 % des limites. Consultez les rubriques Gérer les Pods et Mettre à l'échelle les ressources des nœuds.

• Activez le profilage des ressources pour obtenir des configurations recommandées pour les requêtes et les limites des conteneurs.

Cause possible

Description

Solution recommandée

Le nœud est dans l'état NotReady.

Le Pod est automatiquement supprimé après que le nœud a récupéré de l'état NotReady.

Le Pod est configuré avec des finalizers.

Si un Pod est configuré avec des finalizers, Kubernetes exécute les opérations de nettoyage spécifiées par ces finalizers avant de supprimer le Pod. Si une opération de nettoyage ne répond pas, le Pod reste dans l'état Terminating.

Vérifiez la configuration des finalizers du Pod à l'aide de la commande kubectl get pod -n <ns> <pod name> -o yaml et identifiez la cause du problème.

Le hook preStop du Pod est invalide ou bloqué.

Si un hook preStop est configuré pour le Pod, Kubernetes l'exécute avant d'arrêter le conteneur. Le Pod reste dans l'état Terminating tant que le hook est en cours d'exécution.

Vérifiez la configuration du hook preStop du Pod à l'aide de la commande kubectl get pod -n <ns> <pod name> -o yaml et identifiez la cause du problème.

Une période d'arrêt gracieux est configurée pour le Pod.

Si un Pod est configuré avec une période d'arrêt gracieux (terminationGracePeriodSeconds), il passe à l'état Terminating après réception d'une commande d'arrêt, telle que kubectl delete pod <pod_name>. Kubernetes considère que le Pod a été arrêté avec succès uniquement après l'écoulement du temps spécifié dans terminationGracePeriodSeconds ou la sortie du conteneur.

Kubernetes supprime automatiquement le Pod une fois que le conteneur a terminé son arrêt gracieux.

Le conteneur ne répond pas.

Lorsque vous demandez l'arrêt ou la suppression d'un Pod, Kubernetes envoie un signal SIGTERM aux conteneurs du Pod. Si un conteneur ne gère pas correctement le signal SIGTERM lors de l'arrêt, le Pod peut rester dans l'état Terminating.

1. Supprimez le Pod de force à l'aide de la commande kubectl delete pod <pod-name> --grace-period=0 --force.

2. Examinez les journaux containerd ou Docker sur le nœud du Pod pour approfondir l'investigation.

Cause possible

Description

Solution recommandée

Le nœud subit une pression liée aux ressources, telle que l'utilisation de la mémoire ou du disque.

Le nœud peut rencontrer une pression mémoire, une pression disque ou une pression PID.

• Vérifiez les taints du nœud à l'aide de la commande kubectl describe node <node name> | grep Taints. La sortie peut inclure :

  • Pression mémoire : le nœud possède le taint node.kubernetes.io/memory-pressure.

  • Pression disque : le nœud possède le taint node.kubernetes.io/disk-pressure.

  • Pression PID : le nœud possède le taint node.kubernetes.io/pid-pressure.

• L'état du Pod est l'un des suivants :

  • Evicted

  • ContainerStatusUnknown, et le champ reason du fichier YAML du Pod indique Evicted.

• Pression mémoire :

  • Ajustez la configuration des ressources du Pod selon vos besoins métier. Consultez la rubrique Gérer les Pods.

  • Mettez à niveau le nœud. Consultez la rubrique Mettre à l'échelle les ressources des nœuds.

• Pression disque :

  • Purgez régulièrement les journaux d'application des Pods sur le nœud afin de libérer de l'espace disque.

  • Étendez le disque du nœud. Consultez l'Étape 1 : Redimensionner un disque cloud.

• Pression PID : ajustez la configuration des ressources du Pod. Consultez la documentation Process ID Limits and Reservations.

Une éviction inattendue se produit.

Un taint NoExecute ajouté manuellement sur le nœud du Pod a provoqué une éviction inattendue.

Vérifiez la présence d'un taint NoExecute à l'aide de la commande kubectl describe node <node name> | grep Taints. Si un tel taint existe, supprimez-le.

L'éviction ne se déroule pas comme prévu.

• --pod-eviction-timeout : les Pods sur un nœud défaillant sont évincés après cette période de délai d'attente. La valeur par défaut est de 5 minutes.

• --node-eviction-rate : nombre de Pods évincés d'un nœud par seconde. La valeur par défaut est 0,1, ce qui signifie qu'au maximum un Pod est évacué d'un nœud toutes les 10 secondes.

• --secondary-node-eviction-rate : taux d'éviction secondaire des nœuds. Si trop de nœuds d'un cluster tombent en panne, le taux d'éviction est réduit à cette valeur. La valeur par défaut est 0,01.

• --unhealthy-zone-threshold : seuil de zone de disponibilité non saine. La valeur par défaut est 0,55. Lorsque la fraction de nœuds défaillants dans une zone de disponibilité dépasse ce seuil, la zone est considérée comme non saine.

• --large-cluster-size-threshold : seuil de taille de cluster important. La valeur par défaut est 50. Un cluster est considéré comme important lorsqu'il compte plus de 50 nœuds.

Dans un petit cluster (50 nœuds ou moins), si plus de 55 % des nœuds tombent en panne, l'éviction des Pods s'arrête. Consultez la documentation Rate limits on eviction.

Dans un grand cluster (plus de 50 nœuds), si la fraction de nœuds non sains dépasse le seuil --unhealthy-zone-threshold (par défaut 0,55), le taux d'éviction chute à la valeur --secondary-node-eviction-rate (par défaut 0,01 Pod par seconde). Consultez la documentation Rate limits on eviction.

Un Pod est fréquemment replanifié sur son nœud d'origine après avoir été évacué.

Le kubelet évacue les Pods en fonction de l'utilisation réelle des ressources, tandis que le planificateur place les Pods en fonction des demandes de ressources. Comme une éviction libère des ressources, le planificateur peut replanifier un Pod sur le même nœud si ses demandes restent compatibles avec les ressources disponibles.

Ajustez les demandes de ressources du Pod pour qu'elles correspondent aux ressources allouables du nœud. Consultez la rubrique Définir les ressources CPU et mémoire pour un conteneur. Activez le profilage des ressources pour obtenir des valeurs recommandées pour les demandes et les limites.