Fehlerbehebung bei der IP-Adressverwaltung in VPC-Clustern

Eine effektive IP-Adressverwaltung ist entscheidend für die Stabilität und Skalierbarkeit von VPC-nativen Clustern in Google Kubernetes Engine (GKE). Probleme können die Skalierung verhindern oder zu Fehlern bei Arbeitslasten führen, z. B. dass Pods nicht geplant werden können.

In diesem Dokument finden Sie Informationen zur Fehlerbehebung und Behebung von Problemen im Zusammenhang mit der IP-Adresszuweisung, der Netzwerkstabilität und erweiterten Netzwerkfunktionen in VPC-nativen GKE-Clustern.

Diese Informationen richten sich in erster Linie an Plattformadministratoren und -betreiber, die die Netzwerkinfrastruktur des Clusters verwalten. Außerdem können Anwendungsentwickler so besser nachvollziehen, wie sich zugrunde liegende Netzwerkeinschränkungen, z. B. ein erschöpfter IP-Adressbereich, auf ihre Arbeitslasten auswirken können. Entwickler konfigurieren VPCs möglicherweise nicht direkt, aber wenn sie diese häufigen Probleme verstehen, können sie besser mit Plattformadministratoren und -operatoren zusammenarbeiten, um Probleme schneller zu beheben. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Aufgebrauchte IP-Adressen diagnostizieren

Wenn in Ihrem Cluster keine IP-Adressen mehr verfügbar sind, kann dies die Knotenskalierung verhindern und Ihre Arbeitslasten beeinträchtigen. In diesem Abschnitt wird erläutert, wie Sie das Monitoring der IP-Adressauslastung in GKE verwenden, um potenzielle Erschöpfungsprobleme zu erkennen und zu beheben.

Die GKE berechnet die IP-Adressauslastung anhand von Daten aus Network Analyzer-Insights und anderen GKE-Datenquellen. Dieses Monitoring ist für alle VPC-nativen Cluster verfügbar.

So rufen Sie die IP-Adressauslastung eines Clusters auf:

  1. Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster auf.

    Zur Seite "Kubernetes-Cluster"

  2. Klicken Sie auf den Namen des Clusters, den Sie prüfen möchten. Dadurch wird die Seite Details des Clusters geöffnet.

  3. Rufen Sie die Seite IP-Nutzung mit einer der folgenden Methoden auf:

    • Wählen Sie den Tab Beobachtbarkeit aus und klicken Sie dann im Navigationsmenü für die Beobachtbarkeit auf IP-Auslastung.

    • Suchen Sie im Abschnitt Netzwerk die Zeile Pod-IPv4-Bereich des Clusters (Standardeinstellung) und klicken Sie auf IP-Auslastung ansehen.

  4. Sehen Sie sich die Spalte Status der IP-Zuweisung an. In dieser Spalte wird der Prozentsatz der zugewiesenen IP-Adressen im IP-Adressbereich Ihres Pods angezeigt. Die GKE betrachtet alle IP-Adressen im zugewiesenen CIDR-Bereich eines Knotens als zugewiesen, unabhängig davon, ob einzelne IP-Adressen Pods zugewiesen sind. Dieses Verhalten bedeutet, dass der Prozentsatz den gesamten Pod-Bereich für einen Knoten widerspiegelt, nicht nur die verwendeten IP-Adressen. Wenn Cluster dieselben IP-Adressbereiche nutzen, wird der Prozentsatz der Auslastung als kombinierte Gesamtsumme angezeigt.

  5. Klicken Sie auf Details einblenden, um eine detaillierte Ansicht der IP-Adressnutzung aufzurufen, einschließlich CIDR-Bereichen, Subnetzinformationen und Empfehlungen.

