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

Infraestructura clásica

La preservación de la IP de origen falla cuando se utilizan nodos contaminados en clústeres clásicos, lo que impide que el tráfico llegue a su aplicación.

En un clúster clásico, ha habilitado la conservación de IP de origen para un servicio equilibrador de carga de la versión 1.0 cambiando externalTrafficPolicy por 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 equilibrador de carga, 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. Generalmente, los pods del servicio equilibrador de carga se despliegan en los mismos nodos trabajadores donde se despliegan los pods de app. Sin embargo, existen algunas situaciones donde los pods de servicio y los pods de app podrían no planificarse en los mismos nodos trabajadores. Si utiliza Kubernetes taints en los nodos trabajadores, cualquier pod que no tenga una tolerancia de taint no podrá ejecutarse en los nodos trabajadores contaminados. Es posible que la conservación de IP de origen no esté funcionando dependiendo del tipo de marca que utilice:

Marcas de nodo perimetral: ha añadido la etiqueta dedicated=edge a dos o más nodos trabajadores en cada VLAN pública del clúster para garantizar que los pods equilibradores de cargas solo se desplieguen en esos 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 equilibrador de carga 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 el equilibrador de carga 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:

Marcas de nodo de extremo: para asegurarse de que el equilibrador de carga y los pods de la app se despliegan en nodos de extremo marcados, añada reglas de afinidad de nodo de extremo y tolerancias al despliegue de la app. Los pods de equilibrador de carga 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 completa una de las opciones anteriores pero los pods de keepalived siguen sin programarse, puede obtener más información sobre los pods de keepalived:

Obtenga los pods keepalived.
```
oc 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 pod keepalived y busque la sección Events. Solucione cualquier mensaje de error o de aviso que aparezca.
```
oc describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```
Una vez resuelto el problema, compruebe que el tráfico llega a su aplicación comprobando los puntos finales de servicio del equilibrador de carga.
```
oc get svc -o wide
```