Etapa 1: Verificar a configuração de sua conta

Verifique se a sua conta do IBM Cloud está configurada adequadamente. Alguns cenários comuns que podem evitar que os componentes padrão sejam executados adequadamente incluem os seguintes:

• Se o seu cluster clássico tiver múltiplas zonas ou se você tiver um cluster de VPC, certifique-se de ativar VRF ou VLAN spanning. Para verificar se o VRF já está ativado, execute ibmcloud account show. Para verificar se a ampliação de VLAN está ativada, execute ibmcloud oc vlan spanning get.
• Se alguns usuários da conta utilizarem uma autenticação multifatorial (MFA), como o TOTP, certifique-se de habilitar a MFA para todos os usuários da conta IBM Cloud.

A ativação do MFA no nível do usuário não é suportada. Se o MFA estiver ativado para alguns usuários, mas não for ativado para todos os usuários no nível da conta, podem ocorrer erros de autenticação.

Etapa 2: Confira o gateway público

• Para clusters VPC com terminais em serviço de nuvem pública e privada ativados:

  Verifique se um gateway público está ativado em cada sub-rede VPC a qual seu cluster está conectado. São necessários gateways públicos para que componentes padrão, como o console da web e o OperatorHub, usem uma conexão segura e pública para concluir ações, como extrair imagens de registros remotos e privados.

  1. Use o console do IBM Cloud ou a CLI para garantir que um gateway público esteja ativado em cada sub-rede à qual seu cluster está conectado.
  2. Reinicie os componentes para o Catálogo do desenvolvedor no console da web.
     1. Edite o configmap para o operador de amostras.

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

  3. Mude o valor de managementState de Removed para Managed. 3. Salve e feche a configuração do mapa. Suas mudanças são aplicadas automaticamente.

