1. Compreensão do fluxo de conexão do cluster

O diagrama a seguir mostra o fluxo de conexão para um cluster VPC com pontos de extremidade de serviço públicos e privados para conexão com o console da Web OpenShift. Observe que todas as conexões do navegador da Web com os componentes do cluster ocorrem pela rede pública. Examine este diagrama e as descrições a seguir para entender melhor as etapas de solução de problemas que podem ser necessárias.

1. O navegador da Web se conecta ao servidor de API mestre do cluster. Um certificado assinado é trocado e um redirecionamento instrui o navegador da Web a se conectar ao balanceador de carga público do console OpenShift.
2. (a) O navegador da Web se conecta ao balanceador de carga do console OpenShift que expõe o console OpenShift. (b) Essa solicitação é enviada a um dos dois pods do openshift-console.
3. O pod openshift-console se conecta por meio da rede pública à porta do servidor mestre do cluster OAuth para verificar se a conexão já está autenticada. Se a solicitação já estiver autenticada, a conexão com o console da Web OpenShift estará concluída e o console da Web poderá ser acessado. Se a solicitação não for autenticada, o usuário será redirecionado para o serviço OAuth do cluster no mestre do cluster.
4. O navegador da Web se conecta à porta do servidor OAuth do cluster, que redireciona o cliente para o IAM.
5. O navegador da Web se conecta ao IAM pela rede pública. O usuário digita sua senha e, se necessário, uma verificação 2FA. Se essa etapa for bem-sucedida, o usuário será redirecionado de volta ao servidor OAuth do cluster.
6. O navegador da Web se conecta novamente à porta do servidor OAuth do cluster. A conexão é redirecionada de volta para o balanceador de carga do console OpenShift.
7. O navegador da Web se conecta ao balanceador de carga do console OpenShift, que expõe o console OpenShift. Essa solicitação é enviada a um dos dois pods do openshift-console, que se conecta novamente à porta do servidor OAuth do mestre do cluster para verificar se a conexão já está autenticada. Se o usuário tiver inserido a senha e a verificação 2FA, a autenticação será validada e o usuário será conectado à página principal do console OpenShift.

2. Verifique a configuração da VPC e do cluster

1. Certifique-se de que o navegador da Web tenha acesso à rede pública para que possa se conectar ao apiserver do cluster, ao balanceador de carga do console OpenShift e ao IAM (que usa tanto o iam.cloud.ibm.com quanto o login.ibm.com)
2. Se você modificou algum grupo de segurança, ACLs ou regras de restrição de base de contexto (CBR) para esse cluster ou balanceador de carga, certifique-se de que eles permitam o tráfego desse navegador da Web para esses recursos

3. Reunir dados do cluster

Siga estas etapas para reunir as informações do cluster necessárias para a solução de problemas. Os resultados que você obtém com esses comandos são usados em etapas posteriores.

1. Localize o servidor de API do cluster URL. Em comandos posteriores, esse URL é chamado de ${CLUSTER_APISERVER_URL}.

   1. Execute o comando ibmcloud ks cluster get -c CLUSTER_ID .

       ibmcloud oc cluster get -c CLUSTER_ID
       ```
   2. Na seção `Master` da saída, localize o `URL`. O endereço URL deve estar no seguinte formato: `https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<YYYYY>`.
   
   
   

2. Localize o cluster OAuth URL. Em comandos posteriores, esse URL é chamado de ${CLUSTER_OAUTH_URL}.

   1. Execute o comando kubectl get --raw /.well-known/oauth-authorization-server | grep issuer . Não use o ibmcloud oc cluster get -c CLUSTER_ID, pois esse comando pode retornar um URL diferente.

       kubectl get --raw /.well-known/oauth-authorization-server | grep issuer
       ```
   2. O endereço URL deve estar no seguinte formato: `https://c<XXX>-e.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
   
   

3. Encontre o subdomínio do Ingress. Em comandos posteriores, esse subdomínio é chamado de ${CONSOLE_LOAD_BALANCER}.

   1. Execute o comando ibmcloud oc cluster get -c CLUSTER_ID .

       ibmcloud oc cluster get -c CLUSTER_ID
       ```
   2. Na saída, localize o subdomínio que corresponde ao seguinte formato: `<CLUSTER-NAME-PLUS-RANDOM-UNIQUE-STRING>.<REGION>.containers.appdomain.cloud`. Observe que, se você tiver configurado um subdomínio Ingress personalizado, o formato corresponderá à sua configuração personalizada.
   
   

4. Verificar conexões e solucionar problemas

Siga estas etapas para verificar as conexões descritas no fluxo de conexão. Se você encontrar um problema com uma conexão, use as informações para solucionar o problema.

