Si un ou plusieurs noeuds worker sont affectés

Si seuls certains, mais pas tous, des noeuds worker de votre cluster sont à l'état Critical ou NotReady, procédez comme suit pour déterminer la cause de l'interruption et résoudre le problème. Si les noeuds worker concernés proviennent tous de la même zone, du même sous-réseau ou du même réseau local virtuel, passez à la section suivante.

1. Obtenir les détails du nœud spécifique.

   oc describe node <node-IP-address>
   

2. Dans la sortie, consultez la section Conditions pour déterminer si le noeud rencontre des problèmes de mémoire, de disque ou de PID. Ces informations peuvent indiquer que le noeud est à court de ce type de ressource. Cette situation peut se produire pour l'une des raisons suivantes :

   • Épuisement de la mémoire ou de l'unité centrale causé par l'absence de demandes et de limites appropriées sur vos pods.
   • Les disques worker sont saturés, parfois en raison de journaux de pod volumineux ou de la sortie de pod sur le noeud lui-même.
   • Fuites de mémoire lentes qui s'accumulent au fil du temps, ce qui peut entraîner des problèmes pour les agents qui n'ont pas été mis à jour depuis plus d'un mois.
   • Bogues et pannes affectant le noyau Linux.

3. Si vous êtes en mesure de déterminer la cause du problème à partir des informations de la section Conditions, suivez les étapes de la rubrique Débogage des noeuds worker pour isoler la charge de travail du problème.

4. Si les étapes précédentes ne permettent pas de résoudre le problème, rechargez ou remplacez les noeuds worker concernés un par un.

Si tous les noeuds worker d'une zone unique, d'un sous-réseau ou d'un VLAN sont affectés

Si tous les nœuds travailleurs d'une zone, d'un sous-réseau ou d'un VLAN sont dans un état Critical ou NotReady, alors que tous les autres nœuds travailleurs de la grappe fonctionnent normalement, il se peut qu'un composant de mise en réseau présente un problème. Suivez les étapes de la rubrique Si tous les noeuds worker d'un cluster sont affectés, en particulier les étapes concernant les composants réseau pouvant affecter la zone, le sous-réseau ou le réseau local virtuel, tels que les règles de pare-feu ou de passerelle, les listes de contrôle d'accès ou les routes personnalisées, ou les règles réseau Calico et Kubernetes.

Si vous avez vérifié vos composants de mise en réseau et que vous ne parvenez toujours pas à résoudre le problème, collectez vos données de noeud worker et ouvrez un ticket de demande de service.

Si tous les noeuds worker d'un cluster sont affectés

Si tous les noeuds worker de votre cluster affichent Critical ou NotReady en même temps, il se peut qu'il y ait un problème avec le cluster apiserver ou le chemin de mise en réseau entre les noeuds worker et apiserver. Suivez ces étapes de traitement des incidents pour déterminer la cause et résoudre le problème.

Certaines étapes sont spécifiques à un domaine spécialisé, tel que la mise en réseau ou l'automatisation. Consultez l'administrateur ou l'équipe appropriée de votre organisation avant d'effectuer ces étapes.

1. Vérifiez si des modifications récentes apportées à votre cluster, à votre environnement ou à votre compte ont un impact sur vos noeuds worker. Si tel est le cas, annulez les modifications, puis vérifiez le statut du noeud worker pour déterminer si les modifications ont provoqué le problème.

   • Pour les clusters classiques, vérifiez tout pare-feu ou passerelle, tel que Virtual Router Appliance, Vyatta ou Juniper, qui gère le trafic des agents de cluster. Recherchez les modifications ou les problèmes susceptibles de supprimer ou de rediriger le trafic des agents de cluster.
   • Pour les clusters de VPC, vérifiez si des modifications ont été apportées au groupe de sécurité par défaut et aux listes de contrôle d'accès sur le VPC ou les noeuds worker. Si des modifications ont été apportées, assurez-vous que vous autorisez tout le trafic nécessaire depuis les noeuds worker du cluster vers le maître cluster, le registre de conteneur et d'autres services critiques. Pour plus d'informations, voir Comprendre la mise en réseau des clusters VPC sécurisés par défaut, Créer et gérer des groupes de sécurité VPC et Contrôler le trafic à l'aide d'ACL.
   • Pour les clusters de VPC, recherchez dans les règles de routage personnalisées les modifications susceptibles de bloquer le trafic provenant du cluster apiserver.
   • Vérifiez les règles réseau Calico ou Kubernetes qui sont appliquées au cluster et assurez-vous qu'elles ne bloquent pas le trafic du noeud worker vers le cluster apiservice, le registre de conteneur ou d'autres services critiques.

