Cluster VPC con un endpoint di servizio pubblico e privato: Perché non riesco a connettermi alla console OpenShift?

Risoluzione dei problemi di connessione alla console OpenShift su un cluster che ha un endpoint di servizio sia pubblico che privato.

Le informazioni contenute in questa guida alla risoluzione dei problemi si riferiscono ai cluster VPC con un endpoint di servizio sia pubblico che privato.

1. Comprendere il flusso di connessioni del cluster

Il diagramma seguente mostra il flusso di connessione per un cluster VPC con endpoint di servizio sia pubblici che privati per connettersi alla console web OpenShift. Si noti che tutte le connessioni dal browser web ai componenti del cluster avvengono attraverso la rete pubblica. Esaminare questo diagramma e le descrizioni seguenti per capire meglio quali sono i passaggi necessari per la risoluzione dei problemi.

OpenShift flusso di connessione della console web per un cluster VPC con endpoint di servizio sia pubblici che privati flusso di connessione della console web per un cluster VPC con endpoint di servizio sia pubblici che privati. — OpenShift

Il browser web si collega al server API del master del cluster. Viene scambiato un certificato firmato e un reindirizzamento istruisce il browser web a connettersi invece al load balancer pubblico della console OpenShift.
(a) Il browser web si connette al bilanciatore di carico della console OpenShift che espone la console OpenShift. (b) La richiesta viene inviata a uno dei due pod openshift-console.
Il pod openshift-console si connette tramite la rete pubblica 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.
Il browser web si collega alla porta del server OAuth del cluster, che reindirizza il client a IAM.
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.
Il browser web si connette nuovamente alla porta del server OAuth del cluster. La connessione viene reindirizzata al bilanciatore di carico della console OpenShift.
Il browser Web si connette 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

Assicurarsi che il browser web abbia accesso alla rete pubblica in modo da potersi connettere all'apiserver del cluster, al bilanciatore di carico della console OpenShift e a IAM (che utilizza sia iam.cloud.ibm.com che login.ibm.com)
Assicurarsi che se sono stati modificati gruppi di sicurezza, ACL o regole CBR (Context-Base Restriction) per il cluster o il bilanciatore di carico, questi consentano il traffico da questo browser web alle risorse in questione

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.

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

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.<REGION>.containers.cloud.ibm.com:<YYYYY>`.

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. L'indirizzo URL deve avere il seguente formato: `https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
```

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

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

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

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.

Verificare che gli operatori del cluster OpenShift siano sani.

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.

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

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

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

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

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

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

Verificare che la connessione a IAM sia riuscita.

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.