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 privés pour se connecter à la console web OpenShift. Ce diagramme suppose que la grappe a les paramètres par défaut de OAuth. 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 via le VPN au serveur API du maître de la grappe. Un certificat signé est échangé et une redirection demande au navigateur web de se connecter à l'équilibreur de charge de la console OpenShift.
2. (a) Le navigateur web se connecte via le VPN à 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 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 via le VPN 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 via le VPN. La connexion est redirigée vers l'équilibreur de charge de la console OpenShift.
7. Le navigateur web se connecte via le VPN à 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

Vérifiez que votre VPC et votre cluster sont correctement configurés. Une configuration incorrecte peut vous empêcher d'accéder à la console web OpenShift.

1. Assurez-vous que votre navigateur Web s'exécute sur un système client qui se trouve dans le même VPC que votre cluster ou qui dispose d'une connexion VPN à ce VPC. La console OpenShift est exposée par un équilibreur de charge VPC privé qui n'est accessible qu'à partir du réseau privé du VPC.

2. Assurez-vous que le système client a accès aux points de terminaison du service public pour l'IAM, qui sont accessibles via iam.cloud.ibm.com et login.ibm.com.

3. Pour les grappes qui utilisent la version 4.13:

   • Si votre cluster utilise la configuration Oauth par défaut de 4.13 ou si vous avez configuré votre cluster pour utiliser la passerelle VPE pour Oauth, assurez-vous que votre client utilise le DNS privé pour le VPC et que ce trafic DNS est acheminé par le VPN vers le VPC. Le DNS privé est généralement 161.26.0.7 et 161.26.0.8, à moins que vous n'utilisiez un résolveur DNS personnalisé. Ceci est nécessaire pour que la passerelle VPE pour apiserver et Oauth, qui n'existe dans aucun DNS public, puisse être trouvée dans le DNS privé du VPC.

4. Pour les clusters qui utilisent une version supportée autre que la version 4.13:

   • Si vous utilisez les paramètres par défaut du cluster Oauth, assurez-vous que des routes existent dans la configuration VPN afin que tout le trafic 166.8.0.0/14 soit acheminé via le même VPN ou un autre VPN qui se connecte à IBM Cloud. Elle est nécessaire pour se connecter aux ports du serveur API et du serveur OAuth de la grappe.

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.private.<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. Dans le résultat, trouvez le site URL avec l'un des formats suivants.
       - Si la passerelle VPE n'est pas utilisée pour OAuth: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
       - Si la passerelle VPE est utilisée pour OAuth: `https://<CLUSTERID>.vpe.private.<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 qu'il existe une route à travers votre VPN qui se connecte au serveur API du cluster URL.
       4. Si l'apériteur de cluster URL contient votre ID de cluster (ce qui indique que le cluster utilise la passerelle VPE pour la connexion à l'apériteur de cluster), vérifiez que le groupe de sécurité de la passerelle VPE pour le maître de cluster autorise le trafic à partir de votre sous-réseau client VPN. Suivez les étapes décrites dans la section [Accès à la console OpenShift lorsque l'accès OAuth est défini sur la passerelle VPE](/docs/openshift?topic=openshift-console-apiserver-oauthvpe).
       5. Vérifiez si des groupes de sécurité, des ACL ou des routes VPC personnalisées appliquées au VPN empêchent le trafic entre le VPN et le serveur API du cluster. Vous pouvez tester cela en autorisant temporairement tout le trafic entrant et sortant via le groupe de sécurité VPN et l'ACL, puis en vérifiant si cela résout le problème. Si c'est le cas, apportez les modifications nécessaires à vos groupes de sécurité, ACL ou routes personnalisées pour autoriser le trafic.
       6. 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 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. Vérifiez qu'il existe une route à travers votre VPN vers ce sous-domaine de l'équilibreur de charge. Vérifiez que l'itinéraire inclut tous les IP ou sous-réseaux utilisés par l'équilibreur de charge. La sortie de la commande `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` comprend les IP et les sous-réseaux actuels de l'équilibreur de charge, mais notez qu'ils peuvent changer au fur et à mesure que l'équilibreur de charge augmente ou diminue.
       3. 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.
       4. Vérifiez si des groupes de sécurité, des ACL ou des routes VPC personnalisées appliquées au VPN empêchent le trafic entre le VPN et l'équilibreur de charge. Vous pouvez tester cela en autorisant temporairement tout le trafic entrant et sortant via le groupe de sécurité VPN et l'ACL, puis en vérifiant si cela résout le problème. Si c'est le cas, apportez les modifications nécessaires à vos groupes de sécurité, ACL ou routes personnalisées pour autoriser le trafic.
   
   

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 qu'il existe une route à travers votre VPN vers le maître de cluster OAuth URL.
       4. Vérifiez si des groupes de sécurité, des ACL ou des routes VPC personnalisées appliquées au VPN empêchent le trafic entre le VPN et le serveur de cluster OAuth. Vous pouvez tester cela en autorisant temporairement tout le trafic entrant et sortant via le groupe de sécurité VPN et l'ACL, puis en vérifiant si cela résout le problème. Si c'est le cas, apportez les modifications nécessaires à vos groupes de sécurité, ACL ou routes personnalisées pour autoriser le trafic.
       5. 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 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.