Chapitre 7. Résolution de problèmes

1. Les fichiers de configuration d'Ignition sont créés.
2. La machine d'amorçage démarre et commence à héberger les ressources distantes nécessaires au démarrage des machines du plan de contrôle.
3. Les machines du plan de contrôle récupèrent les ressources distantes de la machine d'amorçage et terminent le démarrage.
4. Les machines du plan de contrôle utilisent la machine bootstrap pour former un cluster etcd.
5. La machine d'amorçage démarre un plan de contrôle Kubernetes temporaire en utilisant le nouveau cluster etcd.
6. Le plan de contrôle temporaire planifie le plan de contrôle de production sur les machines du plan de contrôle.
7. Le plan de contrôle temporaire s'arrête et passe le contrôle au plan de contrôle de production.
8. La machine d'amorçage ajoute des composants OpenShift Container Platform dans le plan de contrôle de la production.
9. Le programme d'installation arrête la machine de démarrage.
10. Le plan de contrôle met en place les nœuds de travail.
11. Le plan de contrôle installe des services supplémentaires sous la forme d'un ensemble d'opérateurs.
12. Le cluster télécharge et configure les autres composants nécessaires au fonctionnement quotidien, y compris la création de machines de travail dans les environnements pris en charge.

Procédure

1. Vérifiez que le service haproxy systemd est actif :

   $ ssh <user_name>@<load_balancer> systemctl status haproxy

2. Vérifiez que l'équilibreur de charge écoute sur les ports requis. L'exemple suivant fait référence aux ports 80, 443, 6443 et 22623.

   • Pour les instances HAProxy fonctionnant sous Red Hat Enterprise Linux (RHEL) 6, vérifiez l'état des ports à l'aide de la commande netstat:

     $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

   • Pour les instances HAProxy fonctionnant sous Red Hat Enterprise Linux (RHEL) 7 ou 8, vérifiez l'état des ports à l'aide de la commande ss:

     $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

     Note

     Red Hat recommande la commande ss au lieu de netstat dans Red Hat Enterprise Linux (RHEL) 7 ou une version ultérieure. ss est fourni par le paquetage iproute. Pour plus d'informations sur la commande ss, consultez le Guide d'optimisation des performances de Red Hat Enterprise Linux (RHEL) 7.

3. Vérifiez que l'enregistrement DNS générique se résout vers l'équilibreur de charge :

   $ dig <wildcard_fqdn> @<dns_server>

Procédure

1. Observez le journal d'installation au fur et à mesure que l'installation progresse :

   $ tail -f ~/<installation_directory>/.openshift_install.log

2. Surveillez le journal bootkube.service journald unit log sur le nœud d'amorçage, après qu'il ait démarré. Cela permet d'avoir une visibilité sur le démarrage du premier plan de contrôle. Remplacez <bootstrap_fqdn> par le nom de domaine complet du nœud d'amorçage :

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   Note

   The bootkube.service log on the bootstrap node outputs etcd connection refused errors, indicating that the bootstrap server is unable to connect to etcd on control plane nodes. After etcd has started on each control plane node and the nodes have joined the cluster, the errors should stop.

3. Surveillez les journaux de l'unité kubelet.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité des agents des nœuds du plan de contrôle.

   1. Surveillez les journaux à l'aide de oc:

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

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

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

4. Surveillez les journaux de l'unité crio.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité d'exécution des conteneurs CRI-O sur les nœuds du plan de contrôle.

   1. Surveillez les journaux à l'aide de oc:

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

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

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

Procédure

1. Si vous avez accès à la console du nœud d'amorce, surveillez la console jusqu'à ce que le nœud atteigne l'invite de connexion.

