Erro de entrada: ERRIODEG

Nuvem privada virtual Infraestrutura clássica Satellite

Saiba como resolver os erros de ERRIODEG quando o operador de entrada está em um estado degradado.

É possível usar o comando ibmcloud oc ingress status-report ignored-errors add para incluir um erro na lista de erros ignorados Erros ignorados ainda aparecem na saída do comando ibmcloud oc ingress status-report get, mas são ignorados ao calcular o Status do Ingresso geral.

Ao verificar o status dos componentes do Ingresso do seu cluster executando o comando ibmcloud oc ingress status-report get, você vê um erro semelhante ao seguinte.

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

O Operador Ingresso verifica o funcionamento dos Controladores de Ingresso e entra em um estado degradado quando as verificações falham.

Verifique se seus nós não estão sobrecarregados. Nós sobrecarregados podem fazer com que as verificações de integridade do Ingress Operator falhem.

Para verificar se você dispõe de capacidade suficiente na CPU e na memória, execute o comando a seguir.

kubectl top nodes

Acesse os detalhes do artigo “ ingress ” ( ClusterOperator ) e siga as etapas indicadas na mensagem de erro.

Verifique o status do ingress ClusterOperator. Se você ver False na coluna DEGRADED, aguarde de 10 15 minutes minutos para ver se o aviso de Status Ingresso desaparece. Se não, prossiga com as etapas de resolução de problemas com base na mensagem na coluna MESSAGE.

oc get clusteroperator ingress

Uma ou mais condições de status indicam indisponível: DeploymentAvailable=False

  1. Assegure-se de que seu cluster tenha pelo menos dois trabalhadores. Para obter mais informações, consulte Incluindo nós do trabalhador em clusters Classic ou Incluindo nós do trabalhador em clusters VPC..
  2. Certifique-se de que seus funcionários de cluster estão saudáveis, caso contrário os pods do Controlador Ingresso não podem ser planejados Para obter mais informações, consulte Estados do nó do trabalhador.

Uma ou mais condições de status indicam indisponível: LoadBalancerReady=False

  1. Apenas VPC: Certifique-se de que você não atingiu a sua cota de instância LBaaS. Para obter mais informações, consulte Cotas e limites de serviço e o comando ibmcloud is load-balancers.
  2. Garanta que seus mestres de cluster estejam saudáveis. Para obter mais informações, consulte Revisando a saúde master.
  3. Atualize seus masters de cluster executando o comando ibmcloud oc cluster master refresh .

Uma ou mais outras condições de status indicam um estado degradado: CanaryChecksSucceeding=False

  1. Acesse o seu Red Hat OpenShift cluster.

  2. Certifica-se de que o endereço de serviço correto LoadBalancer esteja registrado para o seu subdomínio Ingress.

    1. Execute o comando ibmcloud oc cluster get para ver o seu subdomínio Ingress.
    2. Execute o ibmcloud oc nlb-dns get comando para ver os endereços registrados.
    3. Execute o comando oc get services -n openshift-ingress para obter os endereços reais do balanceador de carga.
    4. Compare os endereços registrados e reais e atualize o subdomínio se ele difere. VPC: Executar o comando ibmcloud oc nlb-dns replace para substituir o endereço atual. Classic: Remova os endereços registrados atualmente executando o ibmcloud oc nlb-dns rm classic comando, em seguida, adiciam os novos endereços com o comando ibmcloud oc nlb-dns add . Satellite: Os endereços efetivos dependem da sua configuração: se você expor seus nós de trabalho por meio de um balanceador de carga externo, registre os endereços do balanceador de carga; caso contrário, registre os endereços IP atribuídos ao serviço router-external-default no namespace openshift-ingress (use o comando oc get services -n openshift-ingress router-external-default -o yaml para recuperar os endereços). Remova os endereços registrados atualmente executando o comando ibmcloud oc nlb-dns rm classic, em seguida, inclua os novos endereços com o comando ibmcloud oc nlb-dns add .

  3. Somente VPC: o tráfego de verificação de funcionamento canário é originado de um dos nós do trabalhador de seu cluster..

    • O tráfego de verificação de funcionamento é originário de um dos nós do trabalhador de seu cluster. No caso de clusters com terminal de serviço público, o tráfego é direcionado para o endereço IP flutuante público da instância do VPC Load Balancer, portanto, é necessário ter um Public Gateway anexado a todas as sub-redes do trabalhador No caso de clusters com somente terminais em serviço privados, o tráfego é direcionado para o endereço IP de sub-rede do VPC Load Balancer, portanto, um Public Gateway não é necessário. Para clusters com terminal em serviço público:
      1. Execute o ibmcloud is public-gateways para ver seus gateways públicos.
      2. Execute o ibmcloud is subnets para ver suas sub-redes.
      3. Para cada sub-rede execute o ibmcloud is subnet <subnet-id> para verificar sempre que ele tiver um gateway público.
        1. Se a sua sub-rede não tiver um gateway público anexado, é necessário anexar um. Para obter mais informações, consulte Criando gateways públicos
    • Se seus VPC Load Balancers estiverem localizados em uma sub-rede diferente dos nós do trabalhador de seu cluster, deve-se atualizar o Grupo de segurança anexado à sub-rede do VPC Load Balancer para permitir o tráfego recebido das sub-redes do trabalhador.
    • Para obter mais informações, consulte Criando um cluster do Red Hat OpenShift em sua nuvem privada virtual, Configurando sub-redes do VPC e Criando e gerenciando grupos de segurança do VPC.

  4. Certifique-se de que nenhuma regra de firewall bloqueie o tráfego do Canary ou o tráfego de DNS nos endereços UDP e TCP. VPC: o tráfego canário tem origem em um dos nós de trabalho, passa por um VPC Public Gateway e chega ao lado público da instância do VPC Load Balancer. Configure seus Grupos de Segurança do VPC para permitir essa comunicação. Para obter mais informações, consulte Noções básicas sobre redes de VPC de cluster seguras por padrão e Criação e gerenciamento de grupos de segurança de VPC. Clássico: o tráfego canário se origina do endereço IP público de um dos nós de trabalho e chega ao endereço IP público de seus balanceadores de carga clássicos. Configure suas políticas de rede para permitir essa comunicação. Para obter mais informações, consulte Controle de tráfego com políticas de rede em clusters clássicos.

Próximas etapas

  1. Aguarde 30 minutes minutos, em seguida, execute o comando oc get clusteroperator ingress e verifique a coluna MESSAGE novamente.
  2. Se você vir uma mensagem de erro diferente repita as etapas de resolução de problemas.
  3. Se o problema persistir, entre em contato com o suporte. Abrir um caso de suporte. Nos detalhes do caso, certifique-se de incluir qualquer arquivo de log relevante, mensagens de erro ou saídas de comandos.