Warum sind die ibm-cloud-provider-ip-Pods für das Istio-Ingress-Gateway im Zustand pending (anstehend) blockiert?

Virtuelle Private Cloud Klassische Infrastruktur

Nur Mehrzonencluster

Wenn Sie kubectl get pod -n ibm-system ausführen, ist der ibm-cloud-provider-ip-Pod, der die externe IP-Adresse für Ihr Istio-Ingress-Gateway bereitstellt, im Status pending (anstehend) blockiert.

Beim Ausführen von kubectl describe pod <pod_name> -n ibm-system für den Pod ibm-cloud-provider-ip wird außerdem ein Fehler aufgrund eines Planungskonflikts im Abschnitt für die Ereignisse des Pods in der Ausgabe angezeigt.

Um den ibm-cloud-provider-ip-Pod für Ihr Gateway zu ermitteln, können Sie kubectl get service -n istio-system ausführen, um den Lastausgleichsservice Ihres Gateways zu finden, die zugehörige externe IP-Adresse (EXTERNAL-IP) zu notieren und nach der IP-Adresse im Namen des ibm-cloud-provider-ip-Pods zu suchen.

Wenn ein Lastausgleichsservice des Typs istio-ingressgateway erstellt wird, wird gleichzeitig ein ibm-cloud-provider-ip-Pod generiert, der eine externe IP-Adresse für die Lastausgleichsfunktion bereitstellt.

Diese ibm-cloud-provider-ip-Pods verfügen über eine Knotenaffinitätsregel, so dass sie in derselben Zone wie das Teilnetz erstellt werden, aus dem die IP-Adresse abgeleitet wird. Wenn die Einstellung ExternalTrafficPolicy für den Lastausgleichsservice istio-ingressgateway auf Local gesetzt ist, verfügt der ibm-cloud-provider-ip-Pod zudem über eine Pod-Affinitätsregel, die in derselben Zone bereitgestellt werden soll wie der Pod für die Lastausgleichsfunktion des Gateways. Wenn die IP-Adresse und die Gateway-Lastausgleichsfunktion in verschiedenen Zonen in Ihrem Cluster enthalten sind, kann der Pod ibm-cloud-provider-ip nicht ordnungsgemäß bereitgestellt werden.

Gehen Sie wie folgt vor, um sicherzustellen, dass die Pods ibm-cloud-provider-ip und istio-ingressgateway nicht in derselben Zone enthalten sind:

  1. Geben Sie den Knoten (NODE) an, auf dem Ihr istio-ingressgateway-Pod bereitgestellt wird.

    kubectl get pod -n istio-system -o wide

  2. Rufen Sie die externe IP-Adresse (EXTERNAL-IP) für den Lastausgleichsservice des Gateways ab.

    kubectl get service -n istio-system

  3. Geben Sie den Knoten (NODE) an, auf dem der ibm-cloud-provider-ip-Pod für die Lastausgleichsfunktion bereitgestellt wird. Ersetzen Sie <IP-with-hyphens> durch die IP-Adresse, die Sie im vorherigen Schritt gefunden haben. Verwenden Sie in der IP-Adresse Bindestriche (-) anstelle von Punkten (.). Beispiel: 169.12.345.67 wird zu 169-12-345-67.

    kubectl get pod -n ibm-system -o wide -l ibm-cloud-provider-ip=<IP-with-hyphens>

  4. Listen Sie die Zonen auf, in denen sich die Workerknoten befinden. Vergleichen Sie die in Schritt 1 und 3 ermittelten Workerknopten, um festzustellen, ob die Pods auf Workerknoten in verschiedenen Zonen bereitgestellt sind.

    kubectl get node --no-headers -L ibm-cloud.kubernetes.io/zone

    Beispielausgabe

    10.176.48.106   Ready   <none>   529d    v1.36+IKS   dal10
10.176.48.107   Ready   <none>   196d    v1.36+IKS   dal10
10.184.58.23    Ready   <none>   2y38d   v1.36+IKS   dal12
10.184.58.42    Ready   <none>   529d    v1.36+IKS   dal12

