Auf Systemdiagnosen basierendes Load Balancing konfigurieren

In diesem Dokument wird beschrieben, wie Sie mit auf Health Checks basierendem Load Balancing Hochverfügbarkeit für statische IP-Adressen in Google Kubernetes Engine (GKE) implementieren. Bei standardmäßigen Konfigurationen mit nichtflüchtigen IP-Adressen wird eine einzelne nichtflüchtige IP-Adresse einem einzelnen Pod zugeordnet. Beim Systemdiagnose-basierten Load-Balancing können Sie jedoch Traffic von einer oder mehreren nichtflüchtigen IP-Adressen auf einen Pool von fehlerfreien Pods verteilen.

Wenn Sie bestimmte nichtflüchtige IP-Adressen beanspruchen und festlegen möchten, welche Pods Traffic empfangen, erstellen Sie eine benutzerdefinierte GKEIPRoute-Ressource. Durch die Integration der GKEIPRoute-Ressource in regionale Systemdiagnosen überwacht GKE Ihre Arbeitslasten auf der Netzwerkebene und leitet Traffic nur an Pods weiter, die bereit sind, ihn zu empfangen. Sie können auch optionale Backup-Pods mit dem GKEIPRoute-Objekt festlegen. GKE leitet Traffic nur dann an diese Standby-Pods weiter, wenn bei allen primären aktiven Pods die Systemdiagnose fehlschlägt.

Anforderungen und Einschränkungen

  • Wenn Sie Load-Balancing auf Grundlage von Systemdiagnosen verwenden möchten, muss Ihr Cluster die GKE-Version 1.32.3-gke.1440000 oder höher verwenden. In GKE wird die Auswahl von Backup-Pods nur in Version 1.35.0-gke.1403000 oder höher unterstützt.
  • In Ihrem Cluster müssen GKE Dataplane V2 und die Gateway API aktiviert sein.
  • Ein einzelnes GKEIPRoute-Objekt unterstützt nur einen übereinstimmenden Pod pro Knoten. Wenn mehrere Pods auf einem Knoten mit dem Pod-Selektor von GKEIPRoute übereinstimmen, wählt GKE den zuletzt erstellten Pod auf diesem Knoten aus.
  • Sie können eine Gateway-Klasse nicht mehr ändern, nachdem Sie das GKEIPRoute-Objekt erstellt haben.
  • Systemdiagnosebasiertes Load-Balancing unterstützt nur Traffic, der von außerhalb der Arbeitslast initiiert wird. Traffic, der von der Arbeitslast zur persistenten IP-Adresse initiiert wird, wird nicht unterstützt.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Systemdiagnosebasiertes Load-Balancing implementieren

In diesem Abschnitt wird der Workflow zum Implementieren des Load-Balancings auf Grundlage von Systemdiagnosen zusammengefasst:

  1. Regionale Systemdiagnose erstellen: Definieren Sie die Parameter, die GKE verwendet, um den Status Ihrer Pods zu überwachen. Dieses Objekt teilt der Netzwerkschicht mit, welche Endpunkte fehlerfrei sind und Traffic von der persistenten IP-Adresse empfangen können.
  2. Cluster erstellen: Richten Sie einen GKE-Cluster mit aktiviertem GKE Dataplane V2 und aktivierter Gateway API ein. Diese Komponenten stellen die zugrunde liegende Infrastruktur bereit, die für die Verwaltung von persistentem IP-Routing und Load-Balancing auf Grundlage von Systemdiagnosen erforderlich ist.
  3. IP-Adresse reservieren: Wählen Sie eine statische interne oder externe IP-Adresse in derselben Region wie Ihr Cluster aus und reservieren Sie sie. Diese Adresse dient als dauerhafter Einstiegspunkt, den GKE auf Ihren Pool aktiver oder Backup-Pods verteilt.
  4. Gateway erstellen: Konfigurieren Sie ein Gateway-Objekt, um Ihre reservierten nichtflüchtigen IP-Adressen zu verwalten. Das GKEIPRoute-Objekt beansprucht und verwendet bestimmte IP-Adressen vom Gateway für Ihre Arbeitslasten.
  5. GKEIPRoute-Objekt erstellen: Definieren Sie die Routingregeln, die Ihre nichtflüchtige IP-Adresse mithilfe von Labelselektoren einer Gruppe von Pods zuordnen. In diesem Objekt verweisen Sie auf Ihre regionale Systemdiagnose und können optional Backup-Pods für Failover-Szenarien festlegen.
  6. Übereinstimmende Endpunkte ansehen: Prüfen Sie, ob GKE Ihre aktiven und Backup-Pods anhand der automatisch generierten EndpointSlices korrekt identifiziert hat. In diesem Schritt wird bestätigt, dass Ihre Labels mit den erwarteten Pods übereinstimmen und dass die Netzwerkschicht bereit ist, Traffic weiterzuleiten.

