Por que os pods do ALB não são implementados em nós do trabalhador?

Nuvem privada virtual Infraestrutura clássica

Quando você executa kubectl get pods -n kube-system | grep alb, nenhum dos pods de ALB ou apenas alguns dos pods de ALB são implementados com sucesso nos seus nós do trabalhador.

Ao descrever um pod ALB executando kubectl describe pod -n kube-system <pod_name>, você vê uma mensagem semelhante à seguinte na seção Eventos da saída.

0/3 nodes are available: 1 node(s) didn’t match pod affinity/anti-affinity, 2 node(s) didn’t match node selector.

O Ingress requer pelo menos dois nós do trabalhador por zona para assegurar a alta disponibilidade e aplicar atualizações periódicas.

Por padrão, os pods de ALB têm duas réplicas. No entanto, os pods do ALB possuem regras de antiafinidade para assegurar que apenas um pod seja planejado para cada nó do trabalhador para alta disponibilidade. Quando existe apenas um nó do trabalhador por zona em um cluster clássico ou de VPC, ou quando existe apenas um nó do trabalhador em uma VLAN à qual o cluster clássico está conectado, os pods ALB não podem implementar corretamente.

Siga estas etapas para resolver o problema:

1. Verifique o número de nós do trabalhador por zona em seu cluster.

   ibmcloud ks worker ls -c <cluster_name_or_ID>
   

2. Se houver apenas um nó de trabalho em uma zona, aumente o número de nós de trabalho nessa zona.

   • Clusters clássicos e VPC:
     • Se você não usar nós de borda: Certifique-se de que haja pelo menos dois nós de trabalho em cada zona redimensionando um pool de trabalho existente, criando um novo pool de trabalho em um cluster VPC ou criando um novo pool de trabalho em um cluster clássico.
     • Se você usar nós de borda: Certifique-se de que pelo menos dois edge workers nodes estejam ativados em cada zona.
   • Somente clusters clássicos: se houver mais de um nó de trabalho em cada zona do cluster clássico, os nós de trabalho poderão estar conectados a VLANs diferentes em uma zona, de modo que apenas um nó de trabalho exista em uma VLAN privada. Continue com a próxima etapa.

3. Para clusters clássicos com vários nós de trabalho por zona, verifique a VLAN privada à qual cada nó de trabalho está conectado.

   ibmcloud ks worker get -w <worker_ID> -c <cluster_name_or_ID>
   

4. Se apenas um nó do trabalhador existir em uma VLAN privada, e os outros nós do trabalhador na zona estiverem conectados a uma VLAN privada diferente, crie um novo conjunto de trabalhadores com um tamanho de pelo menos um nó do trabalhador. Quando você adicionar uma zona ao pool de trabalho, especifique a mesma zona e VLAN privada que o nó de trabalho que você identificou anteriormente.

5. Repita essas etapas para cada zona em seu cluster para assegurar que mais de um nó do trabalhador exista em uma VLAN privada.

Após os novos nós do trabalhador serem implementados, os pods de ALB serão automaticamente planejados para serem implementados naqueles nós do trabalhador.