Passo 1: controlla la configurazione dell'account

Controlla che il tuo account IBM Cloud sia configurato correttamente. Alcuni scenari comuni che possono impedire l'esecuzione corretta dei componenti predefiniti includono:

• Se il cluster classico presenta più zone, oppure se si dispone di un cluster VPC, assicurarsi di abilitare il VRF o lo spanning VLAN. Per verificare se VRF è già abilitato, esegui ibmcloud account show. Per verificare se lo spanning VLAN è abilitato, eseguire il comando ibmcloud oc vlan spanning get``.
• Se alcuni utenti nell'account utilizzano un'autenticazione multifattore (MFA) come TOTP, assicurati di abilitare MFA per tutti gli utenti nell'account IBM Cloud.

L'abilitazione della MFA a livello utente non è supportata. Se MFA è abilitato per alcuni utenti ma non per tutti gli utenti a livello di account, potrebbero verificarsi errori di autenticazione.

Passo 2: controlla il gateway pubblico

• Per i cluster VPC con endpoint del servizio cloud pubblico e privato abilitati:

  Verifica che su ciascuna sottorete VPC a cui è collegato il tuo cluster sia abilitato un gateway pubblico. Il gateway pubblico è richiesto per i componenti predefiniti come la console web e OperatorHub per utilizzare una connessione pubblica e sicura per completare azioni come il pull di immagini da registri privati remoti.

  1. Utilizza la console o la CLI IBM Cloud per assicurarti che un gateway pubblico sia abilitato su ogni sottorete a cui è collegato il tuo cluster.
  2. Riavvia i componenti per il Developer catalog nella console web.
     1. Modifica la mappa di configurazione per l'operatore degli esempi.

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

  3. Modifica il valore di managementState da Removed a Managed. 3. Salva e chiudi la mappa di configurazione. Le tue modifiche vengono applicate automaticamente.