Wenn die Auslastung Ihrer IP-Adressen hoch ist (fast 100 %), sollten Sie die folgenden Lösungen in Betracht ziehen, um eine Erschöpfung der IP-Adressen zu verhindern:

  • Fügen Sie mehr Pod-IPv4-Adressbereiche mithilfe von nicht zusammenhängenden Multi-Pod-CIDRs hinzu. Mit dieser Funktion können Sie Ihren Pods weitere IPv4-Adressen hinzufügen, ohne den Cluster neu erstellen oder neue Subnetze konfigurieren zu müssen.
  • Fügen Sie weitere Subnetze mit zusätzlichen IPv4-Adressbereichen im Cluster hinzu. Mit dieser Funktion können neue Knotenpools IP-Adressen aus neu hinzugefügten Subnetzen verwenden.
  • Erstellen Sie einen neuen Cluster mit einem niedrigeren Wert für die maximale Anzahl von Pods. Bei diesem Ansatz werden weniger IP-Adressen für jeden Knoten reserviert, was Ihnen helfen kann, den gesamten IP-Adressverbrauch im Netzwerkbereich Ihres Clusters zu verwalten. Weitere Informationen finden Sie unter Maximale Anzahl von Pods pro Knoten konfigurieren.
  • Wenn Sie nicht genügend IP-Adressbereiche oder RFC 1918-Adressbereiche haben, sollten Sie Nicht-RFC 1918-Bereiche (einschließlich des Adressbereichs der Klasse E) in Betracht ziehen.

GKE-Pod-CIDR-Zuweisungsberechnung

Eine häufige Quelle für Verwirrung ist, dass GKE nicht dynamisch einzelne Pod-IP-Adressen aus einem zentralen Pool bei Bedarf zuweist. Wenn ein neuer Knoten dem Cluster hinzugefügt wird, erstellt GKE stattdessen einen zusammenhängenden CIDR-Block aus dem sekundären Pod-Bereich des Subnetzes und weist ihn ausschließlich diesem Knoten zu.

Um Kollisionen beim IP-Recycling während schneller Pod-Rollouts zu vermeiden, weist GKE eine Blockgröße pro Knoten zu, die dem kleinsten Zweierpotenzblock entspricht, der mindestens 2 × maximale Pods pro Knoten-Adressen enthält:

Per-node Pod CIDR block size (addresses) = 2^(ceil(log2(2 * max_pods_per_node)))
  • Standardkonfiguration (--max-pods-per-node=110): Erfordert mindestens 2 × 110 = 220 Adressen. Die nächstgelegene Zweierpotenz ist 256 Adressen, wodurch jedem Knoten ein /24-Block (256 IP-Adressen) zugewiesen wird.
  • Auswirkungen auf die Clusterknotenkapazität: Da jeder Knoten einen /24-Block (256 Pod-IP-Adressen) verbraucht, unabhängig davon, wie viele Pods auf diesem Knoten ausgeführt werden, hängt die maximale Anzahl von Knoten, die von einem sekundären Pod-Bereich unterstützt werden, direkt von Ihrer --max-pods-per-node-Einstellung ab:
Maximale Podanzahl pro Knoten Pro Knoten zugewiesener Block Maximale Anzahl von Knoten pro /19-Pod-Bereich (8.192 IP-Adressen) Maximale Anzahl von Knoten pro /16-Pod-Bereich (65.536 IP-Adressen)
110 (Standard) /24 (256 IP-Adressen) 32 Knoten 256 Knoten
64 /25 (128 IP-Adressen) 64 Knoten 512 Knoten
32 (Autopilot-Standard) /26 (64 IP-Adressen) 128 Knoten 1.024 Knoten
16 /27 (32 IP-Adressen) 256 Knoten 2.048 Knoten
8 /28 (16 IP-Adressen) 512 Knoten 4.096 Knoten

Spezifische Netzwerkprobleme beheben

Die folgenden Abschnitte enthalten Hinweise zum Beheben von Problemen im Zusammenhang mit VPC-nativen Clustern. Sie können auch Statistiken zur GKE-IP-Adressauslastung ansehen.

Die Standardnetzwerkressource ist nicht bereit

Symptome

Es kann eine Fehlermeldung wie die folgende angezeigt werden:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Mögliche Ursachen

Es laufen mehrere Vorgänge im selben Subnetz. Beispielsweise wird ein anderer VPC-nativer Cluster erstellt oder ein sekundärer Bereich wird im Subnetz hinzugefügt oder gelöscht.

Lösung

Führen Sie den Befehl noch einmal aus.

Ungültiger Wert für IPCidrRange

Symptome

Es kann eine Fehlermeldung wie die folgende angezeigt werden:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Mögliche Ursachen

