Auf Systemdiagnosen basierendes Load Balancing konfigurieren

In diesem Dokument wird beschrieben, wie Sie mit Load-Balancing auf Grundlage von Systemdiagnosen eine hohe Verfügbarkeit für nichtflüchtige IP-Adressen in Google Kubernetes Engine (GKE) implementieren. Bei Standardkonfigurationen für nichtflüchtige IP-Adressen wird eine einzelne nichtflüchtige IP-Adresse einem einzelnen Pod zugeordnet. Mit Load-Balancing auf Grundlage von Systemdiagnosen können Sie jedoch Traffic von einer oder mehreren nichtflüchtigen IP-Adressen auf einen Pool fehlerfreier 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 an diese Standby-Pods weiter, wenn bei allen primären aktiven Pods die Systemdiagnose fehlschlägt.

Anforderungen und Einschränkungen

  • Um Load-Balancing auf Grundlage von Systemdiagnosen zu verwenden, muss Ihr Cluster die GKE-Version 1.32.3-gke.1440000 oder höher verwenden. GKE unterstützt die Auswahl von Backup-Pods nur in Version 1.35.0-gke.1403000 oder höher.
  • 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. Feld, um eine ordnungsgemäße Verteilung der Pods zu gewährleisten.
  • Sie können eine Gateway-Klasse nicht mehr ändern, nachdem Sie das GKEIPRoute-Objekt erstellt haben.
  • Load-Balancing auf Grundlage von Systemdiagnosen unterstützt nur Traffic, der von außerhalb der Arbeitslast initiiert wird. Traffic, der innerhalb der Arbeitslast an die nichtflüchtige 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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Load-Balancing auf Grundlage von Systemdiagnosen implementieren

In diesem Abschnitt wird der Workflow zur Implementierung von Load-Balancing 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 Netzwerkebene mit, welche Endpunkte fehlerfrei sind und Traffic von der nichtflüchtigen 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 bieten die zugrunde liegende Infrastruktur, die zum Verwalten von nichtflüchtigem 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 nichtflüchtiger 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 Label-Auswahlen einer Gruppe von Pods zuordnen. In diesem Objekt verweisen Sie auf Ihre regionale Systemdiagnose und legen optional Backup-Pods für Failover-Szenarien fest.
  6. Übereinstimmende Endpunkte ansehen: Prüfen Sie, ob GKE Ihre aktiven und Backup-Pods korrekt identifiziert hat, indem Sie die automatisch generierten EndpointSlices untersuchen. Mit diesem Schritt wird bestätigt, dass Ihre Labels mit den erwarteten Pods übereinstimmen und dass die Netzwerkebene 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 hier angegebene Name 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 aktiviertem 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 Unterstützung 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 nichtflüchtige IP-Adressen verarbeiten, regional sind. Ihre IP-Adresse und Ihr GKE-Cluster müssen sich in derselben Region befinden, damit das Routing ordnungsgemäß 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 Traffic in Ihrem privaten Netzwerk korrekt weitergeleitet wird, müssen interne IP-Adressen zum Standard-Subnetz des Clusters oder zum zusätzlichen Netzwerk-Subnetz gehören.

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

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 vorhandene Systeme in migrieren Google Cloud. Um BYOIP zu verwenden, prüft Google, ob Sie der Eigentümer des IP-Adressbereichs sind. Nachdem die IP Adressen in importiert wurden Google Cloud, können Sie sie als die 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 vorhergehenden Beispiel die folgenden Felder:

  • addresses: Listet alle IP-Adressbereiche auf, 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 Ihre primären und Backup-Pod-Auswahlen definieren und die in Schritt 1 erstellte Systemdiagnose zuordnen.

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 nichtflüchtigen 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 mit dieser Auswahl übereinstimmen. 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 ist veränderlich.
  • backupPodSelector: Definiert die Standby-Pods, die nur dann Traffic empfangen, wenn bei allen primären Pods, die mit dem podSelector-Objekt übereinstimmen, die Systemdiagnose fehlschlägt. Diese Auswahl umfasst Folgendes:
    • namespaceSelector: Bestimmt, in welchen Namespaces GKE nach diesen Backup-Pods sucht. Sie können die Suche mithilfe von Label-Auswahlen auf bestimmte Namespaces beschränken. Wenn dieses Feld leer ist oder fehlt, sucht GKE in allen Namespaces im Cluster nach Backup-Pods.
    • podSelector: Gleicht Backup-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, können Ihre Anwendungen diese IP-Adressen nicht automatisch verwenden. Die IP-Adressen werden auf der Ebene des Netzwerk-Routings verarbeitet, aber die Standardkonfiguration Ihres Pods ist sich dessen nicht bewusst. 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 Ihre Pod-Spezifikation mit einer der folgenden Optionen konfigurieren:

  • Ändern Sie net.ipv4.ip_nonlocal_bind sysctl

    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_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 unter spec.template.spec Folgendes in Ihre Deployment- oder StatefulSet-YAML-Spezifikation ein:

    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 mit einem 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 unter spec.template.spec Folgendes in Ihre Deployment- oder StatefulSet-YAML-Spezifikation ein:

    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)

