Clusters clássicos: por que a preservação do IP de origem falha ao usar nós contaminados?

Infraestrutura clássica

Para acessar o serviço preservação de IP de origem habilitada para um ALB de entrada, altere externalTrafficPolicy para Local no arquivo de configuração do serviço. No entanto, nenhum tráfego atinge o serviço de back-end para seu app.

Ao ativar a preservação de IP de origem para serviços ALB do Ingress, o endereço IP de origem da solicitação do cliente é preservado. O serviço encaminha o tráfego para os pods de app no mesmo nó do trabalhador somente para assegurar que o endereço IP do pacote de solicitações não seja mudado.

Normalmente, os pods de serviço do Ingress ALB são implantados nos mesmos nós de trabalho que os pods de aplicativos. No entanto, em algumas situações, os pods de serviço e os pods de aplicativo podem não ser agendados no mesmo nó de trabalho. Se você usar Kubernetes taints nos nós de trabalho, todos os pods que não tiverem uma tolerância de taint serão impedidos de serem executados nos nós de trabalho contaminados. A preservação do IP de origem pode não funcionar, dependendo do tipo de contaminação que você usou:

Contaminações de nó da borda: você incluiu o rótulo dedicated=edge em dois ou mais nós do trabalhador em cada VLAN pública em seu cluster a fim de assegurar que os pods do Ingress sejam implementados somente nesses nós do trabalhador. Em seguida, você também contaminou esses nós de borda para evitar que quaisquer outras cargas de trabalho sejam executadas em nós de borda. No entanto, você não incluiu uma regra de afinidade de nó de borda e tolerância em sua implementação do app. Seus pods de app não podem ser planejados nos mesmos nós contaminados que os pods de serviço, e nenhum tráfego atinge o serviço de back-end para o seu app.
Contaminações customizadas: você usou contaminações customizadas em vários nós para que somente os pods de app com essa tolerância de contaminação possam ser implementados nesses nós. Você incluiu regras de afinidade e tolerâncias nas implementações de seu app e serviço do Ingress para que seus pods sejam implementados somente naqueles nós. No entanto, os pods ibm-cloud-provider-ip keepalived que são criados automaticamente no namespace ibm-system garantem que os pods do ALB e os pods do app estejam sempre planejados no mesmo nó do trabalhador. Esses pods keepalived não têm as tolerâncias para as contaminações customizadas que você usou. Eles não podem ser planejados nos mesmos nós contaminados nos quais seus pods de app estão em execução e nenhum tráfego atinge o serviço de back-end para o seu app.

Resolva o problema escolhendo uma das opções a seguir:

Tintas de nó de borda: Para garantir que o ALB e os pods de aplicativos sejam implantados em nós de borda contaminados, adicione regras de afinidade e tolerâncias de nó de borda à implantação do aplicativo. Os pods do ALB do Ingress têm essas regras de afinidade e tolerâncias por padrão.
Contaminações customizadas: remova as contaminações customizadas para as quais os pods keepalived não têm tolerâncias. Em vez disso, é possível rotular nós do trabalhador como nós de borda e, em seguida, contaminar esses nós de borda.

Se você tiver concluído as etapas anteriores, mas os pods keepalived ainda não estiverem agendados, reúna mais informações sobre os pods keepalived:

Obtenha os pods keepalived .
```
kubectl get pods -n ibm-system
```

Na saída, procure os pods ibm-cloud-provider-ip que têm um Status de Pending. Exemplo:

ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t     0/1       Pending   0          2m        <none>          <none>
ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-8ptvg     0/1       Pending   0          2m        <none>          <none>

Descreva cada pod do keepalived e analise a seção Eventos. Resolva todas as mensagens de erro ou aviso listadas.
```
kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```