Clusters clássicos: por que o controlador de ingresso não implementa em uma zona?

Provedor e versão de infraestrutura:

  • Clássica
  • Red Hat OpenShift versão 4

Ao executar oc get svc -n openshift-ingress, uma ou mais zonas não têm controlador de ingresso público.

  • Nenhum serviço router-default é implementado ou o serviço pode não ter um endereço IP externo designado. Por exemplo, em um cluster de zona única, é possível que você veja o seguinte:
    NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
    router-default                               LoadBalancer   172.21.47.119   <none>         80:32637/TCP,443:31719/TCP   26m
    router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26m
    
  • Se você tiver um cluster multizona, uma zona não terá serviço de controlador de ingresso. Por exemplo, em um cluster multizona que possui nós de trabalho em dal10, dal12 e dal13, você poderá ver um serviço router-default para dal10 e um serviço router-dal12 para dal12, mas nenhum serviço router-dal13 para dal13. Observe que o serviço do controlador Ingress na primeira zona em que você possui nós de trabalho sempre se chama router-default, e os serviços do controlador Ingress nas zonas que você adicionar posteriormente ao seu cluster têm nomes como router-dal12. Também é possível ver que uma zona não tem serviço de controlador de ingresso, mas outra zona tem dois ou mais serviços de controlador de ingresso.
    NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
    router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26m
    router-dal12                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26m
    router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26m
    

Os serviços do roteador podem não ser implementados por um dos motivos a seguir:

  • Se nenhum serviço de controlador de ingresso for implementado ou se nenhum endereço IP externo for designado aos serviços de controlador de ingresso: em clusters padrão, a primeira vez que você cria um cluster em uma zona, uma VLAN pública e uma VLAN privada nessa zona são automaticamente provisionadas para você em sua conta de infraestrutura IBM Cloud. Nessa zona, é solicitada uma sub-rede pública portátil na VLAN pública que você especificar e uma sub-rede privada portátil na VLAN privada que você especificar. Para o Red Hat OpenShift on IBM Cloud, as VLANs têm um limite de 40 sub-redes. Se a VLAN do cluster em uma zona já tiver atingido esse limite, o subdomínio de entrada não será provisionado e o controlador de entrada público padrão também não será provisionado. Para verificar quantas sub-redes uma VLAN possui, no console de infraestrutura do IBM Cloud, selecione Rede > Gerenciamento de IP > VLANs. Clique no Número da VLAN da VLAN usada para criar seu cluster. Revise a seção Subnets para ver se 40 ou mais sub-redes existem.

  • Se uma zona não tem serviço de controlador de ingresso: quando seus serviços de controlador de ingresso são criados, eles são automaticamente dispersos pelas zonas em seu cluster. Se a rede para a primeira zona com a qual seu cluster foi criado não estiver pronta quando os serviços do controlador de ingresso forem criados, o serviço de controlador de ingresso para essa zona poderá ser colocado em uma zona diferente. Dois serviços de controlador de ingresso podem ser criados em uma zona, e nenhum serviço de controlador de ingresso é criado na zona inicial.

Resolva problemas de VLAN para os serviços do controlador de ingresso que não têm endereço IP, ou problemas de serviço do controlador de ingresso multizona para zonas sem serviços de controlador de ingresso.

Resolvendo problemas da VLAN

Para resolver problemas de VLAN para os serviços do controlador de ingresso que não possuem endereço IP:

Opção 1: Se você precisar de uma nova VLAN, solicite-a entrando em contato com o suporte da IBM Cloud. Em seguida, crie um cluster que usa essa nova VLAN.

Opção 2: Se você tiver outra VLAN disponível, poderá configurar o spanning de VLAN no seu cluster existente. Para verificar se o spanning de VLAN já está habilitado, use o comando ibmcloud ks vlan spanning get --region REGION . Em seguida, é possível incluir novos nós do trabalhador no cluster que usam a outra VLAN com sub-redes disponíveis. Crie pelo menos dois nós de trabalho por zona. Agora, os endereços IP estão disponíveis para que os controladores de ingresso possam ser implementados automaticamente.

