Por que o subdomínio de containers.appdomain.cloud público está ausente no meu cluster?

Virtual Private Cloud Infra-estrutura Classic

Ao expor um app por meio de um subdomínio do controlador de ingresso, você consegue um subdomínio local em vez de uma rota pública, no formato: <service_name>-<project_name>.router.default.svc.cluster.local.

Ao tentar abrir o console da web do Red Hat OpenShift ou outra rota de app em seu navegador, é possível ver um erro semelhante ao seguinte.

Application is not available
The application is currently not serving requests on this endpoint.

Depois que o cluster é criado e entra em um estado normal, os componentes de subdomínio do controlador de ingresso e de balanceamento de carga ainda levam algum tempo para implementar.

Se você expor seu app antes dos fornecimento total dos componentes de rede, ou se os componentes tiverem um erro, seus apps só poderão ser expostos internamente com o domínio svc.cluster.local do controlador de ingresso padrão.

Quando os componentes estão totalmente provisionados, um subdomínio do controlador de ingresso público está disponível para seus apps, no formato <cluster-name>-<accountID-hashed>-<ssll>.<region>.containers.appdomain.cloud.

1. Depois de criar um cluster, espere algum tempo antes de expor seus apps, mesmo depois que o cluster entrar em um estado normal.

2. 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>
   

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

   • Clusters de VPC com pontos de extremidade de serviço de nuvem pública e privada ativados: Certifique-se de que um gateway público esteja ativado em cada sub-rede à 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. Observe que se apenas o terminal em serviço privado estiver ativado para seu cluster, nenhum gateway público será necessário porque o terminal em serviço de nuvem privada é usado por padrão para acessar componentes do OpenShift como o console da web do OpenShift ou o OperatorHub.
   • Clusters clássicos:
     • Na saída da Etapa 2, verifique se seu cluster tem uma URL de terminal em serviço público. Se o seu cluster não tiver um endpoint de serviço de nuvem pública, ative-o.
     • 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.

       ibmcloud oc workers -c <cluster_name_or_ID>
       

4. Na saída da Etapa 2, verifique se o Subdomínio do Ingress está disponível. Os componentes de ingresso em seu cluster devem ser fornecidos antes que os componentes do controlador de ingresso possam ser criados. Se o Subdomínio do Ingress e o Segredo do Ingress não estiverem disponíveis, consulte Por que nenhum subdomínio do Ingress existe após a criação do cluster?.

5. Verifique se o Nome do host do subdomínio do controlador de ingresso está no formato: <cluster-name>-<accountID-hashed>-<ssll>.<region>.containers.appdomain.cloud.

   ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
   

   • Se o subdomínio do controlador de ingresso não for atualizado após duas horas da criação do cluster, revise novamente o Status principal do cluster e siga quaisquer etapas de resolução de problemas para resolver o problema.

Se as etapas de resolução de problemas não resolverem o problema, consulte Obtendo ajuda.