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

Infrastructure classique

La préservation de l'IP source échoue lors de l'utilisation de nœuds altérés dans les clusters classiques, ce qui empêche le trafic d'atteindre votre application.

Dans un cluster classique, vous avez activé la conservation de l'adresse IP source pour un service d'équilibreur de charge version 1.0 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 d'adresse IP source pour les services d'équilibreur de charge, 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 principe, des pods de service d'équilibreur de charge sont déployés sur les mêmes noeuds worker que ceux où sont déployés les pods d'application. Il existe cependant des situations où les pods de service et les pods d'application ne sont pas forcément planifiés sur le même noeud worker. 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 fonctionner sur les nœuds de travail tainted. La conservation de l'adresse IP source peut ne pas fonctionner suivant le type de tache que vous avez utilisé :

Teintes de noeud de périphérie : vous avez ajouté le libellé dedicated=edge à au moins deux noeuds worker sur chaque VLAN public de votre cluster pour garantir que les pods d'équilibreur de charge 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 d'équilibreur de charge 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 l'équilibreur de charge 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 :

Teintes de noeud de périphérie : pour garantir que vos pods d'équilibreur de charge et d'application se déploient sur des noeuds de périphérie auxquels une teinte est appliquée, ajoutez des règles d'affinité de noeud de périphérie et des tolérances dans le déploiement de votre application. Par défaut, les pods d'équilibreur de charge 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 ajouter une teinte à ces noeuds de périphérie.

Si vous avez effectué l'une des options précédentes mais que les modules keepalived ne sont toujours pas planifiés, vous pouvez obtenir plus d'informations sur les modules keepalived:

Obtenez les pods keepalived.
```
oc 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 pod keepalived et recherchez la section Events. Traitez tous les messages d'erreur ou d'avertissement qui sont répertoriés.
```
oc describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```
Après avoir résolu le problème, vérifiez que le trafic atteint bien votre application en contrôlant les points d'extrémité du service d'équilibrage de charge.
```
oc get svc -o wide
```