2. Vérifiez si les applications, la sécurité ou les composants de surveillance de votre cluster surchargent le cluster apiserver avec des demandes, ce qui peut entraîner des interruptions pour vos noeuds worker.

3. Si vous avez récemment ajouté des composants à votre cluster, supprimez-les. Si vous avez apporté des modifications à des composants existants de votre cluster, annulez les modifications. Ensuite, vérifiez le statut de vos noeuds worker pour voir si les nouveaux composants ou les modifications étaient à l'origine du problème.

4. Recherchez les modifications sur les webhooks de cluster, qui peuvent interrompre les demandes apiserver ou bloquer la capacité d'un noeud worker à se connecter à apiserver. Vérifier les webhooks qui rejettent les demandes. Exécutez la commande suivante pour obtenir une liste des webhooks qui rejettent les demandes.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

5. Examinez la sortie des webhooks qui ont le statut " rejected="true"

6. Supprimez et régénérez les secrets d'extraction Docker personnalisés, qui, s'ils sont mal configurés, peuvent empêcher les noeuds worker d'extraire des images des registres Docker.

   1. Exécutez les commandes oc delete secret -n openshift pull-secret et oc delete secret -n openshift-config pull-secret pour supprimer les secrets d'extraction Docker personnalisés.

       oc delete secret -n openshift pull-secret
       ```
       ```sh {: pre}
       oc delete secret -n openshift-config pull-secret
       ```
   1. Attendez que le cluster régénère les secrets d'extraction Docker personnalisés. Les composants mal configurés ne sont plus présents dans les secrets d'extraction régénérés.
   

7. Vérifiez l'état de vos nœuds de travail. S'ils sont à l'état Normal, ajoutez à nouveau les composants supprimés et recréez les modifications annulées, une par une, jusqu'à ce que vous puissiez déterminer la configuration ou le composant à l'origine de l'interruption du noeud worker.

8. Si le problème n'est toujours pas résolu, suivez les étapes pour collecter vos données de noeud worker et ouvrir un ticket de demande de service.

Si les noeuds worker passent d'un état normal à un état critique

Si vos noeuds worker passent d'un état Normal à un état Critical ou NotReady, recherchez dans les composants suivants des problèmes ou des modifications récentes susceptibles d'interrompre vos noeuds worker.

1. Pour les clusters classiques, vérifiez vos pare-feux ou vos passerelles. S'il existe une limite de bande passante ou tout type de dysfonctionnement, résolvez le problème. Ensuite, vérifiez à nouveau vos noeuds worker.

2. Vérifiez si les applications, la sécurité ou les composants de surveillance de votre cluster surchargent le cluster apiserver avec des demandes, ce qui peut entraîner des interruptions pour vos noeuds worker.

3. Si vous avez récemment ajouté des composants à votre cluster, supprimez-les. Si vous avez apporté des modifications à des composants existants de votre cluster, annulez les modifications. Ensuite, vérifiez le statut de vos noeuds worker pour voir si les nouveaux composants ou les modifications étaient à l'origine du problème.

4. Recherchez les modifications sur les webhooks de cluster, qui peuvent interrompre les demandes apiserver ou bloquer la capacité d'un noeud worker à se connecter à apiserver. Vérifier les webhooks qui rejettent les demandes. Exécutez la commande suivante pour obtenir une liste des webhooks qui rejettent les demandes.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

5. Examinez la sortie des webhooks qui ont le statut " rejected="true"

6. Si le problème n'est toujours pas résolu, suivez les étapes pour collecter vos données de noeud worker et ouvrir un ticket de demande de service.

Avant de commencer

Vérifiez les conditions de vos noeuds worker et de votre cluster avant de collecter des données.

1. Vérifiez le niveau d'UC et de mémoire de vos noeuds. Si un noeud dépasse 80% de l'utilisation de l'unité centrale ou de la mémoire, envisagez de mettre à disposition davantage de noeuds ou de réduire votre charge de travail.

   oc top node
   

   Exemple de sortie

   NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
   10.001.1.01     640m         16%    6194Mi          47%       
   10.002.2.02     2686m        68%    4024Mi          30%       
   10.003.3.03     2088m        53%    10735Mi         81%  
   

2. Recherchez les modifications sur les webhooks de cluster, qui peuvent interrompre les demandes apiserver ou bloquer la capacité d'un noeud worker à se connecter à apiserver. Vérifier les webhooks qui rejettent les demandes. Exécutez la commande suivante pour obtenir une liste des webhooks qui rejettent les demandes.

   kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
   

3. Examinez la sortie des webhooks qui ont le statut " rejected="true"

Rassemblement de données

Suivez les étapes pour collecter les données de noeud worker appropriées.

1. Obtenez les détails de chaque noeud. Sauvegardez les détails de sortie à inclure dans votre ticket de demande de service.

   oc describe node <node-ip-address>
   

2. Montrez qu'il n'y a plus de webhooks de mutation ou de validation dans votre cluster en obtenant les détails du webhook. Sauvegardez le résultat de la commande à inclure dans votre ticket de demande de service. Notez que les webhooks de mutation suivants peuvent être conservés et n'ont pas besoin d'être supprimés: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.

   kubectl get mutatingwebhookconfigurations
   

   kubectl get validatingwebhookconfigurations
   

3. Clusters classiques: accédez à la console KVM pour l'un des noeuds worker affectés. Ensuite, collectez les journaux et la sortie appropriés.

   1. Procédez comme suit pour accéder à la console KVM.
   2. Collectez et sauvegardez les journaux suivants. Consultez les journaux pour connaître les causes possibles de l'interruption du noeud worker, telles qu'un manque de mémoire ou d'espace disque, le passage du disque en mode lecture seule et d'autres problèmes.
      • /var/log/boot.log
      • /var/log/calico/cni/cni.log
      • /var/log/crio.log
      • /var/log/cron
      • /var/log/messages
      • /var/log/secure
   3. Exécutez les commandes suivantes et sauvegardez la sortie à associer au ticket de demande de service.
      • ps -aux # Processus en cours de vidage
      • df -H # Informations sur l'utilisation du disque de vidage
      • vmstat # Informations sur l'utilisation de la mémoire de vidage
      • lshw # Informations sur le matériel de cliché
      • last -Fxn2 shutdown reboot # déterminer si le dernier redémarrage a été approprié ou non
      • mount | grep -i "(ro" # pour exclure le problème de disque en lecture seule. REMARQUE: tmpfs le fait d'être ro est correct
      • touch /this # pour exclure le problème de disque en lecture seule

4. Clusters VPC: Recueillez l'utilisation des ressources des nœuds de travail en utilisant la commande kubectl top comme dans l'exemple suivant.

   kubectl top nodes
   

   L'exemple de sortie montre l'utilisation de l'unité centrale en millicores (m) et l'utilisation de la mémoire en mégaoctets (Mi).

   NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
   k8s-node-1      250m              12%    800Mi                         40%
   k8s-node-2      180m               9%     600Mi                         30%
   k8s-node-3      250m               22%    700Mi                        50%
   

   NOM

   Nom du noeud.

   Unités centrales (cœurs)

   L'utilisation actuelle du CPU en millicores (m). 1000m équivaut à 1 cœur.

   CPU % DE LA POPULATION

   Pourcentage de la capacité totale de l'unité centrale utilisée sur le nœud.

   Mémoire (octets)

   L'utilisation actuelle de la mémoire en MiB (mégaoctets) ou GiB (gigaoctets).

   MEMOIRE

   Pourcentage de la capacité totale de la mémoire utilisée.

   Un nœud dont le pourcentage de CPU ou de mémoire est élevé (supérieur à 80 %) peut être surchargé et nécessiter des ressources supplémentaires. Un nœud dont le pourcentage de CPU ou de mémoire est faible (moins de 20 %) peut être sous-utilisé, ce qui indique qu'il est possible de redistribuer la charge de travail. Si un nœud atteint une utilisation de 100 % du CPU ou de la mémoire, les nouvelles charges de travail risquent de ne pas être planifiées ou de voir leurs performances se dégrader.

5. Collecter l'utilisation des ressources des pods en utilisant la commande suivante.

   kubectl top pods --all-namespaces
   

   Exemple de sortie

   NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
   default            my-app-564bc58dad-hk5gn       120m            256Mi
   default             my-db-789d9c6c4f-tn7mv         300m            512Mi
   

   NOM

   Nom du pod.

   Unités centrales (cœurs)

   Le total de l'unité centrale utilisée par le pod dans tous ses conteneurs.

   Mémoire (octets)

   La mémoire totale utilisée par le pod dans tous ses conteneurs.

   Si l'utilisation de l'unité centrale d'un pod est élevée, il se peut qu'il subisse un étranglement de l'unité centrale, ce qui affecte les performances. Si l'utilisation de la mémoire d'un pod est proche de sa limite, il risque de rencontrer des erreurs OOM (Out of Memory), qui Kubernetes mettent fin aux processus afin de libérer de la mémoire. Un pod avec une faible utilisation de ressources peut avoir des demandes sur-allouées, ce qui entraîne un gaspillage de ressources.

6. Vérifiez les mesures au niveau du conteneur en exécutant la commande top pod.

   kubectl top pod pod-a --containers -n appns
   ```sh
   {: pre}
   Example output
   ```sh
   NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
   pod-a            app-container        100m         300Mi
   pod-a            db-container           50m          200Mi
   ```sh
   {: screen}
   
   