Um gültige ARP-Anfragen (Address Resolution Protocol) und -Antworten zu generieren und eine neue Verbindung zu einem Pod mit der vom GKEIPRoute-Objekt zugewiesenen IP-Adresse im Standardnetzwerk herzustellen, 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 verarbeitet werden. Wenn Sie sie auf „2“ setzen, wird sichergestellt, dass ARP-Ankündigungen für die nichtflüchtige IP-Adresse erfolgen, sodass andere Geräte im Netzwerk über die neue Zuordnung informiert werden.

Schritt 8: Übereinstimmende Endpunkte ansehen

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

GKE generiert separate EndpointSlices für aktive und Backup-Endpunkte. Das System skaliert die Anzahl der EndpointSlices automatisch basierend auf Ihrer Arbeitslast. Ein einzelner EndpointSlice unterstützt bis zu 1.000 Endpunkte. GKE erstellt jedoch 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 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 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 Load-Balancing auf Grundlage von Systemdiagnosen beheben.

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

Symptom

Der GKEIPRoute-Status zeigt Ready an. 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 Labels des Felds 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 empfangen keinen Traffic.

Ursache

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

Lösung

Fehler bei der ungültigen Load-Balancer-Konfiguration

In diesem Abschnitt wird beschrieben, wie Sie Fehler im GKEIPRoute-Status 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 mit demselben GKEIPRoute-Objekt übereinstimmen, sind auf demselben Knoten geplant. Mit anderen Worten: Es gibt Pods, die sowohl mit den aktiven als auch mit den Backup-Pod-Auswahl-Objekten auf demselben Knoten übereinstimmen.

Lösung

Achten Sie darauf, dass sich die aktiven und Backup-Pods auf verschiedenen Knoten befinden. Aktualisieren Sie Ihre GKEIPRoute-Konfiguration und passen Sie die Labels podSelector oder backupPodSelector so an, dass nicht 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 stimmen mit den Label-Auswahlen für das Feld podSelector (aktiv) und das Feld backupPodSelector (Standby) überein. GKE erfordert, dass sich diese beiden Gruppen gegenseitig ausschließen. Ein einzelner Pod kann nicht als eigenes Backup 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 unterschiedliche Label-Schlüssel und -Werte zu verwenden.

Status NoPodsFound

Symptom

Das GKEIPRoute-Manifest zeigt den Status NoPodsFound an. Das bedeutet, dass in den Namespaces keine Pods mit übereinstimmenden Labels vorhanden sind.

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. Dazu prüfen Sie das 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, aber sich nicht im Status READY befindet, kann der Pod 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 Ihres Gateways angegeben werden. Wenn reactionMode == Exists, prüfen Sie, ob der Pod einem Knoten zugewiesen ist. Dazu prüfen Sie das 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.

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

Symptom

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

Mögliche Ursache

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

Lösung

  1. Warten und wiederholen: In den meisten Fällen wird die Konfiguration innerhalb kurzer Zeit automatisch abgeschlossen. Prüfen Sie nach dem Warten den Status. Bei Erfolg ändert er sich in Ready.

  2. Bei Bedarf weiter untersuchen: Wenn der Mutated Status ü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