1. Comprendere il flusso di connessioni del cluster

Il diagramma seguente mostra il flusso di connessione per un cluster VPC con endpoint di servizi privati per connettersi alla console web OpenShift. Questo diagramma presuppone che il cluster abbia le impostazioni predefinite di OAuth. Esaminare questo diagramma e le descrizioni seguenti per capire meglio quali sono i passaggi necessari per la risoluzione dei problemi.

1. Il browser web si collega attraverso la VPN al server API del master del cluster. Viene scambiato un certificato firmato e un reindirizzamento indica al browser web di connettersi invece al bilanciatore di carico della console OpenShift.
2. (a) Il browser web si connette attraverso la VPN al bilanciatore di carico della console OpenShift che espone la console OpenShift. (b) La richiesta viene inviata a uno dei due pod openshift-console.
3. Il pod openshift-console si connette alla porta del server master del cluster OAuth per verificare se la connessione è già autenticata. Se la richiesta è già autenticata, la connessione alla console web OpenShift è completa e si può accedere alla console web. Se la richiesta non è autenticata, l'utente viene reindirizzato al servizio OAuth del cluster sul master del cluster.
4. Il browser web si connette attraverso la VPN alla porta del server OAuth del cluster, che reindirizza il client a IAM.
5. Il browser web si collega a IAM attraverso la rete pubblica. L'utente inserisce la propria password e, se richiesto, una verifica su 2FA. Se questo passaggio ha successo, l'utente viene reindirizzato al server OAuth del cluster.
6. Il browser web si connette attraverso la VPN alla porta del server OAuth del cluster. La connessione viene reindirizzata al bilanciatore di carico della console OpenShift.
7. Il browser Web si connette attraverso la VPN al bilanciatore di carico della console OpenShift, che espone la console OpenShift. Questa richiesta viene inviata a uno dei due pod openshift-console, che si connette nuovamente alla porta del server master del cluster OAuth per verificare se la connessione è già autenticata. Se l'utente ha inserito la propria password e la verifica 2FA, l'autenticazione viene convalidata e l'utente si collega alla pagina web principale della console OpenShift.

2. Verificare la configurazione del VPC e del cluster

Verificare che il VPC e il cluster siano configurati correttamente. Una configurazione errata potrebbe impedire l'accesso alla console web OpenShift.

1. Assicurarsi che il browser web sia in esecuzione in un sistema client che si trovi all'interno dello stesso VPC del cluster o che disponga di una connessione VPN a tale VPC. La console OpenShift è esposta da un bilanciatore di carico VPC privato, accessibile solo dalla rete privata del VPC.

2. Assicurarsi che il sistema client abbia accesso agli endpoint del servizio pubblico per IAM, accessibili tramite iam.cloud.ibm.com e login.ibm.com.

3. Per i cluster che eseguono la versione 4.13:

   • Se il cluster utilizza la configurazione Oauth predefinita di 4.13 o se è stato impostato il cluster per utilizzare il gateway VPE per Oauth, assicurarsi che il client utilizzi il DNS privato per il VPC e che il traffico DNS sia instradato attraverso la VPN verso il VPC. Il DNS privato è in genere 161.26.0.7 e 161.26.0.8, a meno che non si utilizzi un resolver DNS personalizzato. Questo è necessario affinché il gateway VPE per apiserver e Oauth, che non esiste in nessun DNS pubblico, possa essere trovato nel DNS privato della VPC.

4. Per i cluster che eseguono qualsiasi versione supportata diversa da 4.13:

   • Se si utilizzano le impostazioni predefinite del cluster Oauth, assicurarsi che esistano dei percorsi nella configurazione VPN in modo che tutto il traffico di 166.8.0.0/14 sia instradato attraverso la stessa VPN o un'altra VPN che si connette a IBM Cloud. È necessario per connettersi al server API del cluster e alle porte del server OAuth.

3. Raccogliere i dati del cluster

Seguite questi passaggi per raccogliere le informazioni sul cluster necessarie per la risoluzione dei problemi. I risultati ottenuti con questi comandi vengono utilizzati nelle fasi successive.

1. Trovare il server API del cluster URL. Nei comandi successivi, questo URL viene indicato come ${CLUSTER_APISERVER_URL}.

   1. Eseguire il comando ibmcloud ks cluster get -c CLUSTER_ID.

       ibmcloud oc cluster get -c CLUSTER_ID
       ```
   2. Nella sezione `Master` dell'output, trovare il link `URL`. L'indirizzo URL deve avere il seguente formato: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<YYYYY>`.
   
   
   

