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,dal12edal13, você poderá ver um serviçorouter-defaultparadal10e um serviçorouter-dal12paradal12, mas nenhum serviçorouter-dal13paradal13. Observe que o serviço do controlador Ingress na primeira zona em que você possui nós de trabalho sempre se chamarouter-default, e os serviços do controlador Ingress nas zonas que você adicionar posteriormente ao seu cluster têm nomes comorouter-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.
-
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 subnetspara 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. -
Use o comando
ibmcloud ks cluster subnet addpara disponibilizar a sub-rede existente para o seu cluster. -
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-resourcesNesta 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 -
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 CLUSTERpara 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-ingresspara verificar se o controlador de ingresso ausente é implementado com um endereço IP externo.
- Não há subdomínios de ingresso: execute
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.
-
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 -
Crie o serviço de controlador de ingresso em seu cluster.
oc create -f router-<zone>.yaml -
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-ingressSaí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 -
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 -
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