Clusters classiques : Pourquoi la conservation de l'adresse IP source échoue-t-elle lors de l'utilisation de noeuds tachés ?

Infrastructure classique

Vous pouvez utiliser le service préservation de l'IP source activée pour un ALB entrant en remplaçant externalTrafficPolicy par Local dans le fichier de configuration du service. Cependant, aucun trafic n'atteint le service de back end de votre application.

Lorsque vous activez la conservation de l'adresse IP source pour les services d'équilibreur de charge d'application Ingress, l'adresse IP source de la demande client est conservée. Le service achemine le trafic vers les pods d'application sur le même noeud worker uniquement pour garantir que l'adresse du paquet de demandes n'est pas modifiée.

En règle générale, les modules de service ALB d'Ingress sont déployés sur les mêmes nœuds de travail que les modules d'application. Cependant, dans certaines situations, les pods de service et les pods d'application peuvent ne pas être planifiés sur le même nœud de travail. Si vous utilisez Kubernetes taints sur les nœuds de travail, tous les pods qui n'ont pas de tolérance de taint sont empêchés de s'exécuter sur les nœuds de travail tainted. La préservation de l'IP source peut ne pas fonctionner, en fonction du type d'altération utilisé :

Teintes de noeud de périphérie : vous avez ajouté le libellé dedicated=edge à au moins deux noeuds worker sur chaque VLAN public dans votre cluster pour garantir que les pods Ingress se déploient uniquement sur ces noeuds worker. Ensuite, vous avez également appliqué une tache à ces noeuds de périphérie pour empêcher toute autre charge de travail de s'exécuter sur les noeuds de périphérie. Mais vous n'avez pas ajouté de règles d'affinité et de tolérance dans le déploiement de votre application. Vos pods d'application ne peuvent pas être planifiés sur les mêmes noeuds auxquels une tache est appliquée que les pods de service et aucun trafic n'atteint le service de back end de votre application.
Teintes personnalisées : vous avez utilisé des taches personnalisées sur plusieurs noeuds de sorte que seuls les pods d'application avec cette tolérance de tache puissent se déployer sur ces noeuds. Vous avez ajouté des règles d'affinité et de tolérance aux déploiements de votre application et du service Ingress de sorte que leurs pods se déploient uniquement sur ces noeuds. Cependant, les pods ibm-cloud-provider-ip keepalived automatiquement créés dans l'espace de noms ibm-system garantissent que les pods d'équilibreur de charge d'application et les pods d'application sont toujours planifiés sur le même noeud worker. Ces pods keepalived ne disposent pas des tolérances pour les taches personnalisées que vous avez utilisées. Ils ne peuvent pas être déployés sur les mêmes noeuds auxquels une tache est appliquée sur lesquels s'exécutent vos pods d'application, et aucun trafic n'atteint le service de back end de votre application.

Résolvez le problème en choisissant l'une des options suivantes :

Affinités des nœuds de périphérie: Pour garantir que votre ALB et vos pods d'application sont déployés sur des nœuds de périphérie entachés, ajoutez des règles d'affinité et des tolérances de nœuds de périphérie à votre déploiement d'application. Par défaut, les pods d'équilibreur de charge d'application Ingress disposent de ces règles d'affinité et de ces tolérances.
Teintes personnalisées : retirez les taches personnalisées pour lesquelles les pods keepalived ne disposent pas de tolérances. Vous pouvez à la place libeller les noeuds worker en tant que noeuds de périphérie, puis appliquer une tache à ces noeuds de périphérie.

Si vous avez effectué les étapes précédentes, mais que les pods keepalived ne sont toujours pas planifiés, recueillez davantage d'informations sur les pods keepalived:

Obtenez les pods keepalived.
```
kubectl get pods -n ibm-system
```

Dans la sortie obtenue, recherchez les pods ibm-cloud-provider-ip dont la valeur de Status est Pending. Exemple :

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>

Décrivez chaque module keepalived et passez en revue la section " Événements". Répondre à tous les messages d'erreur ou d'avertissement répertoriés.
```
kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```