1. Comprendre le flux de connexion du cluster

Le diagramme suivant montre le flux de connexion pour un cluster VPC avec des points d'extrémité de service publics et privés pour se connecter à la console web OpenShift. Notez que toutes les connexions entre le navigateur web et les composants de la grappe se font sur le réseau public. Examinez ce diagramme et les descriptions suivantes pour mieux comprendre les étapes de dépannage qui peuvent être nécessaires.

1. Le navigateur web se connecte au serveur API du maître de cluster. Un certificat signé est échangé et une redirection indique au navigateur web de se connecter à l'équilibreur de charge public de la console OpenShift.
2. (a) Le navigateur web se connecte à l'équilibreur de charge de la console OpenShift qui expose la console OpenShift. (b) Cette requête est envoyée à l'un des deux pods openshift-console.
3. Le pod openshift-console se connecte via le réseau public au port du serveur du cluster master OAuth pour vérifier si la connexion est déjà authentifiée. Si la demande est déjà authentifiée, la connexion à la console web OpenShift est terminée et la console web est accessible. Si la demande n'est pas authentifiée, l'utilisateur est redirigé vers le service OAuth du maître de la grappe.
4. Le navigateur web se connecte au port du serveur OAuth du cluster, qui redirige le client vers IAM.
5. Le navigateur web se connecte à IAM via le réseau public. L'utilisateur saisit son mot de passe et, si nécessaire, une vérification sur 2FA. Si cette étape est réussie, l'utilisateur est redirigé vers le serveur OAuth du cluster.
6. Le navigateur web se connecte à nouveau au port du serveur OAuth du cluster. La connexion est redirigée vers l'équilibreur de charge de la console OpenShift.
7. Le navigateur web se connecte à l'équilibreur de charge de la console OpenShift, qui expose la console OpenShift. Cette requête est envoyée à l'un des deux pods openshift-console, qui se connecte à nouveau au port du serveur du cluster master OAuth pour vérifier si la connexion est déjà authentifiée. Si l'utilisateur a saisi son mot de passe et la vérification 2FA, l'authentification est validée et l'utilisateur est connecté à la page web principale de la console OpenShift.

2. Vérifiez la configuration de votre VPC et de votre cluster

1. Assurez-vous que votre navigateur web a accès au réseau public afin qu'il puisse se connecter à l'apiserver du cluster, à l'équilibreur de charge de la console OpenShift et à IAM (qui utilise à la fois iam.cloud.ibm.com et login.ibm.com)
2. Si vous avez modifié des groupes de sécurité, des ACL ou des règles CBR (Context-Base Restriction) pour ce cluster ou cet équilibreur de charge, assurez-vous qu'ils autorisent le trafic de ce navigateur web vers ces ressources

3. Collecte de données sur les clusters

Suivez les étapes suivantes pour rassembler les informations sur les clusters nécessaires au dépannage. Les résultats obtenus à l'aide de ces commandes sont utilisés dans les étapes suivantes.

1. Recherchez le serveur API du cluster URL. Dans les commandes ultérieures, ce URL est appelé ${CLUSTER_APISERVER_URL}.

   1. Exécutez la commande ibmcloud ks cluster get -c CLUSTER_ID.

       ibmcloud oc cluster get -c CLUSTER_ID
       ```
   2. Dans la section `Master` de la sortie, trouvez le `URL`. Le site URL doit se présenter sous la forme suivante : `https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<YYYYY>`.
   
   
   

2. Trouvez le groupe OAuth URL. Dans les commandes ultérieures, ce URL est appelé ${CLUSTER_OAUTH_URL}.

   1. Exécutez la commande kubectl get --raw /.well-known/oauth-authorization-server | grep issuer. N'utilisez pas ibmcloud oc cluster get -c CLUSTER_ID, car cette commande pourrait renvoyer un autre URL.

       kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
       ```
   2. Le site URL doit se présenter sous la forme suivante : `https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
   
   

3. Trouvez le sous-domaine Ingress. Dans les commandes ultérieures, ce sous-domaine est appelé ${CONSOLE_LOAD_BALANCER}.

   1. Exécutez la commande ibmcloud oc cluster get -c CLUSTER_ID.

       ibmcloud oc cluster get -c CLUSTER_ID
       ```
   2. Dans le résultat, trouvez le sous-domaine qui correspond au format suivant : `<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud`. Notez que si vous avez configuré un sous-domaine Ingress personnalisé, le format correspondra à votre configuration personnalisée.
   
   

4. Vérifier les connexions et résoudre les problèmes

Suivez les étapes suivantes pour vérifier les connexions décrites dans le schéma de connexion. Si vous constatez un problème avec une connexion, utilisez les informations pour résoudre le problème.

