Clústeres clásicos: ¿Por qué falla la conservación de IP de origen cuando se utilizan nodos marcados?

Infraestructura clásica

Usted preservación de IP de origen habilitada para un ALB de entrada servicio cambiando externalTrafficPolicy a Local en el archivo de configuración del servicio. Sin embargo, no hay tráfico que llegue al servicio de fondo para su app.

Cuando habilita la conservación de IP para los servicios ALB de Ingress, la dirección IP de origen de la solicitud de cliente se conserva. El servicio reenvía el tráfico a los pods de app del mismo nodo trabajador solo para asegurarse de que la dirección IP del paquete de solicitud no se cambia.

Normalmente, los pods de servicios ALB de Ingress se despliegan en los mismos nodos de trabajo que los pods de aplicaciones. Sin embargo, en algunas situaciones, es posible que los pods de servicio y los pods de aplicación no se programen en el mismo nodo trabajador. Si utiliza Kubernetes taints en los nodos trabajadores, se impedirá que los pods que no tengan una tolerancia de taint se ejecuten en los nodos trabajadores contaminados. La preservación de la IP de origen podría no funcionar, dependiendo del tipo de taint que haya utilizado:

Marcas de nodo de extremo: ha añadido la etiqueta dedicated=edge a dos o más nodos trabajadores en cada VLAN pública del clúster para asegurarse de que los pods de Ingress solo se desplieguen en estos nodos trabajadores. A continuación, también ha aplicado una marca a estos nodos de extremo para evitar que se ejecuten otras cargas de trabajo en los nodos de extremo. Sin embargo, no ha añadido una regla de afinidad de nodo extremo y tolerancia al despliegue de la app. Los pods de la app no se pueden planificar en los mismos nodos marcados que los pods de servicio, y el tráfico que llega al servicio de fondo para la app.
Marcas personalizadas: ha utilizado marcas personalizadas en diversos nodos de modo que solo los pods de la app con tolerancia a marcas se pueden desplegar en dichos nodos. Ha añadido reglas de afinidad y tolerancias a los despliegues de la app y al servicio Ingress para que sus pods solo se desplieguen en esos nodos. Sin embargo, los pods ibm-cloud-provider-ip keepalived que se crean automáticamente en el espacio de nombres ibm-system garantizan que los pods de ALB y los pods de app siempre se planifican en el mismo nodo trabajador. Estos pods keepalived no tienen tolerancia a las marcas personalizadas que ha utilizado. No se pueden planificar en los mismos nodos marcados en los que se ejecutan los pods de la app, y el tráfico que llega al servicio de fondo para la app.

Para solucionar el problema, elija una de las opciones siguientes:

Taints de nodos de borde: Para garantizar que el ALB y los pods de aplicaciones se implementan en nodos de borde contaminados, añada reglas de afinidad y tolerancias de nodos de borde a la implementación de la aplicación. Los pods de ALB de Ingress tienen estas reglas de afinidad y tolerancias de forma predeterminada.
Marcas personalizadas: elimine las marcas personalizadas para las que los pods keepalived no tienen tolerancia. En su lugar, puede añadir nodos trabajadores de etiqueta como nodos de extremo, y luego aplicar una marca en dichos nodos de extremo.

Si ha completado los pasos anteriores, pero los pods de keepalived siguen sin programarse, recopile más información sobre los pods de keepalived:

Obtenga los pods keepalived.
```
kubectl get pods -n ibm-system
```

En la salida, busque los pods ibm-cloud-provider-ip que tienen para Status el valor Pending. Ejemplo:

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>

Describa cada módulo de keepalived y revise la sección Eventos. Atienda los mensajes de error o advertencia que aparezcan en la lista.
```
kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```