7. La commande kubectl top n'indique que l'utilisation réelle, et non les ressources demandées ou limitées. Pour comparer et analyser les résultats de la commande top, vérifiez la spécification du pod à l'aide de la commande suivante.

   kubectl describe pod <pod-name> -n <namespace>
   

   Exemple de sortie

   Containers:
    app-container:
      Requests:
     cpu: 250m
     memory: 512Mi
     Limits:
     cpu: 500m
     memory: 1Gi
   

   Si l'utilisation du processeur ou de la mémoire dépasse les demandes, cela peut indiquer un sous-provisionnement, entraînant des problèmes de performance. Si l'utilisation est proche des limites, le conteneur peut être ralenti ou interrompu lorsque les ressources sont limitées. Si l'utilisation est nettement inférieure aux demandes, le pod peut être surprovisionné, ce qui entraîne un gaspillage de ressources.

8. Identifier les pods qui consomment le plus de CPU.

   kubectl top pod --all-namespaces | sort -k3 -nr | head -10
   

9. Identifier les pods qui consomment beaucoup de mémoire.

   kubectl top pod --all-namespaces | sort -k4 -nr | head -10
   

10. Surveiller l'utilisation des ressources par les démons système. DaemonSets, tels que kube-proxy ou des agents de surveillance, peuvent consommer des ressources inattendues.

    kubectl top pod -n kube-system
    ```sh
    {: pre}
    
    

11. Si certains modules du système consomment trop de CPU ou de mémoire, des demandes de réglage et des limites peuvent s'avérer nécessaires. Pour suivre les changements de ressources en continu, utilisez la commande watch.

    watch -n 5 kubectl top pod --all-namespaces
    ```sh
    {: pre}
    This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.
    
    

