7.2. Vérification de l'état des nœuds

Procédure

1. Le kubelet est géré à l'aide d'un service systemd sur chaque nœud. Examinez l'état du kubelet en interrogeant le service systemd de kubelet dans un pod de débogage.

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

      $ oc debug node/my-node

      Note

      Si vous exécutez oc debug sur un nœud du plan de contrôle, vous trouverez les fichiers administratifs kubeconfig dans le répertoire /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs.

   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 d'OpenShift Container Platform 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 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 kubelet systemd est actif sur le nœud :

      # systemctl is-active kubelet

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

      # systemctl status kubelet

Procédure

1. Requête kubelet journald journaux d'unité des nœuds de cluster OpenShift Container Platform. L'exemple suivant interroge uniquement les nœuds du plan de contrôle :

   $ oc adm node-logs --role=master -u kubelet  1

   1

   Remplacer kubelet le cas échéant pour interroger d'autres journaux d'unité.

2. Collecte des journaux à partir de sous-répertoires spécifiques sous /var/log/ sur les nœuds de la grappe.

   1. Récupérer la liste des journaux contenus dans un sous-répertoire /var/log/. L'exemple suivant répertorie les fichiers de /var/log/openshift-apiserver/ sur tous les nœuds du plan de contrôle :

      $ oc adm node-logs --role=master --path=openshift-apiserver

   2. Inspecter un journal spécifique dans un sous-répertoire /var/log/. L'exemple suivant affiche le contenu de /var/log/openshift-apiserver/audit.log pour tous les nœuds du plan de contrôle :

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

   3. Si l'API n'est pas fonctionnelle, examinez les journaux sur chaque nœud en utilisant SSH à la place. L'exemple suivant est une queue /var/log/openshift-apiserver/audit.log:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

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