Container Service for Kubernetes:Pod troubleshooting

Message d'erreur

Description

Solution

no nodes available to schedule pods.

Le cluster ne dispose d'aucun nœud disponible pour la planification des pods.

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 aux taints. 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 est considéré comme non planifiable si la somme des requests de ressources allouées a atteint sa capacité, même si l'utilisation réelle du CPU ou de la mémoire est faible.

Sur la page de détails du cluster cible, accédez à Nodes > Nodes et vérifiez le taux d'allocation des requests de CPU ou de 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 des nœuds, consultez la section Utilisation de kubectl pour afficher l'utilisation des ressources des nœuds.

• Optimisez la configuration des ressources :

  • Si l'utilisation des ressources d'un nœud est systématiquement inférieure à ses requests, cela indique un gaspillage des ressources. Vous pouvez réduire la configuration des requests pour la charge de travail. Pour plus d'informations, consultez la section 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 vos conteneurs métiers afin de réduire le nombre de réplicas pendant les heures creuses, ce qui diminuera la consommation globale de ressources.

• Nettoyez les charges de travail inutiles : Mettez hors service ou réduisez l'échelle des 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 dans le cluster ne correspondent pas à la politique d'affinité de nœud (nodeAffinity/nodeSelector) déclarée pour le pod. Pour plus d'informations, consultez la documentation 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, recherchez 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 lors de la création d'un déploiement via Create, recherchez 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 sélecteurs Selector ont une relation logique ET, tandis que plusieurs règles 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 déploiement cible.

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

   Exemple YAML

   NodeAffinity

   Les politiques d'affinité sont divisées en affinité stricte (requiredDuringSchedulingIgnoredDuringExecution) et affinité souple (preferredDuringSchedulingIgnoredDuringExecution). L'affinité stricte spécifie une règle qui doit être respectée, tandis que l'affinité souple 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 répondent aux 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é des règles 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 de libellé réelle, 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 Create Deployment, onglet Advanced, recherchez 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 sélecteurs Selector ont une relation logique ET, tandis que plusieurs règles 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érables. 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 approvisionné statiquement, configurez l'affinité de nœud du pod pour garantir qu'il soit planifié sur un nœud situé dans la même zone que le PV.

• Pour un PV approvisionné 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 la section 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 l'un des types 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'un des taints du nœud.

• Si le taint a été ajouté manuellement, vous pouvez supprimer le taint involontaire. Si le taint ne peut pas être supprimé, vous pouvez configurer une tolération correspondante pour le pod. Pour plus d'informations, consultez la documentation Taints and Tolerations et la section Gestion des libellés et des taints des nœuds.

• Si le taint a été ajouté automatiquement par le système, résolvez le problème sous-jacent comme décrit ci-dessous et attendez que le pod soit replanifié.

  Afficher les taints ajoutés 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 au statut Ready du nœud défini sur 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é disponible réelle du nœud, la planification du pod échouera.

2. Exécutez la commande kubectl describe node | grep -A10 Capacity pour afficher la capacité totale de stockage éphémère sur chaque nœud. Si la capacité est insuffisante, augmentez la taille du 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 du PVC et du PV afin d'approfondir le diagnostic. Pour plus d'informations, consultez la section 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 indiqué dans le champ spec.imagePullSecrets du fichier YAML du workload existe.

Avec Container Registry (ACR), vous pouvez utiliser un assistant d'identification pour télécharger des images sans mot de passe. Pour plus d'informations, consultez la section 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 le champ spec.containers.image du fichier YAML du pod est correcte. Si elle est incorrecte, mettez-la à jour.

2. Si l'adresse est correcte, vérifiez la connectivité réseau entre le nœud où s'exécute le pod et le registre d'images. Connectez-vous au nœud (pour plus d'informations, consultez la section 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 sur le nœud est insuffisant.

Connectez-vous au nœud où s'exécute le pod (pour plus d'informations, consultez la section Choisir une méthode de connexion à distance ECS) et exécutez la commande df -h pour vérifier l'espace disque. Si le disque est plein, augmentez sa capacité. Pour plus d'informations, consultez la section Étape 1 : Augmenter la capacité d'un cloud disk.

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 la section Créer une application à partir d'un registre d'images privé.