12. Consultez le site OOMKilled pour connaître les événements qui s'y déroulent. Lorsque Kubernetes rapporte OOMKilled, le pod a dépassé sa limite de mémoire et a été interrompu. Le statut du pod passe à crashloopbackoff.

    kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
    

13. Recherchez les messages OOM dans les journaux.

    kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"
    

14. Vérifier le dernier état du conteneur pour OOM.

    kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"
    

Collecte des journaux des nœuds de travail

Suivez les étapes ci-dessous pour accéder au travailleur et collecter les journaux du nœud du travailleur.

1. Rassemblez et sauvegardez les fichiers journaux suivants. Consultez les journaux pour connaître les causes possibles de l'interruption du noeud worker, telles qu'un manque de mémoire ou d'espace disque, le passage du disque en mode lecture seule et d'autres problèmes.

   • /var/log/containerd.log
   • /var/log/kern.log
   • /var/log/kube-proxy.log
   • /var/log/syslog
   • /var/log/kubelet.log

2. Exécutez les commandes suivantes et sauvegardez la sortie à associer au ticket de demande de service.

   Obtenir des statistiques sur les conteneurs (nécessite un accès SSH au nœud).

   crictl stats
   

   Obtenir des statistiques détaillées pour un conteneur spécifique.

   crictl stats --id <container-id> --output json
   

   Exécutez la commande pour extraire les processus en cours.

   ps -aux
   

   Obtenez une vue dynamique et en temps réel des processus en cours et des tâches gérées par le noyau, ainsi que de l'utilisation des ressources, y compris l'utilisation de l'unité centrale et de la mémoire.

   top
   

   Obtenir l'état actuel du système.

   htop
   

   Obtenez un rapport de suivi complet avec des données historiques.

   atop
   

   Obtenir des informations en temps réel sur les processus du système.

   btop
   

   Obtenir les détails de la connexion au réseau.

   netstat
   

   Obtenir des informations sur l'utilisation du disque.

   df -H
   

   Lancez vmstat pour obtenir des rapports sur les processus, la mémoire, la pagination, les entrées-sorties de blocs, les pièges et l'activité du processeur. Cette commande permet d'obtenir les informations à intervalles de 2 secondes, 5 fois.

   vmstat 2 5
   

   Exécutez le site iostat pour recueillir des statistiques sur l'utilisation des disques, notamment sur le débit, l'utilisation, la longueur des files d'attente et les taux de transaction.

   iostat -x 1 5
   

   Collecter des informations sur le matériel.

   lshw
   

   Pour savoir si le dernier redémarrage s'est fait de manière gracieuse ou non, utilisez la commande ci-dessous.

   last -Fxn2 shutdown reboot
   

   Pour écarter le problème du disque, vérifiez qu'il est accessible en écriture.

   mount | grep -i "(ro"
   touch /this
   

3. Si le problème persiste, ouvrez un ticket d'assistance et joignez tous les résultats enregistrés dans les étapes précédentes.