1. Vérifiez que Ingress est sain et que le routeur et les pods de console sont sains.

   1. Exécutez les commandes.

       ibmcloud oc cluster get -c CLUSTERID
       ibmcloud oc ingress status-report get -c CLUSTERID
       ```
   2. Si la sortie indique un état d'erreur, utilisez la [documentation de dépannage Ingress](/docs/openshift?topic=openshift-ingress-status) pour résoudre le problème.
   
   

2. Vérifiez que les opérateurs du cluster OpenShift sont sains.

   1. Exécutez la commande.

       oc get clusteroperators
       ```
   2. Si le résultat montre que des opérateurs ne sont pas sains ou ne fonctionnent pas avec la version actuelle, utilisez la [documentation de dépannage de la version du cluster OpenShift](/docs/openshift?topic=openshift-ts-cluster-version-downlevel) pour résoudre le problème. Vous pouvez également rechercher dans la documentation IBM et Red Hat les erreurs spécifiques qui sont affichées.
   3. Si l'opérateur de la console n'est pas en bonne santé, vérifiez les journaux des pods `openshift-console/console...` et `openshift-console-operator/console-operator...` pour voir si un groupe de sécurité, un ACL ou une personnalisation DNS empêche les pods de se connecter au port OAuth ou à la console OpenShift URL. Un groupe de sécurité, un ACL ou un DNS peut être configuré de manière à empêcher la connexion.
   
   

3. Vérifiez que la connexion au serveur API du maître de cluster est réussie.

   1. Exécutez la commande. Spécifiez le cluster apiserver URL que vous avez trouvé dans les étapes précédentes.

       curl -k -vvv ${CLUSTER_APISERVER_URL}/version
       ```
   2. Si la connexion n'aboutit pas, procédez aux vérifications suivantes et résolvez les problèmes éventuels.
       1. Vérifiez que le maître de la grappe est sain en exécutant la commande `ibmcloud oc cluster get -c <CLUSTER-ID>`. Reportez-vous à la section [Examen de l'état du maître](/docs/openshift?topic=openshift-debug_master) pour obtenir des informations sur la résolution des problèmes liés au maître de la grappe.
       2. Vérifiez que la partie du nom d'hôte de URL est résolue par DNS. Utilisez la commande `dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)` et indiquez le serveur API du cluster URL.
       3. Vérifiez si des règles CBR (Context Based Restriction) sur le cluster empêchent le client de se connecter au serveur API du cluster. Vous pouvez tester cela en ajoutant temporairement une zone réseau à votre règle CBR publique qui autorise toutes les IP et tous les sous-réseaux. Si cette modification temporaire résout le problème, apportez les modifications nécessaires à la règle pour autoriser le trafic.
   
   

4. Vérifiez que la connexion à l'équilibreur de charge du cluster exposant la console OpenShift est réussie.

   1. Exécutez la commande. Indiquez le sous-domaine Ingress que vous avez trouvé dans les étapes précédentes.

       curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
       ```
   2. Si la connexion n'aboutit pas, procédez aux vérifications suivantes et résolvez les problèmes éventuels.
       1. Vérifiez que le nom d'hôte du sous-domaine est résolu par le DNS. Utilisez la commande `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}`.
       2. Si vous avez modifié des groupes de sécurité, des ACL ou des routes VPC personnalisées appliquées à l'équilibreur de charge, vérifiez si les changements ou les règles que vous avez appliqués empêchent la connexion. Si vous n'avez modifié aucun de ces composants et qu'ils utilisent les valeurs par défaut, vous pouvez sauter cette étape.
   
   

5. Vérifiez que la connexion au serveur de cluster OAuth est réussie.

   1. Exécutez la commande. Spécifiez le cluster OAuth URL que vous avez trouvé dans les étapes précédentes.

       curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
       ```
   2. Si la connexion n'aboutit pas, procédez aux vérifications suivantes et résolvez les problèmes éventuels.
       1. Vérifiez que votre maître de cluster est en bonne santé en exécutant la commande `ibmcloud oc cluster get -c <CLUSTER-ID>`. Reportez-vous à la section [Examen de l'état du maître](/docs/openshift?topic=openshift-debug_master) pour obtenir des informations sur la résolution des problèmes liés au maître de la grappe.
       2. Vérifiez que la partie nom d'hôte du cluster OAuth URL est résolue par DNS. Utilisez l'adresse `dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)` et spécifiez le cluster OAuth URL.
       3. Vérifiez si des règles de restriction contextuelle (CBR) sur le cluster empêchent le client de se connecter au serveur du cluster OAuth. Vous pouvez tester cela en ajoutant temporairement une zone réseau à votre règle CBR publique qui autorise toutes les IP et tous les sous-réseaux. Si cette modification temporaire résout le problème, apportez les modifications nécessaires à la règle pour autoriser le trafic.
   
   

6. Vérifiez que la connexion à IAM est réussie.

   1. Exécutez les commandes.

       curl -vvv https://iam.cloud.ibm.com/healthz
       curl -vvv -o /dev/null -s https://login.ibm.com/
       ```
   2. Si l'une de ces commandes échoue, vérifiez que le système client est en mesure de se connecter à ces URL de manière fiable et que les URL ne sont pas bloquées par un pare-feu du client ou de l'entreprise. Notez que ces URL nécessitent un accès à l'internet public.
   
   

5. Contacter le support

Si vous avez suivi toutes les étapes ci-dessus et que vous n'avez pas résolu le problème, contactez le service d'assistance. Ouverture d'un cas de support. Dans les détails de l'affaire, veillez à inclure tous les fichiers journaux, messages d'erreur ou sorties de commande pertinents.