3. S'il est impossible de modifier le certificat, configurez 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 applique un délai d'expiration par défaut pour le téléchargement d'images. Si le téléchargement ne progresse pas pendant une période donnée, Kubernetes considère que l'opération a échoué ou ne répond pas et annule la tâche.

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

2. Connectez-vous au nœud où s'exécute le pod (pour plus d'informations, consultez la section Choisir une méthode de connexion à distance ECS) et exécutez les commandes 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 où s'exécute le pod (pour plus d'informations, consultez la section 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 stratégie de réseau public du nœud, y compris les configurations des entrées SNAT et des Elastic IP Addresses (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

Délai d'expiration de la connexion 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 sources étrangères via Container Registry. Pour obtenir des instructions, consultez la section Synchroniser des images à l'aide de l'abonnement aux artefacts.

• Créez une instance Global Accelerator (GA) pour télécharger directement des images via son réseau d'accélération globale. Pour plus de détails, consultez la section 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 requêtes 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 débit de téléchargement d'images de kubelet a peut-être été déclenché.

Ajustez les paramètres 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 pour un pool de nœuds.

Message d'erreur

Description

Solution

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

Le pod contient M conteneurs d'initialisation. N d'entre eux sont terminés, mais les M-N conteneurs d'initialisation restants n'ont pas pu démarrer.

1. Exécutez la commande kubectl describe pod -n <ns> <pod name> pour afficher les événements du pod et vérifier les problèmes liés aux conteneurs d'initialisation non démarrés.

2. Exécutez la commande kubectl logs -n <ns> <pod name> -c <container name> pour afficher les journaux des conteneurs d'initialisation non démarrés et les utiliser pour résoudre le problème.

3. Examinez la configuration du pod, telle que les paramètres de vérification d'intégrité, afin de vous assurer que les conteneurs d'initialisation sont configurés correctement.

Pour plus d'informations sur les conteneurs d'initialisation, consultez la section 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

Ce comportement est attendu en raison de la conception du plugin réseau Flannel.

Mettez à niveau le composant Flannel vers la version v0.15.1.11-7e95fe23-aliyun ou ultérieure. Pour plus d'informations, consultez la section 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. Nous vous recommandons d'utiliser la dernière version du cluster. Pour plus d'informations, consultez la section Mettre à niveau manuellement un cluster.

Des défauts dans containerd et runC provoquent ce problème.

Pour un correctif d'urgence, consultez la section 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 elastic network interfaces (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 ENI.

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

2. Si la création du pod échoue toujours après un long délai et que cette erreur persiste, le pilote n'a probablement pas pu charger l'ENI en raison d'une mémoire haute insuffisante. Redémarrez l'instance ECS pour résoudre ce problème. Pour plus d'informations, consultez la section Redémarrer une instance.

• 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 réussi à demander une adresse IP au vSwitch.

1. Affichez les journaux du conteneur Terway dans le pod du composant Terway sur le nœud pour vérifier le processus d'allocation ENI.

2. Exécutez la commande kubectl logs -n kube-system <terwayPodName > -c terway | grep <podName> pour afficher les informations ENI du pod Terway. Obtenez l'ID de requête pour la demande d'adresse IP et le message d'erreur OpenAPI.

3. Utilisez l'ID de requête 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 le workload anormal est déployé.

2. Exécutez la commande docker ps -a | grep $podName. Si le conteneur n'a aucun processus persistant, il se termine avec le code de statut 0.

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

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

• Configuration de la sonde de vivacité : Sur la page Edit du Workloads cible, vérifiez que le chemin de la requête de vérification d'intégrité (par exemple, /healthz) et le port correspondent à ceux fournis par l'application. Augmentez la valeur de 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 vérification d'intégrité fonctionne correctement.

• Résoudre les problèmes applicatifs : Enquêtez sur le problème en consultant les Events et les Log 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 entraîné le redémarrage de l'application.

• Configuration de la sonde de démarrage : Sur la page Edit du Workloads cible, vérifiez que le chemin de la requête de vérification d'intégrité (par exemple, /healthz) et le port correspondent à ceux fournis par l'application. Si l'application met beaucoup de temps à démarrer, augmentez la valeur de 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 vérification d'intégrité fonctionne correctement.

• Résoudre les problèmes applicatifs : 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.

• Augmentez la capacité du cloud disk. Pour plus d'informations, consultez la section Étape 1 : Augmenter la capacité d'un cloud disk.

• Supprimez 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.

Échec du démarrage sans information d'événement.

Ce problème survient lorsqu'un conteneur nécessite plus de ressources que ses limites déclarées, ce qui entraîne son échec.

Vérifiez si la configuration des ressources du pod est correcte. Vous pouvez activer le profilage des ressources pour obtenir les 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 oblige 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 requiert hostNetwork: true, configurez l'anti-affinité des pods pour vous assurer que les pods du même replica set sont 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.

Le workload monte un Secret, mais la valeur dans le Secret n'est pas encodée en Base64.

• Créez le Secret dans la console, où les valeurs sont automatiquement encodées en Base64. Pour plus d'informations, consultez la section 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 disponibilité a échoué, empêchant le pod cible de recevoir du trafic.

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

  Vous pouvez désactiver temporairement la sonde Readiness, vous connecter au terminal du pod ou à son hôte et utiliser une commande, telle que curl, pour vérifier que la méthode de vérification d'intégrité répond correctement.

• Résoudre les problèmes applicatifs : 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 entraîne le redémarrage du conteneur. Cette erreur ne devrait pas aboutir à 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 du système d'exploitation

Consultez le journal du noyau situé à l'emplacement /var/log/messages sur le nœud du Pod. Si le journal indique qu'un processus a été arrêté mais ne contient 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 Scale node resources et Schedule applications to specific nodes.

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

Niveau cgroup

Consultez le journal du noyau situé à l'emplacement /var/log/messages sur le nœud du Pod. Si le journal contient 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. Veillez à ce que l'utilisation réelle reste inférieure à 80 % des limites. Consultez Manage Pods et Scale node resources.

• Activez le resource profiling 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é une fois que le nœud quitte 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.

Exécutez la commande kubectl get pod -n <ns> <pod name> -o yaml pour afficher la configuration des finalizers du Pod et identifier la cause.

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.

Exécutez la commande kubectl get pod -n <ns> <pod name> -o yaml pour afficher la configuration du hook preStop du Pod et identifier la cause.

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

Si une période d'arrêt gracieux (terminationGracePeriodSeconds) est configurée pour un Pod, celui-ci 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 effectué un 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. Exécutez la commande kubectl delete pod <pod-name> --grace-period=0 --force pour supprimer de force le Pod et libérer ses ressources.

2. Consultez 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, telles que l'utilisation de la mémoire ou du disque.

Le nœud peut connaître une pression mémoire, une pression disque ou une pression PID.

• Exécutez la commande kubectl describe node <node name> | grep Taints. La sortie peut inclure les taints suivants :

  • 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.

• Le statut 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 en fonction de vos besoins métier. Pour plus d'informations, consultez Manage pods.

  • Mettez à niveau le nœud. Pour plus d'informations, consultez Scale node resources.

• Pression disque :

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

  • Augmentez la capacité du disque du nœud. Pour plus d'informations, consultez Step 1: Resize a cloud disk.

• Pression PID : Ajustez la configuration des ressources du Pod en fonction de vos besoins métier. Pour plus d'informations, consultez 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.

Exécutez la commande kubectl describe node <node name> | grep Taints pour vérifier si le nœud possède un taint NoExecute. Le cas échéant, 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. Pour plus d'informations, consultez 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 est réduit à la valeur de --secondary-node-eviction-rate (par défaut 0,01 Pod par seconde). Pour plus d'informations, consultez 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 tiennent toujours dans les ressources disponibles.

Assurez-vous que les demandes de ressources du Pod sont adaptées aux ressources allouables du nœud et ajustez-les si nécessaire. Pour plus d'informations, consultez Set CPU and memory resources for a container. Vous pouvez également activer le resource profiling pour obtenir des configurations recommandées pour les demandes et les limites de vos conteneurs.