Um dieses Problem zu beheben, können Sie entweder den istio-ingressgateway-Pod in die Zone verschieben, in der sich der ibm-cloud-provider-ip-Pod befindet, oder umgekehrt.

  • Verschieben des istio-ingressgateway-Pods: Nach dem Verschieben behält die Lastausgleichsfunktion des Gateways ihre externe IP-Adresse bei. In Version 1.9 und früheren Versionen des Add-ons können die von Ihnen vorgenommenen Änderungen jedoch überschrieben werden, wenn die Zonenbeschriftungen für Gateways während der Istio-Patchaktualisierungen automatisch aufgefüllt werden.
  • Verschieben des ibm-cloud-provider-ip-Pods: Das Gateway behält nach dem Verschieben nicht dieselbe externe IP-Adresse und erhält eine neue IP-Adresse. Bei Add-on-Aktualisierungen werden jedoch keine Änderungen überschrieben.

istio-ingressgateway-Pod verschieben

Verschieben Sie den istio-ingressgateway-Pod in die Zone, in der sich auch der ibm-cloud-provider-ip-Pod befindet.

  1. Bearbeiten Sie die Ressource managed-istio-custom für die Konfigurationszuordnung (configmap).
    kubectl edit cm managed-istio-custom -n ibm-operators
  2. Ändern Sie für das Gateway, das Sie verschieben möchten, die Einstellung istio-ingressgateway-zone-1|2|3 in die Zone, in der sich der ibm-cloud-provider-ip-Pod befindet.
  3. Speichern und schließen Sie die Konfigurationsdatei. Der istio-ingressgateway-Pod wird auf einen Workerknoten in derselben Zone wie der ibm-cloud-provider-ip-Pd verschoben und der ibm-cloud-provider-ip-Pod wird ordnungsgemäß bereitgestellt.
  4. Um zu überprüfen, ob die Pods jetzt in derselben Zone vorhanden sind, führen Sie die Schritte im Abschnitt Mögliche Ursache aus.

ibm-cloud-provider-ip-Pod verschieben

Verschieben Sie den ibm-cloud-provider-ip-Pod in die Zone, in der sich auch der istio-ingressgateway-Pod befindet.

  1. Bearbeiten Sie die Ressource managed-istio-custom für die Konfigurationszuordnung (configmap).

    kubectl edit cm managed-istio-custom -n ibm-operators

  2. Notieren Sie den Namen der Einstellung istio-ingressgateway-zone-<1|2|3> für das Gateway. Notieren Sie im vorliegenden Beispiel der Konfigurationszuordnung den Schlüssel istio-ingressgateway-zone-1, um den Pod ibm-cloud-provider-ip für das in dal10 vorhandene Gateway zu verschieben.

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "true"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  3. Inaktivieren Sie das Gateway vorübergehend, indem Sie die entsprechende Einstellung istio-ingressgateway-public-<1|2|3>-enabled in "false" ändern. Ändern Sie in dieser Beispielkonfigurationszuordnung ibm-cloud-provider-ip in dal10, um den istio-ingressgateway-public-1-enabled-Pod für das in "false" vorhandene Gateway zu verschieben.

    apiVersion: v1
data:
  istio-ingressgateway-zone-1: dal10
  istio-ingressgateway-zone-2: dal12
  istio-ingressgateway-public-1-enabled: "false"
  istio-ingressgateway-public-2-enabled: "true"
  istio-monitoring: "true"
kind: ConfigMap
...

  4. Speichern und schließen Sie die Konfigurationsdatei.

  5. Stellen Sie sicher, dass die Lastausgleichsfunktion des Gateways gelöscht wird. Beachten Sie, dass es möglicherweise bis zu 30 Minuten dauern kann, bis die Änderungen abgeschlossen sind.

    kubectl get service -n istio-system -o wide

  6. Öffnen Sie die Konfigurationszuordnungsressource managed-istio-custom.

    kubectl edit cm managed-istio-custom -n ibm-operators

  7. Reaktivieren Sie das Gateway, indem Sie die Einstellung istio-ingressgateway-public-<1|2|3>-enabled wieder auf "true" setzen.

  8. Speichern und schließen Sie die Konfigurationsdatei. Ein neuer Lastausgleichsservice für das Gateway (der istio-ingressgateway-Pod) wird erstellt und ein neuer ibm-cloud-provider-ip-Pod für diese Lastausgleichsfunktion wird auf einem Workerknoten in derselben Zone bereitgestellt wie der istio-ingressgateway-Pod.

  9. Um zu überprüfen, ob die Pods jetzt in derselben Zone vorhanden sind, führen Sie die Schritte im Abschnitt Mögliche Ursache aus.