Schritt 1: Regionale Systemdiagnose und Firewallregeln erstellen

Folgen Sie der Anleitung unter Systemdiagnosen erstellen, um eine regionale Systemdiagnose zu erstellen. Der Name, den Sie hier angeben, wird in Ihrer GKEIPRoute-Konfiguration verwendet. Beispiel:

gcloud compute health-checks create http reg-lb-hc \
    --region=us-central1 \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2

Damit Systemdiagnoseprüfungen von Google Cloud Ihre Knoten erreichen können, müssen Sie auch Firewallregeln erstellen.

Schritt 2: GKE-Cluster erstellen

Erstellen Sie einen Cluster mit aktivierter Gateway API und GKE Dataplane V2. Beispiel:

gcloud container clusters create cluster-1 \
    --enable-dataplane-v2 \
    --gateway-api=standard \
    --region=us-central1

Wenn Sie das GKEIPRoute-Objekt in einem VPC-Netzwerk konfigurieren, das sich vom Standard-VPC-Netzwerk des Clusters unterscheidet, müssen Sie einen GKE-Cluster mit Funktionen für mehrere Netzwerke erstellen. Weitere Informationen finden Sie unter Unterstützung mehrerer Netzwerke für Pods einrichten.

Schritt 3: IP-Adressen reservieren

Reservieren Sie die IP-Adressen, die Sie für Ihre Arbeitslasten verwenden möchten. Sie können von Google bereitgestellte IP-Adressen reservieren oder Ihre eigenen (BYOIP) verwenden.

Schritt 3a: Von Google bereitgestellte IP-Adressen reservieren

Führen Sie den folgenden Befehl aus, um externe IP-Adressen zu reservieren:

gcloud compute addresses create ADDRESS_NAME \
   --region=REGION

Ersetzen Sie Folgendes:

  • ADDRESS_NAME: der Name, den Sie mit dieser Adresse verknüpfen möchten.

  • REGION: die Region, in der Sie diese Adresse reservieren möchten. Die Region muss sich in derselben Region befinden wie der Pod, dem Sie die IP-Adresse zuweisen möchten.

    Hinweis: Sie müssen eine Region angeben, wenn Sie eine IP-Adresse reservieren, da Weiterleitungsregeln, die das Traffic-Routing für statische IP-Adressen verarbeiten, regional sind. Ihre IP-Adresse und Ihr GKE-Cluster müssen sich in derselben Region befinden, damit das Routing richtig funktioniert.

Führen Sie den folgenden Befehl aus, um interne IP-Adressen zu reservieren:

gcloud compute addresses create ADDRESS_NAME \
    --region REGION
    --subnet SUBNETWORK \
    --addresses IP_ADDRESS

