7.3. Résolution des problèmes liés à l'exécution du conteneur CRI-O

Procédure

1. Examinez l'état du CRI-O en interrogeant le service crio systemd sur un nœud, à l'intérieur d'un pod de débogage.

   1. Démarrer un pod de débogage pour un nœud :

      $ oc debug node/my-node

   2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host

      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

   3. Vérifiez si le service crio systemd est actif sur le nœud :

      # systemctl is-active crio

   4. Affiche un résumé plus détaillé de l'état de crio.service:

      # systemctl status crio.service

Procédure

1. Rassembler les journaux de l'unité CRI-O journald. L'exemple suivant collecte les journaux de tous les nœuds du plan de contrôle (au sein de la grappe) :

   $ oc adm node-logs --role=master -u crio

2. Rassemble les journaux de l'unité CRI-O journald d'un nœud spécifique :

   $ oc adm node-logs <node_name> -u crio

3. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant SSH à la place. Remplacez <node>.<cluster_name>.<base_domain> par les valeurs appropriées :

   $ ssh core@<node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

   Note

   Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

Procédure

1. Utiliser cordon sur le nœud. Cela permet d'éviter qu'une charge de travail ne soit planifiée si le nœud passe à l'état Ready. Vous saurez que la planification est désactivée lorsque SchedulingDisabled apparaîtra dans votre section Statut :

   $ oc adm cordon <nodename>

2. Drainer le nœud en tant qu'utilisateur cluster-admin :

   oc adm drain <nodename> --ignore-daemonsets --delete-emptydir-data

   Note

   L'attribut terminationGracePeriodSeconds d'un pod ou d'un modèle de pod contrôle la période de terminaison gracieuse. Cet attribut est fixé par défaut à 30 secondes, mais peut être personnalisé par application si nécessaire. S'il est fixé à plus de 90 secondes, le module peut être marqué comme SIGKILLed et ne pas se terminer avec succès.

3. Lorsque le nœud revient, connectez-vous à nouveau au nœud via SSH ou la console. Ensuite, connectez-vous à l'utilisateur root :

   $ ssh core@node1.example.com
   $ sudo -i

4. Arrêter manuellement le kubelet :

   # systemctl stop kubelet

5. Arrêter les conteneurs et les cosses :

   1. Utilisez la commande suivante pour arrêter les pods qui ne se trouvent pas dans le site HostNetwork. Ils doivent être supprimés en premier car leur suppression dépend des pods du plugin de mise en réseau, qui se trouvent dans le site HostNetwork.

      .. for pod in $(crictl pods -q); do if [[ "$(crictl inspectp $pod | jq -r .status.linux.namespaces.options.network)" != "NODE" ]]; then crictl rmp -f $pod; fi; done

   2. Arrêter toutes les autres nacelles :

      # crictl rmp -fa

6. Arrêter manuellement les services crio :

   # systemctl stop crio

7. Après avoir exécuté ces commandes, vous pouvez effacer complètement le stockage éphémère :

   # crio wipe -f

8. Démarrer le service crio et kubelet :

   # systemctl start crio
   # systemctl start kubelet

9. Vous saurez que le nettoyage a fonctionné si les services crio et kubelet sont démarrés et si le nœud est dans l'état Ready:

   $ oc get nodes

   Exemple de sortie

   NAME				    STATUS	                ROLES    AGE    VERSION
   ci-ln-tkbxyft-f76d1-nvwhr-master-1  Ready, SchedulingDisabled   master	 133m   v1.25.0

10. Marquez le nœud comme étant planifiable. Vous saurez que l'ordonnancement est activé lorsque SchedulingDisabled n'aura plus d'état :

    oc adm uncordon <nodename> $ oc adm uncordon <nodename>

    Exemple de sortie

    NAME				     STATUS	      ROLES    AGE    VERSION
    ci-ln-tkbxyft-f76d1-nvwhr-master-1   Ready            master   133m   v1.25.0