Ein anderer VPC-nativer Cluster wird zur gleichen Zeit erstellt und versucht, dieselben Bereiche im selben VPC-Netzwerk zuzuweisen.

Der gleiche sekundäre Bereich wird dem Subnetzwerk im selben VPC-Netzwerk hinzugefügt.

Lösung

Wenn dieser Fehler beim Erstellen des Clusters zurückgegeben wird und keine sekundären Bereiche angegeben wurden, führen Sie den Befehl zum Erstellen des Clusters noch einmal aus.

Zu wenig verfügbarer IP-Adressbereich für Pods

Symptome

Der Cluster hängt längere Zeit in einem Bereitstellungsstatus fest.

Bei der Clustererstellung wird ein Fehler der verwalteten Instanzgruppe (Managed Instance Group, MIG) ausgegeben.

Wenn Sie einem Cluster einen oder mehrere Knoten hinzufügen, wird der folgende Fehler angezeigt:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
Mögliche Ursachen

Ausschöpfung der Knoten-IP-Adressen: Im primären IP-Adressbereich des Ihrem Cluster zugewiesenen Subnetzes sind keine IP-Adressen mehr verfügbar. Das passiert in der Regel beim Skalieren von Knotenpools oder beim Erstellen großer Cluster.

Hohe anfängliche Knotenanzahl in herunterskalierten Knotenpools: GKE reserviert IP-Adressen für Pods basierend auf der anfänglichen Kapazität, die Sie beim Erstellen eines Knotenpools angefordert haben. Wenn Sie einen Knotenpool mit einem hohen initial_node_count-Wert erstellen und dann die Anzahl der Knoten herunterskalieren, reserviert GKE weiterhin IP-Adressraum basierend auf dem größeren Wert des initial_node_count-Werts des Knotenpools oder der aktuellen Anzahl der Knoten im Knotenpool. Diese Situation kann dazu führen, dass der Cluster meldet, dass die IP-Adressen aufgebraucht sind, auch wenn die aktuelle Anzahl aktiver Knoten niedrig ist.

Ausschöpfung der Pod-IP-Adressen:Der Pod-CIDR-Bereich, der Ihrem Cluster zugewiesen ist, ist voll. Dies tritt auf, wenn die Anzahl der Pods die Kapazität des Pod-CIDR überschreitet, insbesondere bei hoher Pod-Dichte pro Knoten oder bei großen Bereitstellungen.

Bestimmte Benennungskonventionen für Subnetze:Anhand der Benennung eines Subnetzes in einer Fehlermeldung können Sie feststellen, ob das Problem mit dem IP-Adressbereich des Knotens (wo die Knoten selbst ihre IP-Adresse erhalten) oder dem IP-Adressbereich des Pods (wo die Container in den Pods ihre IP-Adressen erhalten) zusammenhängt.

Ausschöpfung des sekundären Bereichs (Autopilot): In Autopilot-Clustern werden sekundäre Bereiche, die für Pod-IP-Adressen zugewiesen sind, aufgrund von Skalierung oder hoher Pod-Dichte aufgebraucht.

Lösung

Erfassen Sie die folgenden Informationen zu Ihrem Cluster: Name, Steuerungsebenenversion, Betriebsmodus, verknüpfter VPC-Name sowie Subnetzname und CIDR. Notieren Sie sich außerdem die Standard- und zusätzlichen IPv4-Bereiche für Cluster-Pods (einschließlich Namen und CIDRs), ob VPC-natives Traffic-Routing aktiviert ist, und die maximale Anzahl von Pods pro Knoten auf Cluster- und Knotenpool-Ebene (falls zutreffend). Notieren Sie sich alle betroffenen Knotenpools und ihre spezifischen IPv4-Pod-IP-Adressbereiche und Konfigurationen für die maximale Anzahl von Pods pro Knoten, falls sie sich von den clusterweiten Einstellungen unterscheiden. Notieren Sie sich auch die Standard- und benutzerdefinierten Konfigurationen (falls vorhanden) für die maximale Anzahl von Pods pro Knoten in der Knotenpoolkonfiguration.