Ersetzen Sie Folgendes:

  • ADDRESS_NAME: Die Namen einer oder mehrerer Adressen, die Sie reservieren möchten. Geben Sie bei mehreren Adressen alle Adressen als Liste an, getrennt durch Leerzeichen. Beispiel: example-address-1 example-address-2 example-address-3.
  • REGION: Die Region für diese Anfrage.
  • SUBNETWORK: Das Subnetz für diese interne IPv4-Adresse.
  • IP_ADDRESS ist eine nicht verwendete interne IP-Adresse aus dem primären IP-Adressbereich des ausgewählten Subnetzes.

Damit der Traffic in Ihrem privaten Netzwerk richtig weitergeleitet wird, müssen interne IP-Adressen zum Standardsubnetz oder zum zusätzlichen Netzwerksubnetz des Clusters gehören.

Weitere Informationen zu externen und internen IP-Adressen oder zum Reservieren von Adressen über die Google Cloud -Konsole finden Sie unter Statische externe IP-Adresse reservieren und Statische interne IP-Adresse reservieren.

Schritt 3b: Eigene IP-Adressen verwenden (Bring your own IP, BYOIP)

Sie können Ihre eigenen IP-Adressen (BYOIP) verwenden, anstatt auf von Google bereitgestellte IP-Adressen zurückzugreifen. BYOIP ist hilfreich, wenn Sie bestimmte IP-Adressen für Ihre Anwendungen benötigen oder vorhandene Systeme in Google Cloudverschieben. Wenn Sie BYOIP verwenden möchten, prüft Google, ob Sie der Eigentümer des IP-Adressbereichs sind. Nachdem die IP-Adressen in Google Cloudimportiert wurden, können Sie sie als IP-Adressen für GKE-Pods zuweisen. Weitere Informationen finden Sie unter Eigene IP-Adressen verwenden.

Schritt 4: Gateway-Objekte erstellen

Sie erstellen ein Gateway mit einer der folgenden Gateway-Klassen, die nur den L3-Netzwerktyp unterstützen:

  • gke-passthrough-lb-external-managed oder
  • gke-passthrough-lb-internal-managed.

Im folgenden Beispiel wird ein Gateway definiert, das einen Pool externer IP-Adressen verwaltet:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: lb-gateway
spec:
  gatewayClassName: gke-passthrough-lb-external-managed

  listeners:
    - name: default
      port: 443
      protocol: none
      allowedRoutes:
        namespaces:
          from: All

  addresses:
    - value: "34.123.10.1/32"
      type: "gke.networking.io/cidr"
    - value: "34.123.10.2/32"
      type: "gke.networking.io/cidr"

Beachten Sie im vorherigen Beispiel die folgenden Felder:

  • addresses: Hier werden alle IP-Adressbereiche aufgeführt, für die das jeweilige Gateway Berechtigungen verwaltet.
  • listeners: Gibt die Namespaces an, aus denen GKEIPRoute-Objekte auf dieses Gateway verweisen können.

Weitere Informationen zur Verwendung von Listenern finden Sie unter Gateway-Objekte erstellen.

Schritt 5: GKEIPRoute-Objekt mit Load-Balancing- und Systemdiagnosekonfiguration erstellen

Erstellen Sie ein GKEIPRoute-Objekt, in dem Sie die primären und Backup-Pod-Selektoren definieren, und verknüpfen Sie die Systemdiagnose, die Sie in Schritt 1 erstellt haben.

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: default
  name: my-ip-route