2. Trovare il cluster OAuth URL. Nei comandi successivi, questo URL viene indicato come ${CLUSTER_OAUTH_URL}.

   1. Eseguire il comando kubectl get --raw /.well-known/oauth-authorization-server | grep issuer. Non utilizzare ibmcloud oc cluster get -c CLUSTER_ID, poiché questo comando potrebbe restituire un URL diverso.

       kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
       ```
   2. Nell'output, trovare URL con uno dei seguenti formati.
       - Se il gateway VPE non viene utilizzato per OAuth: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
       - Se il gateway VPE viene utilizzato per OAuth: `https://<CLUSTERID>.vpe.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
   
   

3. Trovare il sottodominio di Ingress. Nei comandi successivi, questo sottodominio viene indicato come ${CONSOLE_LOAD_BALANCER}.

   1. Eseguire il comando ibmcloud oc cluster get -c CLUSTER_ID.

       ibmcloud oc cluster get -c CLUSTER_ID
       ```
   2. Nell'output, trovare il sottodominio che corrisponde al seguente formato: `<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud`. Si noti che se si è configurato un sottodominio Ingress personalizzato, il formato corrisponderà invece alla configurazione personalizzata.
   
   

4. Verifica dei collegamenti e risoluzione dei problemi

Seguire i seguenti passaggi per verificare i collegamenti descritti nel flusso di collegamento. Se si riscontra un problema con una connessione, utilizzare le informazioni per risolvere il problema.

1. Verificare che Ingress sia sano e che il router e i pod della console siano sani.

   1. Eseguire i comandi.

       ibmcloud oc cluster get -c CLUSTERID
       ibmcloud oc ingress status-report get -c CLUSTERID
       ```
   2. Se l'output mostra uno stato di errore, utilizzare la [documentazione sulla risoluzione dei problemi di Ingress](/docs/openshift?topic=openshift-ingress-status) per risolvere il problema.
   
   

2. Verificare che gli operatori del cluster OpenShift siano sani.

   1. Eseguire il comando.

       oc get clusteroperators
       ```
   2. Se l'output mostra che uno qualsiasi degli operatori non funziona correttamente o non è in esecuzione nella versione corrente, utilizzare la [documentazione per la risoluzione dei problemi della versione del cluster OpenShift](/docs/openshift?topic=openshift-ts-cluster-version-downlevel) per risolvere il problema. In alternativa, è possibile cercare nella documentazione di IBM e Red Hat gli errori specifici visualizzati.
   3. Se l'operatore della console non è sano, controllare i log dei pod `openshift-console/console...` e `openshift-console-operator/console-operator...` per verificare se un gruppo di sicurezza, una ACL o una personalizzazione DNS impediscono ai pod di connettersi alla porta OAuth o alla console OpenShift URL. Un gruppo di sicurezza, una ACL o un DNS potrebbero essere configurati in modo da impedire la connessione.
   
   

3. Verificare che la connessione al server API del master del cluster sia riuscita.

   1. Eseguire il comando. Specificare il cluster apiserver URL trovato nei passi precedenti.

       curl -k -vvv ${CLUSTER_APISERVER_URL}/version
       ```
   2. Se la connessione non riesce, effettuare i seguenti controlli e risolvere eventuali problemi.
       1. Verificare che il master del cluster sia sano eseguendo il comando `ibmcloud oc cluster get -c <CLUSTER-ID>`. Per informazioni sulla risoluzione dei problemi del master del cluster, vedere [Revisione dello stato di salute del master](/docs/openshift?topic=openshift-debug_master).
       2. Verificare che la porzione di hostname del sito URL sia risolta tramite DNS. Utilizzare il comando `dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)` e specificare il server API del cluster URL.
       3. Verificare che esista un percorso attraverso la VPN che si connetta al server API del cluster URL.
       4. Se l'apiserver del cluster URL contiene l'ID del cluster (che indica che il cluster utilizza il gateway VPE per la connessione all'apiserver del cluster), verificare che il gruppo di sicurezza del gateway VPE per il master del cluster consenta il traffico dalla subnet del client VPN. Seguire la procedura descritta in [Accesso alla console OpenShift quando l'accesso a OAuth è impostato sul gateway VPE](/docs/openshift?topic=openshift-console-apiserver-oauthvpe).
       5. Verificare se eventuali gruppi di sicurezza, ACL o percorsi VPC personalizzati applicati alla VPN impediscono il traffico tra la VPN e il server API del cluster. Si può fare una prova consentendo temporaneamente tutto il traffico in entrata e in uscita attraverso il gruppo di sicurezza VPN e l'ACL e verificando se il problema si risolve. In tal caso, apportare le modifiche necessarie ai gruppi di sicurezza, alle ACL o alle rotte personalizzate per consentire il traffico.
       6. Verificare se le regole CBR (Context Based Restriction) sul cluster impediscono al client di connettersi al server API del cluster. Si può verificare aggiungendo temporaneamente una zona di rete alla regola CBR che consente tutti gli IP e le sottoreti. Se questa modifica temporanea risolve il problema, apportare le modifiche necessarie alla regola per consentire il traffico.
   
   