2. Vérifier la configuration du fichier Ignition.

   • Si vous hébergez les fichiers de configuration d'Ignition en utilisant un serveur HTTP.

     1. Vérifier l'URL du fichier Ignition du nœud d'amorçage. Remplacer <http_server_fqdn> par le nom de domaine complet du serveur HTTP :

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

        1

        L'option -I renvoie uniquement l'en-tête. Si le fichier Ignition est disponible sur l'URL spécifiée, la commande renvoie l'état 200 OK. S'il n'est pas disponible, la commande renvoie l'état 404 file not found.

     2. Pour vérifier que le fichier Ignition a été reçu par le nœud d'amorçage, interrogez les journaux du serveur HTTP sur l'hôte d'accueil. Par exemple, si vous utilisez un serveur web Apache pour servir les fichiers Ignition, entrez la commande suivante :

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        Si le fichier Ignition bootstrap est reçu, le message de journal HTTP GET associé inclura un état de réussite 200 OK, indiquant que la demande a réussi.

     3. Si le fichier Ignition n'a pas été reçu, vérifiez que les fichiers Ignition existent et qu'ils disposent des autorisations de fichier et de serveur web appropriées sur l'hôte serveur directement.

   • Si vous utilisez un mécanisme de fournisseur de cloud pour injecter des fichiers de configuration Ignition dans les hôtes dans le cadre de leur déploiement initial.

     1. Examinez la console du nœud d'amorce pour déterminer si le mécanisme injecte correctement le fichier Ignition du nœud d'amorce.
3. Vérifier la disponibilité de l'unité de stockage assignée au nœud d'amorce.
4. Vérifiez qu'une adresse IP a été attribuée au nœud d'amorçage par le serveur DHCP.

5. Collecter les journaux de l'unité bootkube.service journald du nœud d'amorçage. Remplacez <bootstrap_fqdn> par le nom de domaine complet du nœud d'amorçage :

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   Note

   The bootkube.service log on the bootstrap node outputs etcd connection refused errors, indicating that the bootstrap server is unable to connect to etcd on control plane nodes. After etcd has started on each control plane node and the nodes have joined the cluster, the errors should stop.

6. Collecter les journaux des conteneurs du nœud d'amorçage.

   1. Collectez les journaux en utilisant podman sur le nœud d'amorçage. Remplacez <bootstrap_fqdn> par le nom de domaine complet du nœud d'amorçage :

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q) ; do sudo podman logs $pod ; done'

7. Si le processus d'amorçage échoue, vérifiez les points suivants.

   • Vous pouvez résoudre le problème api.<cluster_name>.<base_domain> à partir de l'hôte d'installation.
   • L'équilibreur de charge assure le proxy des connexions du port 6443 vers les nœuds d'amorçage et de plan de contrôle. Assurez-vous que la configuration du proxy est conforme aux exigences d'installation d'OpenShift Container Platform.

Procédure

1. Si vous avez accès à la console du nœud du plan de contrôle, surveillez la console jusqu'à ce que le nœud atteigne l'invite de connexion. Pendant l'installation, les messages du journal Ignition sont envoyés à la console.

2. Vérifier la configuration du fichier d'allumage.

   • Si vous hébergez les fichiers de configuration d'Ignition en utilisant un serveur HTTP.

     1. Vérifier l'URL du fichier Ignition du nœud du plan de contrôle. Remplacez <http_server_fqdn> par le nom de domaine complet du serveur HTTP :

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1

        1

        L'option -I renvoie uniquement l'en-tête. Si le fichier Ignition est disponible sur l'URL spécifiée, la commande renvoie l'état 200 OK. S'il n'est pas disponible, la commande renvoie l'état 404 file not found.

     2. Pour vérifier que le fichier Ignition a été reçu par le nœud du plan de contrôle, interrogez les journaux du serveur HTTP sur l'hôte serveur. Par exemple, si vous utilisez un serveur web Apache pour servir les fichiers Ignition :

        $ grep -is 'master.ign' /var/log/httpd/access_log

        Si le fichier maître Ignition est reçu, le message de journal HTTP GET associé inclura un état de réussite 200 OK, indiquant que la demande a réussi.

     3. Si le fichier Ignition n'a pas été reçu, vérifiez qu'il existe directement sur l'hôte serveur. Assurez-vous que les autorisations appropriées pour les fichiers et le serveur web sont en place.

   • Si vous utilisez un mécanisme de fournisseur de cloud pour injecter des fichiers de configuration Ignition dans les hôtes dans le cadre de leur déploiement initial.

     1. Examinez la console du nœud du plan de contrôle pour déterminer si le mécanisme injecte correctement le fichier d'ignition du nœud du plan de contrôle.
3. Vérifier la disponibilité de l'unité de stockage affectée au nœud du plan de contrôle.
4. Vérifiez qu'une adresse IP a été attribuée au nœud du plan de contrôle par le serveur DHCP.