spec:
  parentRefs:
  - name: lb-gateway
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: default
  podSelector:
    matchLabels:
      component: activePodSelector

  loadBalancing:
    healthCheckName: "reg-lb-hc"
    backupPodSelector:
      namespaceSelector:
        matchLabels:
          environment: test
          dc: us-central
      podSelector:
        matchLabels:
          component: backupPodSelector
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: proxy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: proxy
  template:
    metadata:
      # annotations:  <- Include these lines if the pods are multi-nic pods
      #   networking.gke.io/default-interface: 'eth0'
      #   networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Wichtige Hinweise:

  • podSelector: Gibt die primären aktiven Pods an, die Traffic von den definierten persistenten IP-Adressen empfangen. In diesem Feld werden Labels verwendet, um Pods im selben Namespace wie die GKEIPRoute-Ressource abzugleichen. GKE verteilt den Traffic auf alle fehlerfreien Pods, die dieser Auswahl entsprechen. Wenn sich mehrere übereinstimmende Pods auf demselben Knoten befinden, wählt GKE nur den zuletzt erstellten Pod aus, um Traffic zu empfangen. Die hier definierten Labels dürfen sich nicht mit denen im Feld backupPodSelector überschneiden. Dieses Feld kann geändert werden.
  • backupPodSelector: Definiert die Standby-Pods, die nur dann Traffic empfangen, wenn alle primären Pods, die mit dem podSelector-Objekt übereinstimmen, die Systemdiagnosen nicht bestehen. Dieser Selektor umfasst Folgendes:
    • namespaceSelector: bestimmt, in welchen Namespaces GKE nach diesen Sicherungs-Pods sucht. Mit Label-Selektoren können Sie die Suche auf bestimmte Namespaces beschränken. Wenn dieses Feld weggelassen oder leer ist, sucht GKE in allen Namespaces im Cluster nach Backup-Pods.
    • podSelector: Gleicht Sicherungs-Pods anhand ihrer Labels ab. Diese Labels müssen sich von denen unterscheiden, die im primären podSelector-Objekt verwendet werden.

Weitere Informationen zu den anderen Feldern in diesem Manifest finden Sie unter GKEIPRoute-Objekt erstellen.

Schritt 6: Zugewiesene IP-Adressen im Pod verwenden

Wenn Sie einem GKE-Pod mithilfe eines GKEIPRoute-Objekts eine IP-Adresse zuweisen, sind die IP-Adressen nicht automatisch für Ihre Anwendung nutzbar. Die IP-Adressen werden auf Netzwerkrouting-Ebene verarbeitet, aber die Standardkonfiguration Ihres Pods kennt sie nicht. Sie müssen Ihre Pod-Spezifikation so konfigurieren, dass die Adresse im Pod erkannt und verwendet wird. Dazu benötigt Ihr Pod Berechtigungen.

Sie können die Pod-Spezifikation mit einer der folgenden Optionen konfigurieren:

  • net.ipv4.ip_nonlocal_bind-Sysctl ändern

    Sie können die Systemeinstellungen so ändern, dass Ihre Anwendung IP-Adressen verwenden kann, die nicht direkt ihrer Schnittstelle zugewiesen sind. Dazu legen Sie net.ipv4.ip_nonlocal_bindsysctlsecurityContext in Ihrem Pod fest. Diese Option ist nützlich, wenn Ihre Anwendung an eine IP-Adresse gebunden werden kann, die sich nicht auf einer Schnittstelle befindet.

    Fügen Sie der YAML-Spezifikation für die Bereitstellung oder das StatefulSet unter spec.template.spec Folgendes hinzu:

    securityContext:
  sysctls:
  - name: net.ipv4.ip_nonlocal_bind
    value: "1"

  • Zugewiesene IP-Adresse der Pod-Schnittstelle hinzufügen

    Sie können die vom GKEIPRoute-Objekt beanspruchte IP-Adresse manuell über einen Init-Container einer der Schnittstellen des Pods hinzufügen. Dadurch wird die IP-Adresse für den Pod so sichtbar, als wäre sie direkt zugewiesen. Dazu ist die Funktion NET_ADMIN erforderlich.

    Fügen Sie der YAML-Spezifikation für die Bereitstellung oder das StatefulSet unter spec.template.spec Folgendes hinzu:

    initContainers:
- name: configure-ips
  image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
  command: ['sh', '-c', 'ip address add ASSIGNED_IP/32 dev eth0']
  securityContext:
    capabilities:
      add:
      - NET_ADMIN

    Ersetzen Sie ASSIGNED_IP durch eine der IP-Adressen, die dem GKEIPRoute-Objekt zugewiesen sind.

  • Raw Sockets:Für noch mehr Kontrolle kann Ihre Anwendung direkt mit dem Netzwerk-Stack interagieren (erweitert).

  • Userspace-IP-Adress-Stack:In speziellen Fällen kann eine separate Anwendung im Pod ausgeführt werden, um die IP-Adresse zu verwalten (sehr fortgeschritten).