Problem mit aufgebrauchten IP-Adressen bestätigen

  • Network Intelligence Center: Prüfen Sie im Network Intelligence Center für Ihren GKE-Cluster, ob die Rate der IP-Adresszuweisungen in den Pod-IP-Adressbereichen hoch ist.

    Wenn Sie im Network Intelligence Center eine hohe IP-Adresszuweisungsrate in den Pod-Bereichen feststellen, ist Ihr Pod-IP-Adressbereich aufgebraucht.

    Wenn die IP-Adressbereiche des Pods normale Zuweisungsraten aufweisen, Sie aber weiterhin eine IP-Adressknappheit feststellen, ist der IP-Adressbereich des Knotens wahrscheinlich erschöpft.

  • Prüfen Sie in den Audit-Logs das Feld resourceName in den IP_SPACE_EXHAUSTED-Einträgen und vergleichen Sie es mit den Namen von Subnetzen oder sekundären Pod-IP-Adressbereichen.

  • Prüfen Sie, ob es sich bei dem erschöpften IP-Adressbereich um den IP-Adressbereich des Knotens oder den IP-Adressbereich des Pods handelt.

    Um zu überprüfen, ob es sich bei dem erschöpften IP-Adressbereich um den IP-Adressbereich des Knotens oder den IP-Adressbereich des Pods handelt, prüfen Sie, ob der Wert von resourceName im ipSpaceExhausted-Teil eines IP_SPACE_EXHAUSTED-Logeintrags mit dem Namen des Subnetzes oder dem Namen des sekundären IPv4-Adressbereichs für Pods korreliert, die in dem betroffenen GKE-Cluster verwendet werden.

    Wenn der Wert von resourceName das Format „[Subnet_name]“ hat, ist der IP-Adressbereich des Knotens erschöpft. Wenn der Wert von „resourceName“ das Format „[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]“ hat, ist der IP‑Adressbereich des Pods erschöpft.

So beheben Sie den Ausfall von Pod-IP-Adressen:

  • Größe des vorhandenen Pod-CIDR ändern: Erhöhen Sie die Größe des aktuellen Pod-IP-Adressbereichs. Sie können dem Cluster Pod-IP-Bereiche mit unveränderten Multi-Pod-CIDR hinzufügen.
  • Zusätzliche Subnetze erstellen: Fügen Sie dem Cluster Subnetze mit speziellen Pod-CIDRs hinzu.

Pods pro Knoten reduzieren, um IP-Adressen freizugeben:

So vermeiden Sie, dass die IP-Adressen des Knotens aufgebraucht werden:

  • IP-Adressplanung überprüfen: Der IP-Adressbereich des Knotens muss Ihren Skalierungsanforderungen entsprechen.
  • Neuen Cluster erstellen (falls erforderlich): Wenn der IP-Adressbereich des Knotens stark eingeschränkt ist, erstellen Sie einen Ersatzcluster mit einer geeigneten Größe des IP-Adressbereichs. Weitere Informationen finden Sie unter IP-Bereiche für VPC-native Cluster und IP-Bereichsplanung.

Zusätzliche Diagnosebefehle und Playbooks zur unterbrechungsfreien Fehlerbehebung

Wenn Sie die Fehlerbehebung beschleunigen und die Erschöpfung von IP-Adressen beheben möchten, während Sie gleichzeitig die Cluster-Ausfallzeit minimieren, wenden Sie die folgenden Diagnose- und Betriebs-Playbooks an:

1. Befehlszeilen-Bisektion mit Cloud Logging und Recommender

Führen Sie die folgenden Aufgaben aus, um Probleme mit der Erschöpfung von IP-Adressen über die Befehlszeile zu beheben:

  • Fragen Sie Cloud Logging nach expliziten Ereignissen zur Erschöpfung von IP-Adressen ab: logquery resource.type="k8s_cluster" logName:"logs/container.googleapis.com" ("IP_SPACE_EXHAUSTED" OR "ran out of IPs" OR "wouldn't fit if a new node is added")
  • Fragen Sie die Recommender API nach automatisierten Network Analyzer-Statistiken ab (Auslastung über 80 %): sh gcloud recommender insights list \ --insight-type=google.networkanalyzer.container.ipAddressInsight \ --project=PROJECT_ID --location=GLOBAL
2. Direkte Erweiterung des primären Subnetzes im laufenden Betrieb (bei Erschöpfung der primären IP-Adressen von Knoten)

