Etape 1 : Vérifiez la configuration de votre compte

Vérifiez que votre compte IBM Cloud est correctement configuré. Les scénarios courants qui peuvent empêcher les composants par défaut de s'exécuter correctement sont notamment les suivants :

• Si votre cluster classique comporte plusieurs zones, ou si vous disposez d'un cluster de VPC, prenez soin d'activer la fonction VRF ou Spanning VLAN. Pour vérifier si la fonction VRF est déjà activée, exécutez ibmcloud account show. Pour vérifier si la fonction Spanning VLAN est activée, exécutez ibmcloud oc vlan spanning get.
• Si certains utilisateurs du compte utilisent une authentification multifactorielle (MFA) telle que TOTP, veillez à activer la MFA pour tous les utilisateurs du compte IBM Cloud.

L'activation de l'authentification multi-facteur (MFA) au niveau utilisateur n'est pas prise en charge. Si l'authentification multi-facteur est activée pour certains utilisateurs mais n'est pas activée pour tous les utilisateurs au niveau du compte, des erreurs d'authentification peuvent se produire.

Étape 2 : Vérification de la passerelle publique

• Pour les clusters VPC avec des nœuds finaux de service de cloud public et privé activés :

  Vérifiez qu'une passerelle publique est activée sur chaque sous-réseau VPC auquel votre cluster est connecté. Une passerelle publique est requise pour les composants par défaut, tels que la console Web et OperatorHub, pour utiliser une connexion publique et sécurisée et effectuer des actions, telles que l'extraction d'images de registres privés distants.

  1. Utilisez la console ou l'interface de ligne de commande IBM Cloud pour faire en sorte qu'une passerelle publique soit activée sur chaque sous-réseau auquel votre cluster est connecté.
  2. Redémarrez les composants pour le catalogue développeur dans la console Web.
     1. Editez la mappe de configuration pour l'opérateur d'exemples.

        oc edit configs.samples.operator.openshift.io/cluster
        

  3. Remplacez la valeur managementState par Removed pour Managed. 3. Sauvegardez et fermez la mappe de configuration. Vos modifications sont appliquées automatiquement.