Schritt 7: ARP für die zugewiesenen IP-Adressen aktivieren (nur Standardnetzwerk)

Damit gültige ARP-Anfragen (Address Resolution Protocol) und -Antworten generiert und eine neue Verbindung zu einem Pod über die IP-Adresse hergestellt werden kann, die vom GKEIPRoute-Objekt im Standardnetzwerk zugewiesen wird, müssen Sie die Variable arp_announce konfigurieren.

Führen Sie den folgenden Befehl auf Ihrem Pod aus, um die Variable arp_announce festzulegen:

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

Die Variable arp_announce steuert, wie ARP-Ankündigungen behandelt werden. Wenn Sie den Wert auf „2“ setzen, werden ARP-Ankündigungen für die persistente IP-Adresse gesendet, sodass andere Geräte im Netzwerk die neue Zuordnung kennenlernen.

Schritt 8: Übereinstimmende Endpunkte ansehen

Zur Verwaltung der Traffic-Verteilung erstellt GKE EndpointSlices für jedes GKEIPRoute-Objekt. Diese Slices fungieren als Registry aller Pods, die als Routingziele für diese bestimmte Route vorgesehen sind.

GKE generiert separate EndpointSlices für aktive und Backup-Endpunkte. Das System skaliert die Anzahl der EndpointSlices automatisch basierend auf Ihrer Arbeitslast. Obwohl ein einzelner EndpointSlice bis zu 1.000 Endpunkte unterstützt,erstellt GKE zusätzliche Slices, wenn die Anzahl der übereinstimmenden Pods dieses Limit überschreitet.

Führen Sie den folgenden Befehl aus, um alle EndpointSlices für ein bestimmtes GKEIPRoute-Objekt aufzurufen:

kubectl get endpointslices --all-namespaces -l \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,\
  networking.gke.io/gkeiproute-namespace=GKEIPROUTE_NAMESPACE

Ersetzen Sie Folgendes:

  • GKEIPROUTE_NAME: der Name des GKEIPRoute-Manifests.
  • GKEIPROUTE_NAMESPACE: der Namespace des GKEIPRoute-Manifests.

Die folgende Ausgabe zeigt ein Beispiel für eine EndpointSlice:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
 name: {gkeiproute_name-truncated}-{gkeiproute_namespace-truncated}-backup-{unique_hash}
 namespace: {gkeiproute_namespace}
 labels:
  endpointslice.kubernetes.io/managed-by: gkeiproute-controller
  networking.gke.io/gkeiproute-name: {gkeiproute_name}
  networking.gke.io/gkeiproute-namespace: {gkeiproute_namespace}
  networking.gke.io/pip-es-role: backup
 ownerReferences:
  - kind: GKEIPRoute
    name: {gkeiproute_name}
    apiVersion: networking.gke.io/v1
    uid: {uid}
    controller: true
addressType: IPv4
endpoints:
 - addresses:
     - "{pod_ip_address}"
   targetRef:
     Name: {pod_name}
   nodeName: {node_name}

Wenn Sie EndpointSlices speziell für aktive oder Backup-Endpunkte aufrufen möchten, filtern Sie die Ergebnisse mit dem Label pip-eps-role. Beispiel:

kubectl get endpointslices --all-namespaces -l \
   networking.gke.io/pip-eps-role=ROLE \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,

Ersetzen Sie Folgendes:

  • ROLE: Der Typ des Endpunkts, den Sie aufrufen möchten, entweder active oder backup.
  • GKEIPROUTE_NAME: der Name Ihres spezifischen GKEIPRoute-Objekts.