Im Gegensatz zu sekundären Bereichen können Sie den primären IP-Hostadressbereich eines Subnetzes in Compute Engine live erweitern, ohne Cluster neu erstellen oder Arbeitslasten unterbrechen zu müssen:

gcloud compute networks subnets expand-ip-range SUBNET_NAME \
    --region=REGION \
    --prefix-length=NEW_PREFIX_LENGTH

Wenn Sie beispielsweise ein primäres Subnetz von /24 auf /22 erweitern, erhöht sich die IP-Adresskapazität des primären VM-Hosts von 252 auf 1.020 VM-Knoten.

3. Playbook für die Blau/Grün-Knotenpoolmigration (bei Erschöpfung von Pod-IP-Adressen)

Wenn ein vorhandener Knotenpool auf kleine sekundäre Bereiche oder die große IP-Adresszuweisung der Standardkonfiguration --max-pods-per-node=110 beschränkt ist, migrieren Sie Arbeitslasten zu einem neuen Knotenpool mit CIDRs in der richtigen Größe:

# Step 1: Add a new secondary IPv4 range to your subnet
gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --add-secondary-ranges=NEW_SECONDARY_RANGE_NAME=NEW_CIDR

# Step 2: Register the new Pod range with your GKE cluster
gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --additional-pod-ipv4-ranges=NEW_SECONDARY_RANGE_NAME

# Step 3: Launch a replacement node pool with right-sized --max-pods-per-node
gcloud container node-pools create pool-blue-v2 \
    --cluster=CLUSTER_NAME \
    --region=REGION \
    --max-pods-per-node=32 \
    --pod-ipv4-range=NEW_SECONDARY_RANGE_NAME \
    --enable-autoscaling --min-nodes=2 --max-nodes=60

# Step 4: Gracefully cordon and drain old nodes
kubectl cordon -l cloud.google.com/gke-nodepool=OLD_POOL_NAME
kubectl drain -l cloud.google.com/gke-nodepool=OLD_POOL_NAME --ignore-daemonsets --delete-emptydir-data --force --grace-period=300

# Step 5: Delete old node pool after workloads migrate
gcloud container node-pools delete OLD_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --region=REGION
4. Klasse-E-Bereichsdesign (240.0.0.0/4) mit IP-Masquerading

Wenn in Ihrem Unternehmensnetzwerk der RFC 1918-Adressbereich knapp wird, weisen Sie Ihren sekundären Pod-Bereichen Klasse-E-IPv4-Blöcke (240.0.0.0/4) zu. Diese Blöcke bieten über 268 Millionen Adressen. Aktivieren Sie den GKE-IP-Masquerade-Agenten, damit ausgehender Traffic zu lokalen Datenbanken oder anderen vorhandenen Netzwerkendpunkten mithilfe der primären RFC 1918-Hostadresse des Knotens maskiert wird.

Probleme mit dem Aufbrauchen von IP-Adressen mit gcpdiag beheben

gcpdiag ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Google Cloud -Produkt. Mit dem Tool gcpdiag können Sie Probleme mit Google Cloud-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.

So prüfen Sie die Ursachen für die Ausschöpfung von IP-Adressen in Autopilot- und Standard-GKE-Clustern:
  • Clusterstatus:Prüft den Clusterstatus, wenn eine IP-Adresse aufgebraucht ist.
  • Netzwerkanalysator:In Stackdriver-Logs werden nach Netzwerkanalysator-Logs gesucht, um festzustellen, ob die IP-Adressen von Pods oder Knoten erschöpft sind.
  • Clustertyp:Der Clustertyp wird geprüft und es werden relevante Empfehlungen basierend auf dem Clustertyp angezeigt.

Google Cloud Console

  1. Führen Sie den folgenden Befehl aus und kopieren Sie ihn. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell.
    3. Cloud Console öffnen
  3. Fügen Sie den kopierten Befehl ein.
  4. Führen Sie den Befehl gcpdiag aus, um das Docker-Image gcpdiag herunterzuladen und dann Diagnoseprüfungen durchzuführen. Folgen Sie gegebenenfalls der Anleitung für die Ausgabe, um fehlgeschlagene Prüfungen zu beheben.

