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

Klassische Infrastruktur

Die Bewahrung der Quell-IP schlägt bei der Verwendung von verdorbenen Knoten in klassischen Clustern fehl und verhindert, dass der Datenverkehr Ihre Anwendung erreicht.

Sie haben in einem klassischen Cluster die Beibehaltung der Quellen-IP eines Service für die Lastausgleichsfunktion der Version 1.0 durch Ändern von externalTrafficPolicy in Local in der Konfigurationsdatei des Service aktiviert. An den Back-End-Service für die App wird jedoch kein Datenverkehr geleitet.

Wenn Sie das Beibehalten von Quellen-IPs für Lastausgleichsservices 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. In der Regel werden Pods für den Lastausgleichsservice auf den Workerknoten bereitgestellt, auf denen auch die App-Pods bereitgestellt werden. Es kann jedoch vorkommen, dass die Service-Pods und die App-Pods nicht auf demselben Workerknoten geplant sind. 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. Abhängig vom jeweils verwendeten Taint-Typ kann es vorkommen, dass die Beibehaltung der Quellen-IP nicht funktioniert:

Edge-Knoten-Taints: Sie haben das Label dedicated=edge zu zwei oder mehr Workerknoten in jedem öffentlichen VLAN in Ihrem Cluster hinzugefügt, um sicherzustellen, dass Load Balancer-Pods nur auf diesen Arbeitsknoten 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 Lastausgleichsservice 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 Pods für die Lastausgleichsfunktion 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:

Edge-Knoten-Taints: Wenn Sie sicherstellen möchten, dass die Pods für die Lastausgleichsfunktion und die App auf mit Taints versehenen Edge-Knoten bereitgestellt werden, fügen Sie Affinitätsregeln und Tolerierungen für den Edge-Knoten zur App-Bereitstellung hinzu. Pods für den Lastausgleich 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 eine der vorherigen Optionen ausführen, die keepalived Pods aber immer noch nicht eingeplant sind, können Sie weitere Informationen über die keepalived Pods erhalten:

Rufen Sie keepalived-Pods ab.
```
oc 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 suchen Sie den Abschnitt zu den Ereignissen (Events). Beheben Sie aufgelistete Fehler- oder Warnnachrichten.
```
oc describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```
Nachdem Sie das Problem behoben haben, überprüfen Sie, ob der Datenverkehr Ihre Anwendung erreicht, indem Sie die Endpunkte des Load Balancer-Dienstes überprüfen.
```
oc get svc -o wide
```