Fehlerbehebung beim Load-Balancing auf Grundlage von Systemdiagnosen

In diesem Abschnitt wird beschrieben, wie Sie Probleme im Zusammenhang mit dem Load-Balancing auf Grundlage von Systemdiagnosen beheben.

Einige aktive Pods sind fehlerhaft, aber Backup-Pods erhalten keinen Traffic

Symptom

Der GKEIPRoute-Status ist Ready. Das bedeutet, dass die IP-Adresskonfiguration für übereinstimmende Pods abgeschlossen ist. Systemdiagnosen oder andere Diagnosen zeigen, dass einige aktive Pods fehlerhaft sind. Backup-Pods empfangen jedoch keinen Traffic.

Ursache

Backup-Pods empfangen erst dann Traffic, wenn alle aktiven Pods fehlerhaft sind. Bis dahin wird der gesamte Traffic auf die verbleibenden fehlerfreien, aktiven Pods verteilt.

Lösung

Aktualisieren Sie bei Bedarf die Feldlabels für podSelector, damit sie nicht mehr mit aktiven Pods übereinstimmen. GKE leitet Traffic automatisch an die Backend-Gruppe weiter.

GKEIPRoute ist konfiguriert, aber nicht alle Pods empfangen Traffic

Symptom

Der GKEIPRoute-Status zeigt Ready an. Das bedeutet, dass die IP-Adresskonfiguration für übereinstimmende Pods abgeschlossen ist, aber einige der übereinstimmenden Pods keinen Traffic empfangen.

Ursache

Die Pods, die keinen Traffic empfangen, sind möglicherweise nicht fehlerfrei oder reagieren nicht richtig auf Systemdiagnosen. Wenn alle übereinstimmenden Pods fehlerhaft sind, verteilt GKE den Traffic auf alle Pods, unabhängig von ihrem Zustand.

Lösung

  • Prüfen, ob der Pod fehlerfrei ist: Verwenden Sie die Google Cloud CLI oder dieGoogle Cloud Console, um zu prüfen, ob der Pod korrekt auf Health Checks reagiert.
  • Bei Bedarf weitere Untersuchungen durchführen: Wenn der Pod fehlerhaft ist, prüfen Sie, ob Sie Firewalls für die Systemdiagnosen richtig eingerichtet haben und ob Ihr Pod reagiert.

Fehler durch ungültige Load-Balancer-Konfiguration

In diesem Abschnitt finden Sie Informationen zur Fehlerbehebung bei Statusfehlern von GKEIPRoute.

Backup pod and active pod are on the same node

Symptom

Der GKEIPRoute-Status meldet den folgenden Fehler:

invalid LB configuration: Backup pod %s and active pod %s are on the same node %s. Active and backup pods must reside on different nodes.

Ursache

Ein aktiver Pod und ein Backup-Pod, die demselben GKEIPRoute-Objekt entsprechen, werden auf demselben Knoten geplant. Mit anderen Worten: Es gibt Pods, die sowohl mit dem aktiven als auch mit dem Backup-podSelector-Objekt auf demselben Knoten übereinstimmen.

Lösung

Achten Sie darauf, dass sich die aktiven und Backup-Pods auf unterschiedlichen Knoten befinden. Aktualisieren Sie die GKEIPRoute-Konfiguration und passen Sie die Labels podSelector oder backupPodSelector an, damit keine zwei Pods auf demselben Knoten mit demselben GKEIPRoute-Objekt übereinstimmen.

Pod cannot be selected as both an active and a backup pod

Symptom

Der GKEIPRoute-Status meldet den folgenden Fehler:

invalid LB configuration: pod %s cannot be selected as both an active and a backup pod. Active and backup pod sets must be mutually exclusive

Ursache

Ein oder mehrere Pods entsprechen den Labelselektoren für das Feld podSelector (aktiv) und das Feld backupPodSelector (Stand-by). In GKE müssen sich diese beiden Gruppen gegenseitig ausschließen. Ein einzelner Pod kann nicht als eigene Sicherung dienen.