4. Verificare che la connessione al bilanciatore di carico del cluster che espone la console OpenShift sia riuscita.

   1. Eseguire il comando. Specificare il sottodominio di Ingress individuato nei passaggi precedenti.

       curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
       ```
   2. Se la connessione non riesce, effettuare i seguenti controlli e risolvere eventuali problemi.
       1. Verificare che la porzione di hostname del sottodominio sia risolta tramite DNS. Utilizzare il comando `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}`.
       2. Verificare che esista un percorso attraverso la VPN verso questo sottodominio del bilanciatore di carico. Verificare che il percorso includa tutti gli IP o le sottoreti utilizzati dal bilanciatore del carico. L'output del comando `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` include gli IP e le sottoreti correnti del bilanciatore di carico, ma si noti che questi possono cambiare quando il bilanciatore di carico aumenta o diminuisce.
       3. Se sono stati modificati gruppi di sicurezza, ACL o percorsi VPC personalizzati applicati al bilanciatore di carico, verificare se le modifiche o le regole applicate impediscono la connessione. Se non si è modificato nessuno di questi componenti e si utilizzano i valori predefiniti, si può saltare questo passaggio.
       4. Verificare se eventuali gruppi di sicurezza, ACL o rotte VPC personalizzate applicate alla VPN impediscono il traffico tra la VPN e il bilanciatore di carico. Si può fare una prova consentendo temporaneamente tutto il traffico in entrata e in uscita attraverso il gruppo di sicurezza VPN e l'ACL e verificando se il problema si risolve. In tal caso, apportare le modifiche necessarie ai gruppi di sicurezza, alle ACL o alle rotte personalizzate per consentire il traffico.
   
   

5. Verificare che la connessione al server del cluster OAuth sia riuscita.

   1. Eseguire il comando. Specificare il cluster OAuth URL trovato nei passi precedenti.

       curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
       ```
   2. Se la connessione non riesce, effettuare i seguenti controlli e risolvere eventuali problemi.
       1. Verificare che il master del cluster sia sano eseguendo il comando `ibmcloud oc cluster get -c <CLUSTER-ID>`. Per informazioni sulla risoluzione dei problemi del master del cluster, vedere [Revisione dello stato di salute del master](/docs/openshift?topic=openshift-debug_master).
       2. Verificare che la parte di hostname del cluster OAuth URL sia risolta tramite DNS. Utilizzare `dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)` e specificare il cluster OAuth URL.
       3. Verificare che esista un percorso attraverso la VPN verso il master del cluster OAuth URL.
       4. Verificare se eventuali gruppi di sicurezza, ACL o percorsi VPC personalizzati applicati alla VPN impediscono il traffico tra la VPN e il server OAuth del cluster. Si può fare una prova consentendo temporaneamente tutto il traffico in entrata e in uscita attraverso il gruppo di sicurezza VPN e l'ACL e verificando se il problema si risolve. In tal caso, apportare le modifiche necessarie ai gruppi di sicurezza, alle ACL o alle rotte personalizzate per consentire il traffico.
       5. Verificare se eventuali regole CBR (Context Based Restriction) sul cluster impediscono al client di connettersi al server OAuth del cluster. Si può verificare aggiungendo temporaneamente una zona di rete alla regola CBR che consente tutti gli IP e le sottoreti. Se questa modifica temporanea risolve il problema, apportare le modifiche necessarie alla regola per consentire il traffico.
   
   

6. Verificare che la connessione a IAM sia riuscita.

   1. Eseguire i comandi.

       curl -vvv https://iam.cloud.ibm.com/healthz
       curl -vvv -o /dev/null -s https://login.ibm.com/
       ```
   2. Se uno di questi comandi non funziona, verificare che il sistema client sia in grado di connettersi a questi URL in modo affidabile e che gli URL non siano bloccati da firewall del cliente o dell'azienda. Si noti che questi URL richiedono l'accesso a Internet pubblico.
   
   

5. Contatta l'assistenza

Se sono stati completati tutti i passaggi sopra descritti e il problema non è stato risolto, contattare l'assistenza. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere tutti i file di log, i messaggi di errore o gli output dei comandi pertinenti.