• Pour les clusters Classiques avec des nœuds finaux de service de cloud public et privé activés :

  Vérifiez que votre cluster dispose d'une connectivité publique pour que les composants de mise en réseau puissent communiquer avec le maître lors de leur déploiement.

  1. Vérifiez la zone Etat du maître (Master Status). Si l'état du maître n'est pas Prêt (Ready), vérifiez son état et suivez les informations de traitement des incidents pour résoudre le problème.

      ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
      ```
  1. Dans la sortie **état maître**, vérifiez que votre cluster a un **URL du noeud final de service public**. Si votre cluster ne dispose pas d'un point de terminaison de service cloud public, activez-le.
  1. Vérifiez qu'au moins certains nœuds worker de votre cluster ont une adresse **IP publique**. Si aucun nœud de travail ne le fait, vous devez configurer des VLAN publics pour au moins un pool de nœuds de travail.
  
  ```sh {: pre}
      ibmcloud oc workers -c CLUSTER_NAME_OR_ID
      ```
  

Etape 3 : Vérifiez les pare-feux et les règles réseau

Vérifiez les pare-feu ou les règles de réseau pour vérifier que vous ne bloquez aucun trafic Ingress ou Egress pour OperatorHub ou d'autres composants Red Hat OpenShift.

• Si vous avez généré une liste autorisée IBM Cloud Identity and Access Management (IAM) en spécifiant les adresses IP qui ont accès à votre cluster, vous devez ajouter à la liste autorisée les routages CIDR du plan de contrôle Red Hat OpenShift on IBM Cloud pour les zones de la région dans laquelle se trouve votre cluster.
• Classique uniquement : si vous disposez d'un pare-feu, ouvrez les ports et adresses IP requis dans votre pare-feu.
• VPC uniquement : si vous contrôlez le trafic avec des listes de contrôle ou des groupes de sécurité VPC, prenez soin d'autoriser les règles entrantes et sortantes minimum requises.

Etape 4 : Vérifiez la configuration du cluster

Vérifiez que votre cluster est correctement configuré. Si vous venez de créer votre cluster, attendez que ses composants soient entièrement mis à disposition.

1. Obtenez les détails relatifs à votre cluster.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

2. Passez en revue la sortie de l'étape précédente pour vérifier le sous-domaine Ingress.
   • Si votre cluster ne comporte pas de sous-domaine, voir Aucun sous-domaine Ingress n'existe après la création du cluster.
   • Si votre cluster comporte un sous-domaine, passez à l'étape suivante.
3. Vérifiez que votre cluster exécute la version de correctif la plus récente. Si votre cluster n'exécute pas la dernière version de correctif, mettez à jour le cluster et les noeuds worker.
   1. Mettez à jour le maître cluster vers la dernière version de correctif pour les versions principale et secondaire de votre cluster.

       ibmcloud oc cluster master update -c CLUSTER_NAME_OR_ID --version MAJOR.MINOR_openshift-f
       ```
   2. Répertoriez vos noeuds worker.
   ```sh {: pre}
       ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
       ```
   3. [Mettez à jour les noeuds worker](/docs/openshift?topic=openshift-update#worker_node) pour qu'ils correspondent à la version maître du cluster.
   ```sh {: pre}
       ibmcloud oc worker update -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID -w WORKER3_ID
       ```
   

4. Vérifiez la zone State pour le cluster. Si l'état n'est pas normal, examinez l'état de la grappe et résolvez les problèmes éventuels.
5. Vérifiez la zone Master health. Si l'état n'est pas normal, examinez l'état sanitaire principal et résolvez les problèmes éventuels.
6. Vérifiez les noeuds worker sur lesquels les composants Red Hat OpenShift peuvent s'exécuter. Si l'état n'est pas normal, voir Débogage des noeuds worker.

   ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
   

Etape 5 : Connectez-vous à votre cluster

Connectez-vous à votre cluster. Notez que si la console Web Red Hat OpenShift ne vous permet pas d'obtenir le jeton de connexion, vous pouvez accéder au cluster à partir de l'interface de ligne de commande.

VPC uniquement : si vous avez activé le noeud final de service cloud privé, vous devez être connecté au réseau privé via votre connexion VPN VPC pour accéder à la console Web.

Etape 6 : Vérifiez les pods de composant

Vérifiez la santé des composants Red Hat OpenShift qui ne fonctionnent pas.

1. Vérifiez le statut du pod.

   oc get pods -n <project>
   

2. Si un pod n'est pas à l'état En cours d'exécution, décrivez-le et vérifiez les événements. Par exemple, vous pouvez voir une erreur que le pod ne peut pas être planifié en raison d'un manque de ressources d'unité centrale ou de mémoire, ce qui est courant si vous avez un cluster avec moins de 3 nœuds worker. Redimensionnez votre pool de noeuds worker Classic ou Redimensionnez votre pool de noeuds worker VPC et réessayez.

   oc describe pod -n <project> <pod>
   

3. Si vous ne voyez pas d'informations utiles dans la section des événements, consultez les journaux de pod pour obtenir des messages d'erreur ou d'autres informations d'identification et de résolution des incidents.

   oc logs pod -n <project> <pod>
   

4. Redémarrez le pod et vérifiez s'il parvient à l'état En cours d'exécution.

   oc delete pod -n <project> <pod>
   

Etape 7 : Vérifiez les pods système

Si les pods sont sains, vérifiez si d'autres pods système présentent des problèmes. Souvent, pour fonctionner correctement, un composant dépend de la bonne santé d'un autre composant.

Par exemple, OperatorHub dispose d'un ensemble d'images qui sont stockées dans des registres externes, tels que quay.io. Ces images sont insérées dans le registre interne qui sera utilisé dans les projets de votre cluster Red Hat OpenShift. Si l'un des composants OperatorHub ou internes du registre n'est pas configuré correctement, par exemple en raison d'un manque de droits d'accès ou de ressources de traitement, OperatorHub et le catalogue ne s'affichent pas.

1. Recherchez des pods en instance.

   oc get pods --all-namespaces | grep Pending
   

2. Décrivez les pods et recherchez les événements.

   oc describe pod -n <project_name> <pod_name>
   

   Par exemple, les messages susceptibles de s'afficher à partir des pods openshift-image-registry sont notamment les suivants :
   • Un message d'erreur Volume could not be created car vous avez créé le cluster sans l'autorisation de stockage correcte. Les clusters Red Hat OpenShift on IBM Cloud sont fournis avec une unité de stockage de fichiers par défaut pour stocker les images du système et des autres pods. Vérifiez vos droits d'infrastructure et redémarrez le pod.
   • Un message d'erreur order will exceed maximum number of storage volumes allowed peut s'afficher car vous avez dépassé le quota combiné d'unités de stockage de fichiers et de stockage par blocs autorisées pour chaque compte. Retirez les unités de stockage inutilisées ou augmentez votre quota de stockage, puis redémarrez le pod.
   • Un message indiquant que les images ne peuvent pas être stockées car l'unité de stockage de fichiers est pleine. Redimensionnez l'unité de stockage et redémarrez le pod.
   • Un message d'erreur Pull image still failed due to error: unauthorized: authentication required car le registre interne ne peut pas extraire les images d'un registre externe. Vérifiez que les secrets d'extraction d'image sont définis pour le projet et redémarrez le pod.
3. Vérifiez le noeud sur lequel s'exécutent les pods défectueux. Si tous les pods s'exécutent sur le même noeud worker, ce dernier peut avoir un problème de connectivité réseau. Rechargez le noeud worker.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Étape 8 : Vérifier le VPN

Vérifiez que le VPN du cluster est correctement configuré.

1. Vérifiez que le pod VPN est en cours d'exécution.

   oc get pods -n kube-system -l app=vpn
   

2. Vérifiez les journaux du VPN et recherchez un message ERROR tel que WORKERIP:<port>, par exemple WORKERIP:10250, indiquant que le tunnel VPN ne fonctionne pas.

   oc logs -n kube-system <vpn_pod> --tail 10
   

3. Si le message d'erreur concerne l'adresse IP du noeud worker, vérifiez que la communication entre les noeuds worker est rompue. Connectez-vous à un pod calico-node dans le projet calico-system et recherchez la même erreur WORKERIP:10250.

   oc exec -n calico-system <calico-node_pod> -- date
   

4. Si la communication entre les noeuds worker est rompue, prenez soin d'activer la fonction VRF ou Spanning VLAN.
5. Si vous constatez une erreur autre que celle liée au VPN ou au pod calico-node, redémarrez le pod VPN.

   oc delete pod -n kube-system <vpn_pod>
   

6. Si le VPN ne fonctionne toujours pas, vérifiez le nœud de travail sur lequel s'exécute le pod.

   oc describe pod -n kube-system <vpn_pod> | grep "Node:"
   

7. Isolez le nœud de travail afin que le pod VPN soit réaffecté à un autre nœud de travail.

   oc cordon <worker_node>
   

8. Vérifiez à nouveau les journaux du pod VPN. Si le pod ne présente plus d'erreur, le noeud worker peut avoir un problème de connectivité réseau. Rechargez le noeud worker.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Etape 9 : Actualisez le maître cluster

Actualisez le maître cluster pour configurer les composants Red Hat OpenShift par défaut. Après avoir actualisé le cluster, patientez quelques minutes pour permettre à l'opération de s'achever.

ibmcloud oc cluster master refresh -c CLUSTER_NAME_OR_ID

Etape 10 : Réessayez

Essayez d'utiliser à nouveau le composant Red Hat OpenShift.

Si l'erreur persiste, voir Commentaires, questions et support.