• Para clusters clássicos com terminais em serviço de nuvem pública e privada ativados:

  Verifique se o seu cluster tem conectividade pública para que os componentes de rede possam falar com o mestre conforme eles implementarem.

  1. Verifique o Status do mestre. Se o Status do mestre não estiver Pronto, revise seu status e siga qualquer informação de resolução de problemas para resolver o problema.

      ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
      ```
  1. Na saída **Status do principal**, verifique se o seu cluster tem uma **URL de terminal em serviço público**. Se o seu cluster não tiver um endpoint de serviço em nuvem pública, habilite-o.
  1. Verifique se pelo menos alguns nós do trabalhador em seu cluster têm um endereço **IP público**. Se nenhum nó de trabalho o fizer, você deverá configurar VLANs públicas para pelo menos um pool de trabalho.
  
  ```sh {: pre}
      ibmcloud oc workers -c CLUSTER_NAME_OR_ID
      ```
  

Etapa 3: Verificar firewalls e políticas de rede

Confira quaisquer firewalls ou políticas de rede para verificar se você não bloqueia nenhum tráfego de ingresso ou egresso para o OperatorHub ou outros componentes do Red Hat OpenShift.

• Se você tiver gerado uma lista de permissões do IBM Cloud Identity and Access Management (IAM) especificando quais endereços IP têm acesso ao seu cluster, inclua os CIDRs do plano de controle do Red Hat OpenShift on IBM Cloud para as zonas na região na qual seu cluster está localizado na lista de permissões.
• Classic apenas: se você tiver um firewall, abra as portas e os endereços IP necessários no seu firewall.
• VPC apenas: se você controlar o tráfego com ACLs de VPC ou grupos de segurança, certifique-se de permitir o mínimo de regras de entrada e saída necessário.

Etapa 4: Verificar a configuração do cluster

Verifique se o seu cluster está configurado adequadamente. Se você tiver acabado de criar seu cluster, aguarde um tempo até que os componentes dele sejam totalmente provisionados.

1. Obtém os detalhes do seu cluster.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

2. Revise a saída da etapa anterior para verificar o Subdomínio do Ingress.
   • Se o seu cluster não tiver um subdomínio, consulte Não existe nenhum subdomínio do Ingress após a criação do cluster.
   • Se o seu cluster tiver um subdomínio, continue com a próxima etapa.
3. Verifique se seu cluster executa a Versão de correção mais recente. Se o seu cluster não executar a versão de correção mais recente, atualize o cluster e os nós do trabalhador.
   1. Atualize o cluster mestre para a versão de correção mais recente para a versão secundária e principal do seu cluster.

       ibmcloud oc cluster master update -c CLUSTER_NAME_OR_ID --version MAJOR.MINOR_openshift-f
       ```
   2. Liste seus nós do trabalhador
   ```sh {: pre}
       ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
       ```
   3. [Atualize os nós do trabalhador](/docs/openshift?topic=openshift-update#worker_node) para corresponder à versão do cluster mestre.
   ```sh {: pre}
       ibmcloud oc worker update -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID -w WORKER3_ID
       ```
   

4. Verifique o Estado do cluster. Se o estado não for normal, revise o estado do cluster e resolva os problemas.
5. Verifique o Funcionamento do mestre. Se o estado não for normal, revise o status de saúde principal e resolva todos os problemas.
6. Verifique os nós do trabalhador nos quais os componente do Red Hat OpenShift podem executar. Se o estado não for normal, consulte Depurando nós do trabalhador.

   ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
   

Etapa 5: Efetuar login em seu cluster

Efetue login no seu cluster. Note que se o console da web do Red Hat OpenShift não funcionar para você obter o token de login, será possível acessar o cluster por meio da CLI.

VPC apenas: se você ativou o terminal em serviço de nuvem privada, deverá estar conectado à rede privada por meio de sua conexão VPC VPN para acessar o console da web.

Etapa 6: Verificar os pods do componente

Verifique o funcionamento dos pods de componente do Red Hat OpenShift que não funcionam.

1. Verifique o status do pod.

   oc get pods -n <project>
   

2. Se um pod não estiver em um status Em execução, descreva o pod e verifique os eventos. Por exemplo, você pode ver um erro de que o pod não pode ser planejado por falta de recursos de CPU ou de memória, o que é comum se você tem um cluster com menos de 3 nós do trabalhador. Redimensione seu conjunto de trabalhadores clássicos ou Redimensione seu conjunto de trabalhadores da VPC e tente novamente.

   oc describe pod -n <project> <pod>
   

3. Se você não vir nenhuma informação útil na seção de eventos, verifique os logs do pod para quaisquer mensagens de erro ou outras informações de resolução de problemas.

   oc logs pod -n <project> <pod>
   

4. Reinicie o pod e verifique se ele atinge um status Em execução.

   oc delete pod -n <project> <pod>
   

Etapa 7: Verificar os pods do sistema

Se os pods estiverem funcionais, verifique se outros pods do sistema estão experimentando problemas. Muitas vezes, para funcionar adequadamente, um componente depende de outro componente para estar funcional.

Por exemplo, o OperatorHub tem um conjunto de imagens que são armazenadas em registros externos, como quay.io. Essas imagens são extraídas para o registro interno para uso entre os projetos em seu cluster Red Hat OpenShift. Se algum dos componentes do OperatorHub ou do registro interno não for configurado adequadamente, como por exemplo, por falta de permissões ou recursos de cálculo, o OperatorHub e o catálogo não serão exibidos.

1. Verifique os pods pendentes.

   oc get pods --all-namespaces | grep Pending
   

2. Descreva os pods e verifique os Eventos.

   oc describe pod -n <project_name> <pod_name>
   

   Por exemplo, algumas mensagens comuns que é possível ver por meio dos pods openshift-image-registry incluem:
   • Uma mensagem de erro Volume could not be created porque você criou o cluster sem a permissão de armazenamento correta. Os clusters do Red Hat OpenShift on IBM Cloud vêm com um dispositivo de armazenamento de arquivos por padrão para armazenar imagens para o sistema e outros pods. Revise suas permissões de infraestrutura e reinicie o pod.
   • Uma mensagem de erro order will exceed maximum number of storage volumes allowed porque você excedeu a cota combinada de dispositivos de armazenamento de arquivo e de bloco que são permitidos por conta. Remova os dispositivos de armazenamento não usados ou aumente sua cota de armazenamento e reinicie o pod.
   • Uma mensagem de que as imagens não podem ser armazenadas porque o dispositivo de armazenamento de arquivos está cheio. Redimensione o dispositivo de armazenamento e reinicie o pod.
   • Uma mensagem de erro Pull image still failed due to error: unauthorized: authentication required porque o registro interno não consegue tirar imagens de um registro externo. Verifique se os segredos de extração de imagem estão configurados para o projeto e reinicie o pod.
3. Verifique o Nó no qual os pods com falha são executados. Se todos os pods forem executados no mesmo nó do trabalhador, o nó do trabalhador poderá ter um problema de conectividade de rede. Recarregue o nó do trabalhador.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Passo 8: Verifique a VPN

Verifique se a VPN no cluster está configurada corretamente.

1. Verifique se o pod da VPN está em execução.

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

2. Verifique os registros da VPN e procure por uma mensagem do tipo “ ERROR ”, como “ WORKERIP:<port> ” ou “WORKERIP:10250 ”, que indica que o túnel da VPN não está funcionando.

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

3. Se você vir o erro de IP do trabalhador, verifique se a comunicação de trabalhador para trabalhador está interrompida. Efetue login em um pod calico-node no projeto calico-system e verifique o mesmo erro WORKERIP:10250.

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

4. Se a comunicação de trabalhador para trabalhador estiver interrompida, certifique-se de ativar VRF ou VLAN spanning.
5. Se você observar um erro diferente do pod da VPN ou do pod “ calico-node ”, reinicie o pod da VPN.

   oc delete pod -n kube-system <vpn_pod>
   

6. Se a VPN continuar apresentando falhas, verifique o nó de trabalho no qual o pod está sendo executado.

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

7. Isolar o nó de trabalho para que o pod da VPN seja remanejado para um nó de trabalho diferente.

   oc cordon <worker_node>
   

8. Verifique os logs do pod da VPN novamente. Se o pod não tiver mais um erro, o nó do trabalhador poderá ter um problema de conectividade de rede. Recarregue o nó do trabalhador.

   ibmcloud oc worker reload -c CLUSTER_NAME_OR_ID -w WORKER_NODE_ID
   

Etapa 9: Atualizar o cluster mestre

Atualize o cluster mestre para configurar os componentes padrão do Red Hat OpenShift. Depois de atualizar o cluster, espere alguns minutos para permitir a conclusão da operação.

ibmcloud oc cluster master refresh -c CLUSTER_NAME_OR_ID

Etapa 10: Tentar novamente

Tente usar o componente do Red Hat OpenShift novamente.

Se o erro ainda existir, consulte Feedback, perguntas e suporte.