5. Déterminer l'état des nœuds du plan de contrôle.

   1. Demande l'état des nœuds du plan de contrôle :

      $ oc get nodes

   2. Si l'un des nœuds du plan de contrôle n'atteint pas l'état Ready, récupérez une description détaillée du nœud :

      oc describe node <master_node>

      Note

      Il n'est pas possible d'exécuter les commandes oc si un problème d'installation empêche l'API OpenShift Container Platform de fonctionner ou si le kubelet ne fonctionne pas encore sur chaque nœud :

6. Déterminer le statut SDN de la plateforme OpenShift Container.

   1. Examinez l'état des jeux de démons sdn-controller, sdn et ovs dans l'espace de noms openshift-sdn:

      $ oc get daemonsets -n openshift-sdn

   2. Si ces ressources sont répertoriées comme Not found, examinez les pods dans l'espace de noms openshift-sdn:

      $ oc get pods -n openshift-sdn

   3. Examinez les journaux relatifs aux pods SDN de OpenShift Container Platform qui ont échoué dans l'espace de noms openshift-sdn:

      $ oc logs <sdn_pod> -n openshift-sdn

7. Déterminer l'état de la configuration du réseau de la grappe.

   1. Vérifiez si la configuration du réseau de la grappe existe :

      $ oc get network.config.openshift.io cluster -o yaml

   2. Si le programme d'installation n'a pas réussi à créer la configuration réseau, générez à nouveau les manifestes Kubernetes et examinez les messages :

      $ ./openshift-install create manifests

   3. Examinez l'état du pod dans l'espace de noms openshift-network-operator pour déterminer si le Cluster Network Operator (CNO) est en cours d'exécution :

      $ oc get pods -n openshift-network-operator

   4. Rassemble les journaux des pods de l'opérateur réseau de l'espace de noms openshift-network-operator:

      oc logs pod/<network_operator_pod_name> -n openshift-network-operator

8. Surveillez les journaux de l'unité kubelet.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité des agents des nœuds du plan de contrôle.

   1. Récupérez les journaux à l'aide de oc:

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

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

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.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>.

9. Récupérer les journaux de l'unité crio.service journald sur les nœuds du plan de contrôle, après leur démarrage. Cela permet de connaître l'activité d'exécution des conteneurs CRI-O sur les nœuds du plan de contrôle.

   1. Récupérez les journaux à l'aide de oc:

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

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant plutôt SSH :

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

10. Collecter les journaux dans des sous-répertoires spécifiques sous /var/log/ sur les nœuds du plan de contrôle.

    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

11. Examiner les journaux des conteneurs du nœud du plan de contrôle à l'aide de SSH.

    1. Dressez la liste des conteneurs :

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. Récupérer les journaux d'un conteneur en utilisant crictl:

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

12. Si vous rencontrez des problèmes de configuration des nœuds du plan de contrôle, vérifiez que le MCO, le point de terminaison MCO et l'enregistrement DNS fonctionnent. Le MCO (Machine Config Operator) gère la configuration du système d'exploitation pendant la procédure d'installation. Vérifiez également l'exactitude de l'horloge du système et la validité du certificat.

    1. Tester si le point de terminaison MCO est disponible. Remplacer <cluster_name> par les valeurs appropriées :

       $ curl https://api-int.<cluster_name>:22623/config/master

    2. Si le point d'accès ne répond pas, vérifiez la configuration de l'équilibreur de charge. Assurez-vous que le point d'accès est configuré pour fonctionner sur le port 22623.

    3. Vérifiez que l'enregistrement DNS du point d'extrémité MCO est configuré et qu'il se résout vers l'équilibreur de charge.

       1. Lancer une recherche DNS pour le nom du point de terminaison MCO défini :

          $ dig api-int.<cluster_name> @<dns_server>

       2. Effectuez une recherche inversée de l'adresse IP MCO attribuée sur l'équilibreur de charge :

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. Vérifiez que le MCO fonctionne directement à partir du nœud de démarrage. Remplacez <bootstrap_fqdn> par le nom de domaine pleinement qualifié du nœud d'amorce :

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

    5. L'heure de l'horloge système doit être synchronisée entre les nœuds de démarrage, maître et subordonné. Vérifiez l'heure de référence de l'horloge système de chaque nœud et les statistiques de synchronisation du temps :

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. Examiner la validité du certificat :

       openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

Procédure

1. Vérifier l'état des pods etcd.

   1. Examiner l'état des pods dans l'espace de noms openshift-etcd:

      $ oc get pods -n openshift-etcd

   2. Examiner l'état des pods dans l'espace de noms openshift-etcd-operator:

      $ oc get pods -n openshift-etcd-operator

