Clusters de VPC privados: Por que não consigo me conectar ao console OpenShift?

Solucione problemas de conexão com o console OpenShift em um cluster que tenha apenas um ponto de extremidade de serviço privado.

As informações contidas neste guia de solução de problemas referem-se a clusters de VPC com apenas um endpoint de serviço privado.

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

O diagrama a seguir mostra o fluxo de conexão de um cluster VPC com pontos de extremidade de serviço privados para conexão com o console da Web OpenShift. Este diagrama pressupõe que o cluster tenha as configurações padrão do site OAuth. Examine este diagrama e as descrições a seguir para entender melhor as etapas de solução de problemas que podem ser necessárias.

OpenShift
OpenShift fluxo de conexão do console da Web para um cluster de VPC com pontos de extremidade de serviço privados fluxo de conexão do console da Web para um cluster de VPC com pontos de extremidade de serviço privados.

  1. O navegador da Web se conecta por meio da VPN 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 do console OpenShift.
  2. (a) O navegador da Web se conecta por meio da VPN 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 à porta do servidor OAuth do mestre do cluster 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 por meio da VPN à 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 por meio da VPN à porta do servidor OAuth do cluster novamente. A conexão é redirecionada de volta para o balanceador de carga do console OpenShift.
  7. O navegador da Web se conecta por meio da VPN 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 sua 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

Verifique se a VPC e o cluster estão configurados corretamente. Uma configuração incorreta pode impedi-lo de acessar o console da Web OpenShift.

  1. Certifique-se de que o navegador da Web esteja sendo executado em um sistema cliente que esteja dentro da mesma VPC do cluster ou que tenha uma conexão VPN com essa VPC. O console OpenShift é exposto por um balanceador de carga de VPC privado que só pode ser acessado pela rede privada da VPC.

  2. Certifique-se de que o sistema cliente tenha acesso aos endpoints de serviço público do IAM, que podem ser acessados em iam.cloud.ibm.com e login.ibm.com.

  3. Para clusters que executam a versão 4.13:

    • Se o seu cluster usar a configuração padrão do 4.13 Oauth ou se você tiver definido o cluster para usar o Gateway VPE para Oauth, certifique-se de que o cliente esteja usando o DNS privado para a VPC e que esse tráfego de DNS seja roteado pela VPN para a VPC. O DNS privado é normalmente 161.26.0.7 e 161.26.0.8, a menos que você use um resolvedor de DNS personalizado. Isso é necessário para que o gateway VPE para apiserver e Oauth, que não existe em nenhum DNS público, possa ser encontrado no DNS privado da VPC.

  4. Para clusters que executam qualquer versão suportada diferente de 4.13:

    • Se estiver usando as configurações padrão do cluster do Oauth, certifique-se de que existam rotas na configuração da VPN para que todo o tráfego do 166.8.0.0/14 seja roteado pela mesma VPN ou por outra VPN que se conecte ao IBM Cloud. Isso é necessário para se conectar ao servidor de API do cluster e às portas do servidor OAuth.

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.private.<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. Na saída, localize o endereço URL com um dos seguintes formatos.
    - Se o gateway VPE não for usado para OAuth: `https://c<XXX>-e.private.<REGION>.containers.cloud.ibm.com:<ZZZZZ>`.
    - Se o gateway VPE for usado para OAuth: `https://<CLUSTERID>.vpe.private.<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 há uma rota por meio de sua VPN que se conecta ao servidor de API do cluster URL.
    4. Se o apiserver do cluster URL contiver sua ID de cluster (o que indica que o cluster usa o gateway VPE para a conexão com o apiserver do cluster), verifique se o grupo de segurança do gateway VPE para o mestre do cluster permite o tráfego da sua sub-rede de cliente VPN. Siga as etapas em [Como acessar o console OpenShift quando o acesso OAuth estiver definido como gateway VPE](/docs/openshift?topic=openshift-console-apiserver-oauthvpe).
    5. Verifique se algum grupo de segurança, ACLs ou rotas VPC personalizadas aplicadas à VPN impedem o tráfego entre a VPN e o servidor de API do cluster. Você pode testar isso permitindo temporariamente todo o tráfego de entrada e saída por meio do grupo de segurança e da ACL da VPN e, em seguida, verificando se isso resolve o problema. Se for o caso, faça as alterações necessárias em seus grupos de segurança, ACLs ou rotas personalizadas para permitir o tráfego.
    6. 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 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. Verifique se há uma rota por meio de sua VPN para esse subdomínio do balanceador de carga. Verifique se a rota inclui todos os IPs ou sub-redes que o balanceador de carga usa. A saída do comando `dig console-openshift-console.${CONSOLE_LOAD_BALANCER}` inclui os IPs e sub-redes atuais do balanceador de carga, mas observe que eles podem mudar à medida que o balanceador de carga aumenta ou diminui.
    3. 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 tiver modificado nenhum desses componentes e eles usarem os valores padrão, poderá pular esta etapa.
    4. Verifique se algum grupo de segurança, ACLs ou rotas VPC personalizadas aplicadas à VPN impedem o tráfego entre a VPN e o balanceador de carga. Você pode testar isso permitindo temporariamente todo o tráfego de entrada e saída por meio do grupo de segurança e da ACL da VPN e, em seguida, verificando se isso resolve o problema. Se for o caso, faça as alterações necessárias em seus grupos de segurança, ACLs ou rotas personalizadas para permitir o tráfego.

  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 há uma rota por meio de sua VPN para o mestre do cluster OAuth URL.
    4. Verifique se algum grupo de segurança, ACLs ou rotas VPC personalizadas aplicadas à VPN impedem o tráfego entre a VPN e o servidor OAuth do cluster. Você pode testar isso permitindo temporariamente todo o tráfego de entrada e saída por meio do grupo de segurança e da ACL da VPN e, em seguida, verificando se isso resolve o problema. Se for o caso, faça as alterações necessárias em seus grupos de segurança, ACLs ou rotas personalizadas para permitir o tráfego.
    5. 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 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.