Klassische Cluster: Warum schlägt die Beibehaltung der Quellen-IP fehl, wenn mit Taints versehene Knoten verwendet werden?

Klassische Infrastruktur

Sie haben die Quell-IP-Erhaltung für einen Ingress-ALB-Dienst aktiviert, indem Sie in der Dienstkonfigurationsdatei externalTrafficPolicy in Local geändert haben. An den Back-End-Service für die App wird jedoch kein Datenverkehr geleitet.

Wenn Sie die Beibehaltung der Quellen-IP für Ingress-ALB-Services aktivieren, wird die Quellen-IP-Adresse der Clientanforderung beibehalten. Der Datenverkehr wird vom Service nur an App-Pods auf demselben Workerknoten weitergeleitet, um sicherzustellen, dass die IP-Adresse des Anforderungspakets nicht geändert wird.

Normalerweise werden Ingress ALB-Service-Pods auf denselben Worker Nodes wie die App-Pods bereitgestellt. In manchen Situationen kann es jedoch vorkommen, dass die Service-Pods und die App-Pods nicht auf demselben Arbeitsknoten geplant werden. Wenn Sie Kubernetes taints auf Worker Nodes verwenden, werden alle Pods, die keine taint-Toleranz haben, daran gehindert, auf den tainted Worker Nodes zu laufen. Die Erhaltung der Quell-IP funktioniert möglicherweise nicht, je nachdem, welche Art von Taint Sie verwendet haben:

Edge-Knoten-Taints: Sie haben die Bezeichnung dedicated=edge zu mehreren Workerknoten in jedem öffentlichen VLAN im Cluster hinzugefügt, um sicherzustellen, dass die Ingress-Pods nur auf diesen Workerknoten bereitgestellt werden. Danach haben Sie auch auf diese Edge-Knoten ein Taint angewendet, um zu vermeiden, dass andere Workloads auf Edge-Knoten ausgeführt werden. Sie haben jedoch keine Affinitätsregel und Tolerierung für den Edge-Knoten zur App-Bereitstellung hinzugefügt. Die App-Pods können nicht auf denselben mit Taints versehenen Knoten geplant werden, auf denen die Service-Pods ausgeführt werden, und der Datenverkehr erreicht nicht den Back-End-Service für die App.
Angepasste Taints: Sie haben angepasste Taints auf mehreren Knoten verwendet, sodass nur App-Pods mit dieser Taint-Tolerierung auf diesen Knoten bereitgestellt werden können. Da Sie Affinitätsregeln und Tolerierungen zu den Bereitstellungen der App und zum Ingress-Service hinzugefügt haben, können die zugehörigen Pods nur auf diesen Knoten bereitgestellt werden. Durch ibm-cloud-provider-ip-keepalived-Pods, die automatisch im Namensbereich ibm-system erstellt werden, wird jedoch sichergestellt, dass die ALB-Pods und die App-Pods immer auf demselben Workerknoten geplant werden. Diese keepalived-Pods weisen nicht die Tolerierungen für die angepassten Taints auf, die Sie verwendet haben. Sie können nicht auf denselben mit Taints versehenen Knoten geplant werden, auf denen die App-Pods ausgeführt werden, und der Datenverkehr erreicht nicht den Back-End-Service für die App.

Beheben Sie das Problem unter Verwendung einer der beiden Optionen:

Verunreinigungen von Edge-Knoten: Um sicherzustellen, dass Ihre ALB- und App-Pods auf "tainted" Edge Nodes bereitgestellt werden, fügen Sie Ihrer App-Bereitstellung Edge-Node-Affinitätsregeln und -Toleranzen hinzu. Ingress-ALB-Pods weisen diese Affinitätsregeln und Tolerierungen standardmäßig auf.
Angepasste Taints: Entfernen Sie angepasste Taints, für die die keepalived-Pods nicht über Tolerierungen verfügen. Stattdessen können Sie Workerknoten als Edge-Knoten bezeichnen und anschließend Taints auf diese Edge-Knoten anwenden.

Wenn Sie die vorherigen Schritte durchgeführt haben, die keepalived Pods aber immer noch nicht eingeplant sind, sammeln Sie weitere Informationen über die keepalived Pods:

Rufen Sie keepalived-Pods ab.
```
kubectl get pods -n ibm-system
```

Suchen Sie in der Ausgabe nach ibm-cloud-provider-ip-Pods, die den Status Pending aufweisen. Beispiel:

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>

Beschreiben Sie jeden keepalived pod und lesen Sie den Abschnitt Ereignisse. Beheben Sie alle aufgelisteten Fehler- oder Warnmeldungen.
```
kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```