2. Si l'un des pods répertoriés par les commandes précédentes n'affiche pas un état Running ou Completed, recueillez des informations de diagnostic pour le pod.

   1. Examiner les événements pour le pod :

      oc describe pod/<nom_du_pod> -n <espace_de_noms>

   2. Inspecter les journaux de bord de la nacelle :

      oc logs pod/<nom_du_pod> -n <espace-noms>

   3. Si le pod a plus d'un conteneur, la commande précédente créera une erreur et les noms des conteneurs seront fournis dans le message d'erreur. Examinez les journaux de chaque conteneur :

      oc logs pod/<nom_du_pod> -c <nom_du_conteneur> -n <espace_de_noms>

3. Si l'API n'est pas fonctionnelle, examinez les journaux des pods et des conteneurs etcd sur chaque nœud du plan de contrôle en utilisant SSH à la place. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées.

   1. Liste des pods etcd sur chaque nœud du plan de contrôle :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-

   2. Pour tout pod n'affichant pas l'état Ready, inspectez l'état du pod en détail. Remplacez <pod_id> par l'ID du pod indiqué dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>

   3. Liste des conteneurs liés à un pod :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

   4. Pour tous les conteneurs qui n'affichent pas le statut Ready, inspectez le statut du conteneur en détail. Remplacez <container_id> par les ID des conteneurs répertoriés dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. Examinez les journaux pour tous les conteneurs qui n'affichent pas le statut Ready. Remplacez <container_id> par les ID des conteneurs répertoriés dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

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

4. Valider la connectivité des serveurs DNS primaire et secondaire à partir des nœuds du plan de contrôle.

Procédure

1. Vérifiez que l'enregistrement DNS du serveur API dirige le kubelet sur les nœuds du plan de contrôle vers https://api-int.<cluster_name>.<base_domain>:6443. Assurez-vous que l'enregistrement fait référence à l'équilibreur de charge.
2. Assurez-vous que la définition du port 6443 de l'équilibreur de charge fait référence à chaque nœud du plan de contrôle.
3. Vérifier que des noms d'hôtes uniques de nœuds de plan de contrôle ont été fournis par DHCP.

4. Inspectez les journaux de l'unité kubelet.service journald sur chaque nœud du plan de contrôle.

   1. Récupérez les journaux à l'aide de oc:

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

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

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.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>.

5. Vérifier les messages d'expiration des certificats dans les journaux des kubelets du nœud du plan de contrôle.

   1. Récupérez le journal en utilisant oc:

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

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

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

Procédure

1. Si vous avez accès à la console du nœud de travail, surveillez la console jusqu'à ce que le nœud atteigne l'invite de connexion. Pendant l'installation, les messages du journal Ignition sont envoyés à la console.

2. Vérifier la configuration du fichier d'allumage.

   • Si vous hébergez les fichiers de configuration d'Ignition en utilisant un serveur HTTP.

     1. Vérifiez l'URL du fichier Ignition du nœud de travail. Remplacez <http_server_fqdn> par le nom de domaine complet du serveur HTTP :

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

        1

        L'option -I renvoie uniquement l'en-tête. Si le fichier Ignition est disponible sur l'URL spécifiée, la commande renvoie l'état 200 OK. S'il n'est pas disponible, la commande renvoie l'état 404 file not found.

     2. Pour vérifier que le fichier Ignition a été reçu par le nœud de travail, interrogez les journaux du serveur HTTP sur l'hôte HTTP. Par exemple, si vous utilisez un serveur web Apache pour servir les fichiers Ignition :

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        Si le fichier Ignition du travailleur est reçu, le message de journal HTTP GET associé inclura un état de réussite 200 OK, indiquant que la demande a réussi.

     3. Si le fichier Ignition n'a pas été reçu, vérifiez qu'il existe directement sur l'hôte serveur. Assurez-vous que les autorisations appropriées pour les fichiers et le serveur web sont en place.

   • Si vous utilisez un mécanisme de fournisseur de cloud pour injecter des fichiers de configuration Ignition dans les hôtes dans le cadre de leur déploiement initial.

     1. Examinez la console du nœud de travail pour déterminer si le mécanisme injecte correctement le fichier Ignition du nœud de travail.