Docker

Sie können gcpdiag mit einem Wrapper ausführen, der gcpdiag in einem Docker-Container startet. Docker oder Podman muss installiert sein.

  1. Kopieren Sie den folgenden Befehl und führen Sie ihn auf Ihrer lokalen Workstation aus.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Führen Sie den Befehl gcpdiag aus. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

Verfügbare Parameter für dieses Runbook ansehen

Ersetzen Sie Folgendes:

  • PROJECT_ID: die ID des Projekts, das die Ressource enthält
  • CLUSTER_NAME: Der Name des Ziel-GKE-Clusters in Ihrem Projekt.
  • LOCATION: Die Zone oder Region, in der sich der Cluster befindet.
  • start_time: Die Uhrzeit, zu der das Problem aufgetreten ist.
  • end_time: Die Uhrzeit, zu der das Problem beendet wurde. Stellen Sie die aktuelle Uhrzeit ein, wenn das Problem weiterhin besteht.

Nützliche Flags:

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.

Prüfen, ob Standard-SNAT deaktiviert ist

Verwenden Sie den folgenden Befehl, um den Status von Standard-SNAT zu prüfen:

gcloud container clusters describe CLUSTER_NAME

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Die entsprechende Ausgabe sieht etwa so aus:

networkConfig:
  disableDefaultSnat: true
  network: ...

--disable-default-snat kann ohne --enable-ip-alias nicht verwendet werden.

Diese Fehlermeldung und must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster bedeuten, dass Sie beim Erstellen des Clusters explizit das Flag --disable-default-snat setzen sollten, da Sie in Ihrem privaten Cluster öffentliche IP-Adressen verwenden.

Wenn Fehlermeldungen wie cannot disable default sNAT ... angezeigt werden, kann die Standard-SNAT in Ihrem Cluster nicht deaktiviert werden. Prüfen Sie die Clusterkonfiguration, um dieses Problem zu beheben.

Debugging von Cloud NAT mit deaktiviertem Standard-SNAT

Wenn Sie einen privaten Cluster mit dem Flag --disable-default-snat erstellt und Cloud NAT für den Internetzugriff eingerichtet haben und kein Traffic von Ihren Pods zum Internet angezeigt wird, vergewissern Sie sich, dass der Pod-Bereich in der Cloud NAT-Konfiguration enthalten ist.

Wenn ein Problem mit der Pod-zu-Pod-Kommunikation auftritt, prüfen Sie die iptables-Regeln der Knoten. Achten Sie dabei darauf, dass die Pod-Bereiche nicht durch iptables-Regeln maskiert werden.

Weitere Informationen finden Sie in der Dokumentation zur GKE-IP-Maskierung.

Wenn Sie keinen IP-Masquerading-Agent für den Cluster konfiguriert haben, sorgt GKE automatisch dafür, dass die Pod-zu-Pod-Kommunikation nicht maskiert wird. Wenn jedoch ein IP-Masquerading-Agent konfiguriert ist, werden die Standardregeln für das IP-Masquerading überschrieben. Prüfen Sie, ob im IP-Masquerading-Agent zusätzliche Regeln konfiguriert sind, um die Maskierung der Pod-Bereiche zu ignorieren.

Die Netzwerkkommunikation des Dual-Stack-Clusters funktioniert nicht wie erwartet

Mögliche Ursachen
Die vom GKE-Cluster erstellten Firewallregeln enthalten nicht die zugewiesenen IPv6-Adressen.
Lösung
Sie können die Firewallregel so prüfen:

  1. Prüfen Sie den Inhalt der Firewallregel:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Ersetzen Sie FIREWALL_RULE_NAME durch den Namen der Firewallregel.

    Jeder Dual-Stack-Cluster erstellt eine Firewallregel, durch die Knoten und Pods miteinander kommunizieren können. Der Inhalt der Firewallregel sieht in etwa so aus:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    Der Wert sourceRanges muss mit subnetIpv6CidrBlock übereinstimmen. Der Wert targetTags muss mit den Tags auf den GKE-Knoten übereinstimmen. Um dieses Problem zu beheben, aktualisieren Sie die Firewallregeln mit den ipAllocationPolicy-Blockierungsinformationen des Clusters.

Nächste Schritte