• Per i cluster classici con endpoint del servizio cloud sia pubblici che privati abilitati:

  Controlla che il tuo cluster abbia la connettività pubblica in modo che i componenti di rete possano comunicare con il master man mano che vengono distribuiti.

  1. Controlla il valore di Master Status. Se Master Status non è Ready, riesamina il suo stato e attieniti alle eventuali informazioni di risoluzione dei problemi per correggere il problema.

      ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
      ```
  1. Nell'output "**Master Status** ", verifica che il tuo cluster disponga di un **endpoint di servizio pubblico URL**. Se il tuo cluster non dispone di un endpoint del servizio cloud pubblico, abilitalo.
  1. Verifica che almeno alcuni nodi di lavoro del tuo cluster dispongano di un indirizzo **IP pubblico**. Se nessun nodo di lavoro lo fa, è necessario configurare delle VLAN pubbliche per almeno un pool di worker.
  
  ```sh {: pre}
      ibmcloud oc workers -c CLUSTER_NAME_OR_ID
      ```
  

Passo 3: controlla i firewall e le politiche di rete

Controlla eventuali firewall o politiche di rete per verificare che non blocchi alcun traffico in entrata o in uscita per OperatorHub o altri componenti Red Hat OpenShift.

• Se hai generato un elenco di autorizzazioni IBM Cloud Identity and Access Management (IAM) specificando quali indirizzi IP hanno accesso al tuo cluster, devi aggiungere i CIDR del piano di controllo Red Hat OpenShift on IBM Cloud delle zone nella regione in cui si trova il tuo cluster all'elenco di autorizzazioni.
• Solo classico: se hai un firewall, apri le porte e gli indirizzi IP richiesti nel tuo firewall.
• Solo VPC: se controlli il traffico con gli ACL o i gruppi di sicurezza VPC, assicurati di consentire le regole in entrata e in uscita minime richieste.

Fase 4: controllare la configurazione del cluster

Verifica che il tuo cluster sia configurato correttamente. Se hai appena creato il cluster, attendi qualche istante affinché il provisioning dei componenti del cluster venga completato.

1. Ottieni i dettagli del tuo cluster.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

2. Riesamina l'output del passo precedente per controllare il dominio secondario Ingress.
   • Se il tuo cluster non ha un dominio secondario, vedi Non esiste alcun dominio secondario Ingress dopo la creazione del cluster.
   • Se il tuo cluster ha un dominio secondario, continua al passo successivo.
3. Verifica che il tuo cluster utilizzi l'ultima versione della patch. Se il cluster non utilizza l'ultima versione della patch, aggiornare il cluster e i nodi di lavoro.
   1. Aggiorna il master cluster alla versione di patch più recente per la tua versione principale e secondaria del cluster.

       ibmcloud oc cluster master update -c CLUSTER_NAME_OR_ID --version MAJOR.MINOR_openshift-f
       ```
   2. Elenca i tuoi nodi di lavoro.
   ```sh {: pre}
       ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
       ```
   3. [Aggiorna i nodi di lavoro](/docs/openshift?topic=openshift-update#worker_node) perché corrispondano alla versione del master cluster.
   ```sh {: pre}
       ibmcloud oc worker update -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID -w WORKER3_ID
       ```
   

4. Controlla il valore State del cluster. Se lo stato non è normale, rivedere lo stato del cluster e risolvere eventuali problemi.
5. Controlla il valore Master health. Se lo stato non è normale, rivedere lo stato di salute master e risolvere eventuali problemi.
6. Verificare i nodi di lavoro su cui potrebbero essere in esecuzione i componenti di Red Hat OpenShift. Se lo stato non è normal, vedi Debug dei nodi di lavoro.

   ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
   

Passo 5: accedi al tuo cluster

Accedi al tuo cluster. Si noti che, qualora la console web Red Hat OpenShift non funzionasse per ottenere il token di accesso, è possibile accedere al cluster tramite la CLI.

Solo VPC: se hai abilitato l'endpoint del servizio cloud privato, devi essere connesso alla rete privata tramite la tua connessione VPN VPC per accedere alla console web.

Passo 6: controlla i pod dei componenti

Verifica lo stato di funzionamento dei pod del componente " Red Hat OpenShift " che non funzionano.

1. Controlla lo stato del pod.

   oc get pods -n <project>
   

2. Se un pod non si trova nello stato Running, descrivilo e verifica la presenza di eventi. Ad esempio, potrebbe comparire un errore che indica che il pod non può essere pianificato a causa della mancanza di risorse CPU o di memoria, cosa che capita spesso se si dispone di un cluster con meno di 3 nodi di lavoro. Ridimensiona il tuo pool di nodi di lavoro Classic o Ridimensiona il tuo pool di nodi di lavoro VPC e riprova.

   oc describe pod -n <project> <pod>
   

3. Se nella sezione "Eventi" non trovi informazioni utili, controlla i log dei pod per verificare la presenza di eventuali messaggi di errore o altre informazioni utili alla risoluzione dei problemi.

   oc logs pod -n <project> <pod>
   

4. Riavvia il pod e controlla se raggiunge uno stato Running.

   oc delete pod -n <project> <pod>
   

Passo 7: controlla i pod di sistema

Se i pod sono integri, controlla se si verificano problemi con altri pod del sistema. Per funzionare correttamente, spesso l'integrità di un componente dipende da un altro componente.

Ad esempio, OperatorHub ha una serie di immagini memorizzate in registri esterni come quay.io. Queste immagini vengono importate nel registro interno per essere utilizzate in tutti i progetti del cluster Red Hat OpenShift. Se uno qualsiasi dei componenti di OperatorHub o del registro interno non è configurato correttamente, ad esempio a causa della mancanza di autorizzazioni o di risorse di calcolo, l' OperatorHub e e il catalogo non vengono visualizzati.

1. Controlla l'eventuale presenza di pod in sospeso.

   oc get pods --all-namespaces | grep Pending
   

2. Descrivi i pod e verifica la presenza di Eventi.

   oc describe pod -n <project_name> <pod_name>
   

   Ad esempio, alcuni messaggi comuni che potresti vedere dai pod openshift-image-registry includono:
   • Un messaggio di errore Volume could not be created perché hai creato il cluster senza l'autorizzazione di archiviazione corretta. Red Hat OpenShift on IBM Cloud i cluster vengono forniti con un dispositivo di archiviazione file per impostazione predefinita per memorizzare immagini per il sistema e altri pod. Riesamina le tue autorizzazioni dell'infrastruttura e riavvia il pod.
   • Un messaggio di errore order will exceed maximum number of storage volumes allowed perché hai superato la quota combinata di dispositivi di archiviazione file e blocchi consentiti per ogni account. Rimuovi i dispositivi di archiviazione inutilizzati o aumenta la tua quota di archiviazione e riavvia il pod.
   • Messaggio che indica che non è possibile salvare le immagini perché il dispositivo di archiviazione è pieno. Ridimensiona il dispositivo di archiviazione e riavvia il pod.
   • Viene visualizzato un messaggio di errore " Pull image still failed due to error: unauthorized: authentication required " poiché il registro interno non è in grado di recuperare le immagini da un registro esterno. Verifica che per il progetto siano stati impostati i segreti di pull dell'immagine e riavvia il pod.
3. Controlla il Nodo su cui vengono eseguiti i pod in errore. Se tutti i pod vengono eseguiti sullo stesso nodo di lavoro, il nodo di lavoro potrebbe avere un problema di connettività di rete. Ricarica il nodo di lavoro.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Passo 8: controlla la VPN

Verificare che la VPN nel cluster sia configurata correttamente.

1. Verifica che il pod VPN sia in esecuzione.

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

2. Controlla i log della VPN e verifica la presenza di un messaggio di errore " ERROR " ( ), ad esempio " WORKERIP:<port>" o "WORKERIP:10250", che indica che il tunnel VPN non funziona.

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

3. Se vedi l'errore per l'IP del nodo di lavoro, verifica se le comunicazioni tra i nodi di lavoro sono interrotte. Accedi a un pod calico-node nel progetto calico-system e verifica la presenza dello stesso errore WORKERIP:10250.

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

4. Se le comunicazioni tra i nodi di lavoro sono interrotte, assicurati di abilitare VRF o lo spanning della VLAN.
5. Se viene visualizzato un errore diverso da quello relativo al pod VPN o al pod " calico-node ", riavvia il pod VPN.

   oc delete pod -n kube-system <vpn_pod>
   

6. Se la VPN continua a non funzionare, controlla il nodo di lavoro su cui è in esecuzione il pod.

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

7. Isolare il nodo di lavoro in modo che il pod VPN venga riprogrammato su un altro nodo di lavoro.

   oc cordon <worker_node>
   

8. Controlla di nuovo i log del pod VPN. Se il pod non presenta più un errore, il nodo di lavoro potrebbe avere un problema di connettività di rete. Ricarica il nodo di lavoro.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Passo 9: aggiorna il master cluster

Aggiornare il master del cluster per configurare i componenti predefiniti di Red Hat OpenShift. Dopo aver aggiornato il cluster, attendi alcuni minuti per consentire il completamento dell'operazione.

ibmcloud oc cluster master refresh -c CLUSTER_NAME_OR_ID

Passo 10: Riprova

Prova a utilizzare nuovamente il componente " Red Hat OpenShift ".

Se l'errore continua a essere presente, vedi Feedback, domande e supporto.