3. Vérifier la disponibilité de l'unité de stockage assignée au nœud de travail.
4. Vérifiez qu'une adresse IP a été attribuée au nœud de travail par le serveur DHCP.

5. Déterminer l'état des nœuds de travail.

   1. Demande l'état du nœud :

      $ oc get nodes

   2. Récupérer une description détaillée du nœud pour tout nœud de travailleur n'affichant pas l'état Ready:

      oc describe node <worker_node> $ oc describe node <worker_node>

      Note

      Il n'est pas possible d'exécuter les commandes oc si un problème d'installation empêche l'API OpenShift Container Platform de fonctionner ou si le kubelet ne fonctionne pas encore sur chaque nœud.

6. Contrairement aux nœuds du plan de contrôle, les nœuds de travailleur sont déployés et mis à l'échelle à l'aide de l'opérateur API Machine. Vérifiez l'état de l'opérateur API Machine.

   1. Examiner le statut du pod de l'opérateur API de la machine :

      $ oc get pods -n openshift-machine-api

   2. Si le pod Opérateur API Machine n'a pas de statut Ready, détaillez les événements du pod :

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

   3. Inspecter les journaux du conteneur machine-api-operator. Le conteneur s'exécute dans le pod machine-api-operator:

      oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

   4. Inspectez également les journaux du conteneur kube-rbac-proxy. Le conteneur s'exécute également dans le pod machine-api-operator:

      oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

7. Surveillez les journaux de l'unité kubelet.service journald sur les nœuds de travail, après leur démarrage. Cela permet d'avoir une visibilité sur l'activité des agents des nœuds de travail.

   1. Récupérez les journaux à l'aide de oc:

      $ oc adm node-logs --role=worker -u kubelet

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

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.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>.

8. Récupérer les journaux de l'unité crio.service journald sur les noeuds de travail, après qu'ils aient démarré. Cela permet d'avoir une visibilité sur l'activité d'exécution des conteneurs CRI-O sur les nœuds de travail.

   1. Récupérez les journaux à l'aide de oc:

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

   2. Si l'API n'est pas fonctionnelle, examinez les journaux en utilisant plutôt SSH :

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

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

   1. Récupérer la liste des journaux contenus dans un sous-répertoire /var/log/. L'exemple suivant répertorie les fichiers contenus dans /var/log/sssd/ sur tous les nœuds de travail :

      $ oc adm node-logs --role=worker --path=sssd

   2. Inspecter un journal spécifique dans un sous-répertoire /var/log/. L'exemple suivant affiche le contenu de /var/log/sssd/audit.log à partir de tous les nœuds de travail :

      $ oc adm node-logs --role=worker --path=sssd/sssd.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/sssd/sssd.log:

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

10. Examinez les journaux des conteneurs des nœuds de travail à l'aide de SSH.

    1. Dressez la liste des conteneurs :

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. Récupérer les journaux d'un conteneur en utilisant crictl:

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

11. Si vous rencontrez des problèmes de configuration des nœuds de travail, vérifiez que le MCO, le point de terminaison MCO et l'enregistrement DNS fonctionnent. Le MCO (Machine Config Operator) gère la configuration du système d'exploitation pendant la procédure d'installation. Vérifiez également l'exactitude de l'horloge du système et la validité du certificat.

    1. Tester si le point de terminaison MCO est disponible. Remplacer <cluster_name> par les valeurs appropriées :

       $ curl https://api-int.<cluster_name>:22623/config/worker

    2. Si le point d'accès ne répond pas, vérifiez la configuration de l'équilibreur de charge. Assurez-vous que le point d'accès est configuré pour fonctionner sur le port 22623.

    3. Vérifiez que l'enregistrement DNS du point d'extrémité MCO est configuré et qu'il se résout vers l'équilibreur de charge.

       1. Lancer une recherche DNS pour le nom du point de terminaison MCO défini :

          $ dig api-int.<cluster_name> @<dns_server>

       2. Effectuez une recherche inversée de l'adresse IP MCO attribuée sur l'équilibreur de charge :

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. Vérifiez que le MCO fonctionne directement à partir du nœud de démarrage. Remplacez <bootstrap_fqdn> par le nom de domaine pleinement qualifié du nœud d'amorce :

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

    5. L'heure de l'horloge système doit être synchronisée entre les nœuds de démarrage, maître et subordonné. Vérifiez l'heure de référence de l'horloge système de chaque nœud et les statistiques de synchronisation du temps :

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. Examiner la validité du certificat :

       openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

