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 Netzwerkschicht 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. Die GKE leitet Traffic nur dann an diese Standby-Pods weiter, wenn alle primären aktiven Pods die Systemdiagnose nicht bestehen.

Anforderungen und Einschränkungen

  • Wenn Sie das auf Systemdiagnosen basierende Load-Balancing verwenden möchten, muss Ihr Cluster die GKE-Version 1.32.3-gke.1440000 oder höher verwenden. Die Auswahl von Sicherungs-Pods wird in GKE nur ab Version 1.35.0-gke.1403000 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 der Pod-Auswahl 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.

Hinweis

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 diese Aufgabe 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 für die Implementierung des Systemdiagnose-basierten Lastenausgleichs zusammengefasst:

  1. Regionale Systemdiagnose erstellen: Definieren Sie die Parameter, die GKE zum Überwachen des Status Ihrer Pods verwendet. 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 des persistenten IP-Routings und des Load Balancing auf Basis 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 aus dem 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 geben optional Backup-Pods für Failover-Szenarien an.
  6. Abgestimmte 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 sich auf von Google bereitgestellte IP-Adressen zu verlassen. BYOIP ist hilfreich, wenn Sie bestimmte IP-Adressen für Ihre Anwendungen benötigen oder bestehende Systeme in Google Cloudmigrieren. Wenn Sie BYOIP verwenden möchten, prüft Google, ob Sie der Inhaber 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 Listener-Nutzung finden Sie unter Gateway-Objekte erstellen.

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

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

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 für den Empfang von Traffic aus. 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, ihre 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 wird oder leer ist, sucht GKE in allen Namespaces im Cluster nach Sicherungs-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

Durch das Zuweisen einer IP-Adresse zu einem GKE-Pod mithilfe eines GKEIPRoute-Objekts werden die IP-Adressen nicht automatisch für Ihre Anwendung nutzbar. Die IP-Adressen werden auf Netzwerkroutingebene verarbeitet, sind aber in der Standardkonfiguration Ihres Pods nicht bekannt. Sie müssen die Pod-Spezifikation so konfigurieren, dass die Adresse im Pod erkannt und verwendet wird. Dazu benötigt Ihr Pod Berechtigungen.

Sie können Ihre 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 ihrer Schnittstelle nicht direkt zugewiesen sind. Legen Sie dazu net.ipv4.ip_nonlocal_bind sysctl in Ihrem Pod securityContext 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 Ihrer YAML-Spezifikation für das Deployment oder 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 IP-Adresse, die vom GKEIPRoute-Objekt beansprucht wird, manuell über einen Init-Container einer der Schnittstellen des Pods hinzufügen. Dadurch wird die IP-Adresse für den Pod sichtbar, als wäre sie direkt zugewiesen. Dazu ist die Funktion NET_ADMIN erforderlich.

    Fügen Sie Ihrer Deployment- oder StatefulSet-YAML-Spezifikation 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 (erweiterte Funktion).

  • 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)

Wenn Sie gültige ARP-Anfragen (Address Resolution Protocol) und -Antworten generieren und eine neue Verbindung zu einem Pod über die vom GKEIPRoute-Objekt im Standardnetzwerk zugewiesene IP-Adresse herstellen möchten, müssen Sie die Variable arp_announce konfigurieren.

Führen Sie den folgenden Befehl in 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 verarbeitet 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 Registrierung 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 einzelnes EndpointSlice bis zu 1.000 Endpunkte unterstützt,erstellt GKE zusätzliche Segmente, 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 einen 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 nur 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 Endpunkttyp, 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 auf Systemdiagnosen basierenden Lastenausgleich beheben.

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

Symptom

Der Status von GKEIPRoute 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 erhalten 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 Systemdiagnosen reagiert.
  • Bei Bedarf weiter untersuchen: Wenn der Pod fehlerhaft ist, prüfen Sie, ob Sie Firewalls für die Systemdiagnosen richtig eingerichtet haben und ob Ihr Pod antwortet.

Fehler bei ungültiger Load-Balancer-Konfiguration

In diesem Abschnitt erfahren Sie, wie Sie Statusfehler bei GKEIPRoute beheben.

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 den aktiven als auch mit den Backup-PodSelector-Objekten auf demselben Knoten übereinstimmen.

Lösung

Achten Sie darauf, dass sich die aktiven und die Sicherungs-Pods auf verschiedenen 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 (Standby). 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 Label-Schlüssel und ‑Werte zu verwenden.

Status von NoPodsFound

Symptom

Das GKEIPRoute-Manifest hat den Status NoPodsFound. Das bedeutet, 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 reactionMode == Exists, prüfen Sie, ob der Pod einem Knoten zugewiesen ist. Sehen Sie dazu im Feld pod.Spec.nodeName nach. 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, aber nicht im Status READY ist, kann er keinen Traffic bereitstellen und wird nicht ausgewählt.

Lösung

  • Labels prüfen: Prüfen Sie, ob die Labels im Feld podSelector des 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 Status reactionMode == Exists lautet, prüfen Sie, ob der Pod einem Knoten zugewiesen ist. Sehen Sie sich dazu das Feld pod.Spec.nodeName an.

  • 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 einer GKEIPRoute-IP-Adresse ausgeführt wird

Symptom

Der GKEIPRoute-Status ist Mutated. Das bedeutet, dass die IP-Adresskonfiguration für einen übereinstimmenden Pod gerade ausgeführt wird.

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 wiederholen: In den meisten Fällen wird der Konfigurationsvorgang innerhalb kurzer Zeit automatisch abgeschlossen. Prüfen Sie den Status nach dem Warten. Er ändert sich bei Erfolg 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-Konfiguration 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