Lösung

Achten Sie darauf, dass Ihre aktiven und Backup-Pods eindeutig sind. Ändern Sie das Feld podSelector oder das Feld backupPodSelector in Ihrem GKEIPRoute-Manifest, um spezifischere oder eindeutige Labelschlüssel und ‑werte zu verwenden.

Status von NoPodsFound

Symptom

Das GKEIPRoute-Manifest hat den Status NoPodsFound, was darauf hinweist, dass es in den Namespaces keine Pods mit übereinstimmenden Labels gibt.

Mögliche Ursachen

  • Falsche Labels: Der Pod, den Sie für die konfigurierte IP-Adresse verwenden möchten, hat möglicherweise falsche oder gar keine Labels.
  • Keine Pods vorhanden: Wenn der reactionMode == Exists, prüfen Sie, ob der Pod einem Knoten zugewiesen ist. Suchen Sie dazu nach dem Feld pod.Spec.nodeName. Möglicherweise werden im Namespace von GKEIPRoute keine Pods ausgeführt, die mit der Auswahl übereinstimmen.
  • Pods nicht bereit: Wenn reactionMode == ReadyCondition, prüfen Sie, ob der Pod-Status READY ist. Wenn ein übereinstimmender Pod vorhanden ist, er sich aber nicht im Status READY befindet, kann er keinen Traffic bereitstellen und wird daher nicht ausgewählt.

Lösung

  • Labels prüfen: Prüfen Sie, ob die Labels im Feld podSelector Ihres GKEIPRoute-Objekts mit den Labels übereinstimmen, die Sie auf den gewünschten Pod angewendet haben.
  • Pod-Vorhandensein prüfen: Achten Sie darauf, dass ein Pod mit den richtigen Labels tatsächlich in den Namespaces des GKEIPRoute-Objekts vorhanden ist, die durch die Listener des Gateways angegeben werden. Wenn der reactionMode == Exists, prüfen Sie, ob der Pod einem Knoten zugewiesen ist. Suchen Sie dazu nach dem Feld pod.Spec.nodeName.

  • Pod-Bereitschaft bestätigen: Wenn reactionMode == ReadyCondition, prüfen Sie, ob der Pod-Status READY ist. Prüfen Sie mit dem folgenden Befehl, ob sich der Pod im Status Ready befindet:

    kubectl get pods -n NAMESPACE

    Pods in anderen Status (z. B. Pending, Error) werden nicht ausgewählt.

Mutated-Status, wenn ein übereinstimmender Pod gefunden wurde und die Programmierung der GKEIPRoute-IP-Adresse ausgeführt wird

Symptom

Der GKEIPRoute-Status ist Mutated. Das bedeutet, dass die IP-Adresskonfiguration für einen übereinstimmenden Pod läuft.

Mögliche Ursache

Der Status Mutated ist während der Konfiguration zu erwarten, wenn das System den GKE-Datenpfad und die Google Cloud -Ressourcen für die konfigurierte IP-Adresse einrichtet.

Lösung

  1. Warten und noch einmal versuchen: In den meisten Fällen wird die Konfiguration automatisch innerhalb kurzer Zeit abgeschlossen. Prüfen Sie den Status nach der Wartezeit. Bei Erfolg ändert sich der Status zu Ready.

  2. Weiter untersuchen (falls erforderlich): Wenn der Status Mutated über einen längeren Zeitraum bestehen bleibt, kann dies auf einen Konfigurationsfehler hinweisen. Prüfen Sie die anderen Statusbedingungen für Ihr GKEIPRoute-Objekt:

    • Accepted: Gibt an, ob Ihre GKEIPRoute-Einrichtung gültig ist.
    • GCPReady: Gibt an, ob die Google Cloud Ressourcen wie erwartet eingerichtet sind.

Suchen Sie in diesen Bedingungen nach Fehlermeldungen, um das Problem zu beheben.

Nächste Schritte