Procédure

1. Vérifier que les opérateurs de cluster sont tous disponibles à la fin d'une installation.

   $ oc get clusteroperators

2. Vérifiez que toutes les demandes de signature de certificat (CSR) requises sont approuvées. Certains nœuds peuvent ne pas passer à l'état Ready et certains opérateurs de cluster peuvent ne pas être disponibles s'il y a des CSR en attente.

   1. Vérifiez l'état des CSR et assurez-vous que vous voyez une requête client et serveur avec l'état Pending ou Approved pour chaque machine que vous avez ajoutée au cluster :

      $ oc get csr

      Exemple de sortie

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1

      Une demande de CSR du client.

      2

      Une demande de serveur CSR.

      In this example, two machines are joining the cluster. You might see more approved CSRs in the list.

   2. If the CSRs were not approved, after all of the pending CSRs for the machines you added are in Pending status, approve the CSRs for your cluster machines:

      Note

      Étant donné que les CSR tournent automatiquement, approuvez-les dans l'heure qui suit l'ajout des machines à la grappe. Si vous ne les approuvez pas dans l'heure qui suit, les certificats tourneront et il y aura plus de deux certificats pour chaque nœud. Vous devez approuver tous ces certificats. Une fois que vous avez approuvé les CSR initiaux, les CSR des clients des nœuds suivants sont automatiquement approuvés par le cluster kube-controller-manager.

      Note

      For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If a request is not approved, then the oc exec, oc rsh, and oc logs commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the Kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the CSR was submitted by the node-bootstrapper service account in the system:node or system:admin groups, and confirm the identity of the node.

      • To approve them individually, run the following command for each valid CSR:

        $ oc adm certificate approve <csr_name> 1

        1

        <csr_name> est le nom d'un CSR figurant dans la liste des CSR actuels.

      • To approve all pending CSRs, run the following command:

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

3. Voir les événements de l'opérateur :

   oc describe clusteroperator <nom_opérateur>

4. Examiner le statut du pod de l'opérateur dans l'espace nominatif de l'opérateur :

   oc get pods -n <operator_namespace>

5. Obtenir une description détaillée pour les pods qui n'ont pas le statut Running:

   $ oc describe pod/<operator_pod_name> -n <operator_namespace>

6. Inspecter les journaux de bord :

   oc logs pod/<operator_pod_name> -n <operator_namespace>

7. En cas de problèmes liés à l'image de la base du pod, vérifier l'état de l'image de la base.

   1. Obtenir les détails de l'image de base utilisée par un pod problématique :

      $ oc get pod -o \N "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}\N" <operator_pod_name> -n <operator_namespace>

   2. Liste des informations de validation des images de base :

      $ oc adm release info <image_path>:<tag> --commits

Procédure

1. Generate the commands that are required to obtain the installation logs from the bootstrap and control plane machines:

   • If you used installer-provisioned infrastructure, change to the directory that contains the installation program and run the following command:

     ./openshift-install gather bootstrap --dir <installation_directory> $ ./openshift-install gather bootstrap --dir <installation_directory> 1

     1

     installation_directory is the directory you specified when you ran ./openshift-install create cluster. This directory contains the OpenShift Container Platform definition files that the installation program creates.

     For installer-provisioned infrastructure, the installation program stores information about the cluster, so you do not specify the hostnames or IP addresses.

   • If you used infrastructure that you provisioned yourself, change to the directory that contains the installation program and run the following command:

     $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
         --bootstrap <bootstrap_address> \ 2
         --master <master_1_address> \ 3
         --master <master_2_address> \ 4
         --master <master_3_address>" 5

     1

     For installation_directory, specify the same directory you specified when you ran ./openshift-install create cluster. This directory contains the OpenShift Container Platform definition files that the installation program creates.

     2

     <bootstrap_address> is the fully qualified domain name or IP address of the cluster’s bootstrap machine.

     3 4 5

     For each control plane, or master, machine in your cluster, replace <master_*_address> with its fully qualified domain name or IP address.

     Note

     A default cluster contains three control plane machines. List all of your control plane machines as shown, no matter how many your cluster uses.

   Exemple de sortie

   INFO Pulling debug logs from the bootstrap machine
   INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

   If you open a Red Hat support case about your installation failure, include the compressed logs in the case.