Errore di ingresso: ERRIODEG

Virtual Private Cloud Infrastruttura classica Satellite

Imparare a risolvere gli errori di ERRIODEG quando l'operatore di ingresso è in uno stato degradato.

È possibile utilizzare il comando ibmcloud oc ingress status-report ignored-errors add per aggiungere un errore all'elenco degli errori ignorati. Gli errori ignorati vengono ancora visualizzati nell'output del comando ibmcloud oc ingress status-report get, ma vengono ignorati quando si calcola lo stato Ingress generale.

Quando controlli lo stato dei componenti Ingress del tuo cluster eseguendo il comando ibmcloud oc ingress status-report get, vedi un errore simile al seguente.

The Ingress Operator is in a degraded state (ERRIODEG).

L'operatore Ingress controlla l'integrità dei controller Ingress ed entra in uno stato danneggiato quando i controlli non riescono.

Verifica che i tuoi nodi non siano sovraccarichi. I nodi sovraccarichi possono causare il fallimento dei controlli di integrità di Ingress Operator.

Per verificare se si dispone di risorse sufficienti in termini di CPU e memoria, eseguire il seguente comando.

kubectl top nodes

Consulta i dettagli relativi all' ingress ClusterOperator e segui la procedura indicata nel messaggio di errore.

Controllare lo stato di ingress ClusterOperator. Se vedi False nella colonna DEGRADED, attendi da 10 a 15 minuti per vedere se l'avvertenza dello stato Ingress scompare. In caso contrario, procedere con la procedura di risoluzione dei problemi in base al messaggio nella colonna MESSAGE.

oc get clusteroperator ingress

Una o più condizioni di stato indicano non disponibile: DeploymentAvailable=False

  1. Assicurati che il tuo cluster abbia almeno due nodi di lavoro. Per ulteriori informazioni, vedi Aggiunta di nodi di lavoro ai cluster Classic o Aggiunta di nodi di lavoro ai cluster VPC.
  2. Assicurati che i tuoi nodi di lavoro del cluster siano integri, altrimenti i pod del controller Ingress non possono essere pianificati. Per ulteriori informazioni, vedi Stati del nodo di lavoro.

Una o più condizioni di stato indicano non disponibile: LoadBalancerReady=False

  1. Solo VPC: assicurati di non aver raggiunto la quota della tua istanza LBaaS. Per ulteriori informazioni, vedi Quote e limiti del servizio e il comando ibmcloud is load-balancers .
  2. Assicurati che i tuoi master cluster siano integri. Per ulteriori informazioni, vedi Revisione dell'integrità master.
  3. Aggiorna i tuoi master cluster eseguendo il comando ibmcloud oc cluster master refresh .

Una o più altre condizioni di stato indicano uno stato danneggiato: CanaryChecksSucceeding=False

  1. Accedi al tuo cluster Red Hat OpenShift.

  2. Assicurati che l'indirizzo di servizio LoadBalancer sia registrato per il tuo dominio secondario Ingress.

    1. Esegui il ibmcloud oc cluster get comando per vedere il tuo dominio secondario Ingress.
    2. Eseguire il comando ibmcloud oc nlb-dns get per visualizzare gli indirizzi registrati.
    3. Esegui il comando oc get services -n openshift-ingress per ottenere gli indirizzi del programma di bilanciamento del carico effettivi.
    4. Confrontare gli indirizzi registrati e quelli effettivi e aggiornare il sottodominio se differisce. VPC: eseguire il comando ibmcloud oc nlb-dns replace per sostituire l'indirizzo corrente. Classic: rimuovere gli indirizzi attualmente registrati eseguendo il comando ibmcloud oc nlb-dns rm classic , quindi aggiungere i nuovi indirizzi con il comando ibmcloud oc nlb-dns add . Satellite: Gli indirizzi effettivi dipendono dalla configurazione: se i nodi di lavoro sono esposti tramite un bilanciatore di carico esterno, registrare gli indirizzi del bilanciatore di carico; in caso contrario, registrare gli indirizzi IP assegnati al servizio router-external-default nel namespace openshift-ingress (utilizzare il comando oc get services -n openshift-ingress router-external-default -o yaml per recuperare gli indirizzi). Rimuovere gli indirizzi attualmente registrati eseguendo il comando ibmcloud oc nlb-dns rm classic , quindi aggiungerli con il comando ibmcloud oc nlb-dns add .

  3. Solo VPC: il traffico del controllo di integrità del canary ha origine da uno dei nodi di lavoro del tuo cluster.

    • Il traffico del controllo di integrità ha origine da un nodo di lavoro del tuo cluster. Nel caso di cluster con endpoint del servizio pubblico, il traffico viene indirizzato all'indirizzo IP mobile pubblico dell'istanza di VPC Load Balancer, pertanto è necessario che abbia un Public Gateway collegato a tutte le sottoreti del nodo di lavoro. Nel caso di cluster con solo endpoint del servizio privati, il traffico viene indirizzato all'indirizzo IP della sottorete VPC del programma di bilanciamento del carico VPC, pertanto non è richiesto un Public Gateway. Per i cluster con endpoint di servizio pubblico:
      1. Esegui ibmcloud is public-gateways per vedere i tuoi gateway pubblici.
      2. Esegui ibmcloud is subnets per vedere le tue sottoreti.
      3. Per ogni sottorete esegui ibmcloud is subnet <subnet-id> per controllare ogni volta che ha un gateway pubblico.
        1. Se la tua sottorete non ha un gateway pubblico collegato, devi collegarne uno. Per ulteriori informazioni, vedi Creazione di gateway pubblici
    • Se i tuoi programmi di bilanciamento del carico VPC si trovano su una sottorete diversa dai nodi di lavoro del tuo cluster, devi aggiornare il gruppo di sicurezza collegato alla sottorete del programma di bilanciamento del carico VPC per consentire il traffico in entrata dalle sottoreti di lavoro.
    • Per ulteriori informazioni, vedi Creazione di un cluster Red Hat OpenShift nel tuo Virtual Private Cloud, Configurazione delle sottoreti VPC e Creazione e gestione dei gruppi di sicurezza VPC.

  4. Assicurarsi che nessuna regola del firewall blocchi il traffico canary o il traffico DNS su UDP e TCP. VPC: il traffico "canary" ha origine da uno dei nodi di lavoro, passa attraverso un VPC Public Gateway e arriva al lato pubblico dell'istanza del bilanciatore di carico VPC. Configurare i gruppi di protezione VPC per consentire questa comunicazione. Per ulteriori informazioni, vedere Comprendere la rete VPC sicura per impostazione predefinita del cluster e Creare e gestire i gruppi di sicurezza VPC. Classico: il traffico canario ha origine dall'indirizzo IP pubblico di uno dei nodi worker e arriva all'indirizzo IP pubblico dei bilanciatori di carico classici. Configurare le politiche di rete per consentire questa comunicazione. Per ulteriori informazioni, vedere Controllo del traffico con i criteri di rete sui cluster classici.

Passi successivi

  1. Attendere 30 minuti, quindi eseguire il comando oc get clusteroperator ingress e controllare nuovamente la colonna MESSAGE.
  2. Se viene visualizzato un messaggio di errore diverso, ripetere la procedura di risoluzione dei problemi.
  3. Se il problema persiste, contattare il supporto. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere i file di log, i messaggi di errore o gli output dei comandi pertinenti.