1. Verifique se o Ingress está íntegro e se os pods do roteador e do console estão íntegros.

   1. Execute os comandos.

       ibmcloud oc cluster get -c CLUSTERID
       ibmcloud oc ingress status-report get -c CLUSTERID
       ```
   2. Se a saída mostrar um status de erro, use a [documentação de solução de problemas do Ingress](/docs/openshift?topic=openshift-ingress-status) para resolver o problema.
   
   

2. Verifique se os operadores do cluster OpenShift estão saudáveis.

   1. Execute o comando.

       oc get clusteroperators
       ```
   2. Se a saída mostrar que algum operador não está íntegro ou não está sendo executado na versão atual, use a [documentação de solução de problemas da versão do cluster OpenShift](/docs/openshift?topic=openshift-ts-cluster-version-downlevel) para resolver o problema. Ou você pode pesquisar na documentação dos sites IBM e Red Hat para encontrar erros específicos que são mostrados.
   3. Se o operador do console especificamente não estiver íntegro, verifique os logs dos pods `openshift-console/console...` e `openshift-console-operator/console-operator...` para ver se um grupo de segurança, ACL ou personalização de DNS está impedindo que os pods se conectem à porta OAuth ou ao console OpenShift URL. Um grupo de segurança, ACL ou DNS pode estar configurado de forma a impedir a conexão.
   
   

3. Verifique se a conexão com o servidor de API mestre do cluster foi bem-sucedida.

   1. Execute o comando. Especifique o apiserver do cluster URL que você encontrou nas etapas anteriores.

       curl -k -vvv ${CLUSTER_APISERVER_URL}/version
       ```
   2. Se a conexão não for bem-sucedida, faça as seguintes verificações e resolva os problemas que encontrar.
       1. Verifique se o mestre do cluster está funcionando bem executando o comando `ibmcloud oc cluster get -c <CLUSTER-ID>`. Consulte [Revisão da integridade do mestre](/docs/openshift?topic=openshift-debug_master) para obter informações sobre a resolução de problemas do mestre do cluster.
       2. Verifique se a parte do nome do host do site URL foi resolvida via DNS. Use o comando `dig $(echo ${CLUSTER_APISERVER_URL} | cut -d/ -f3 | cut -d: -f1)` e especifique o servidor de API do cluster URL.
       3. Verifique se alguma regra de Restrição Baseada em Contexto (CBR) no cluster impede que o cliente se conecte ao servidor de API do cluster. Você pode testar isso adicionando temporariamente uma zona de rede à sua regra CBR pública que permite todos os IPs e sub-redes. Se essa alteração temporária resolver o problema, faça as alterações necessárias na regra para permitir o tráfego.
   
   

4. Verifique se a conexão com o balanceador de carga do cluster que expõe o console OpenShift foi bem-sucedida.

   1. Execute o comando. Especifique o subdomínio do Ingress que você encontrou nas etapas anteriores.

       curl -k -vvv https://console-openshift-console.${CONSOLE_LOAD_BALANCER}/
       ```
   2. Se a conexão não for bem-sucedida, faça as seguintes verificações e resolva os problemas que encontrar.
       1. Verifique se a parte do nome do host do subdomínio foi resolvida pelo DNS. Use o comando `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}`.
       2. Se você modificou algum grupo de segurança, ACLs ou rotas VPC personalizadas que são aplicadas ao balanceador de carga, verifique se as alterações ou regras aplicadas impedem a conexão. Se você não modificou nenhum desses componentes e eles usam os valores padrão, pode pular esta etapa.
   
   

5. Verifique se a conexão com o servidor do cluster OAuth foi bem-sucedida.

   1. Execute o comando. Especifique o cluster OAuth URL que você encontrou nas etapas anteriores.

       curl -k -vvv ${CLUSTER_OAUTH_URL}/healthz
       ```
   2. Se a conexão não for bem-sucedida, faça as seguintes verificações e resolva os problemas que encontrar.
       1. Verifique se o mestre do cluster está funcionando bem executando o comando `ibmcloud oc cluster get -c <CLUSTER-ID>`. Consulte [Revisão da integridade do mestre](/docs/openshift?topic=openshift-debug_master) para obter informações sobre a resolução de problemas do mestre do cluster.
       2. Verifique se a parte do nome do host do cluster OAuth URL está resolvida via DNS. Use o endereço `dig $(echo ${CLUSTER_OAUTH_URL} | cut -d/ -f3 | cut -d: -f1)` e especifique o cluster OAuth URL.
       3. Verifique se alguma regra de Restrição Baseada em Contexto (CBR) no cluster impede que o cliente se conecte ao servidor OAuth do cluster. Você pode testar isso adicionando temporariamente uma zona de rede à sua regra CBR pública que permite todos os IPs e sub-redes. Se essa alteração temporária resolver o problema, faça as alterações necessárias na regra para permitir o tráfego.
   
   

6. Verifique se a conexão com o IAM foi bem-sucedida.

   1. Execute os comandos.

       curl -vvv https://iam.cloud.ibm.com/healthz
       curl -vvv -o /dev/null -s https://login.ibm.com/
       ```
   2. Se algum desses comandos falhar, verifique se o sistema do cliente consegue se conectar a esses URLs de forma confiável e se os URLs não estão bloqueados por nenhum firewall corporativo ou do cliente. Observe que esses URLs exigem acesso à Internet pública.
   
   

5. Entre em contato com o suporte

Se tiver concluído todas as etapas acima e o problema não tiver sido resolvido, entre em contato com o suporte. Abrir um caso de suporte. Nos detalhes do caso, certifique-se de incluir todos os arquivos de registro, mensagens de erro ou saídas de comando relevantes.