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

Infraestrutura clássica

A preservação do IP de origem falha ao usar nós contaminados em clusters clássicos, impedindo que o tráfego chegue ao seu aplicativo.

Em um cluster clássico, você ativou a preservação de IP de origem para um serviço de balanceador de carga versão 1.0, mudando 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 do balanceador de carga, 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. Geralmente, os pods de serviço do balanceador de carga são implementados para os mesmos nós do trabalhador nos quais os pods do app são implementados. No entanto, existem algumas situações em que os pods de serviço e os pods de app podem não ser planejados para o mesmo nó do trabalhador. Se você usar Contaminações do Kubernetes em nós do trabalhador, os pods que não tiverem uma tolerância de contaminação serão impedidos de ser executados nos nós do trabalhador contaminados. A preservação de IP de origem pode não estar funcionando com base no 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 de cada VLAN pública no cluster para garantir que os pods de balanceamento de carga 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ê adicionou regras de afinidade e tolerações às implementações de seu app e serviço de balanceador de carga para que seus pods implementem para apenas esses nós. No entanto, os pods ibm-cloud-provider-ip keepalived que são criados automaticamente no namespace ibm-system asseguram que o balanceador de carga 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:

Contaminações de nó de borda: para assegurar que seus pods do balanceador de carga e do app sejam implementados em nós de borda contaminados, inclua regras de afinidade e tolerâncias de nó de borda em sua implementação do app. Os pods do balanceador de carga 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ê concluir uma das opções anteriores, mas os pods keepalived ainda não estiverem agendados, poderá obter mais informações sobre os pods keepalived:

Obtenha os pods keepalived .
```
oc 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 keepalived e procure a seção Eventos. Trate quaisquer mensagens de erro ou de aviso que estejam listadas.
```
oc describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```
Depois de resolver o problema, verifique se o tráfego está chegando ao seu aplicativo verificando os pontos de extremidade do serviço do balanceador de carga.
```
oc get svc -o wide
```