Opção 3: Se você não estiver utilizando todas as sub-redes da VLAN, é possível reutilizar as sub-redes da VLAN adicionando-as ao seu cluster.

  1. Verifique se a sub-rede que você deseja usar está disponível. A conta de infraestrutura que você usa pode ser compartilhada em diversas contas da IBM Cloud. Nesse caso, mesmo que você execute o comando ibmcloud oc subnets para ver sub-redes com Clusters de ligação, é possível ver informações somente de seus clusters. Verifique com o proprietário da conta de infraestrutura para certificar-se de que as sub-redes estão disponíveis e não em uso por nenhuma outra conta ou equipe.

  2. Use o comando ibmcloud ks cluster subnet add para disponibilizar a sub-rede existente para o seu cluster.

  3. Verifique se a sub-rede foi criada com sucesso e se foi incluída em seu cluster. O CIDR da sub-rede é listado na seção Subnet VLANs.

    ibmcloud ks cluster get --cluster CLUSTER_NAME --show-resources
    

    Nesta saída de exemplo, uma segunda sub-rede foi incluída na VLAN pública 2234945:

    Subnet VLANs
    VLAN ID   Subnet CIDR          Public   User-managed
    2234947   10.xxx.xx.xxx/29     false    false
    2234945   169.xx.xxx.xxx/29    true     false
    2234945   169.xx.xxx.xxx/29    true     false
    
  4. Verifique se os endereços IP móveis da sub-rede que você incluiu são usados para o controlador de ingresso em seu cluster. Podem ser necessários vários minutos até que os serviços usem os endereços IP móveis da nova sub-rede.

    • Não há subdomínios de ingresso: execute ibmcloud ks cluster get --cluster CLUSTER para verificar se o Subdomínio de ingresso está preenchido.
    • Um controlador de ingresso não é implementado em uma zona: execute oc get svc -n openshift-ingress para verificar se o controlador de ingresso ausente é implementado com um endereço IP externo.

Resolvendo problemas de implementação do serviço de controlador de ingresso multizona

Crie um serviço de controlador Ingress na zona em que um serviço de controlador Ingress não foi implantado. Se um serviço de controlador de ingresso duplicado foi inicialmente criado em uma zona diferente, não exclua esse serviço de controlador de ingresso.

  1. Crie um arquivo YAML para um serviço de controlador de Ingress na zona em que esse serviço não foi implantado. Nomeie o serviço de controlador de ingresso router-<zone>.

     apiVersion: v1
     kind: Service
     metadata:
       annotations:
         service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
       finalizers:
       - service.kubernetes.io/load-balancer-cleanup
       labels:
         app: router
         ingresscontroller.operator.openshift.io/owning-ingresscontroller: default
         router: router-default
       name: router-<zone>
       namespace: openshift-ingress
     spec:
       externalTrafficPolicy: Cluster
       selector:
         ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
       sessionAffinity: None
       type: LoadBalancer
    
  2. Crie o serviço de controlador de ingresso em seu cluster.

    oc create -f router-<zone>.yaml
    
  3. Verifique se o serviço de controlador de ingresso é criado na zona correta. Na saída, obtem o endereço IP EXTERNO .

    oc get svc router-<zone> -n openshift-ingress
    

    Saída de exemplo

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
    router-dal12                 LoadBalancer   172.21.57.132    169.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
    
  4. Obtenha o subdomínio para o seu controlador de ingresso padrão. Na saída, procure o subdomínio formatado como <cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.

    ibmcloud ks nlb-dns ls -c CLUSTER_NAME_OR_ID
    
  5. Registre o endereço IP do serviço do controlador de ingresso com o subdomínio do seu controlador de ingresso.

    ibmcloud ks nlb-dns add -c CLUSTER_NAME_OR_ID --ip ROUTER_SVC_IP --nlb-host ROUTER_SUBDOMAIN