Fehlerbehebung bei der IP-Adressverwaltung in VPC-Clustern

Auf dieser Seite erfahren Sie, wie Sie Probleme mit der IP-Adressverwaltung in VPC-Clustern in Google Kubernetes Engine (GKE) beheben.

Auf dieser Seite finden Plattformadministratoren und ‑betreiber Informationen zur Diagnose und Behebung von Problemen wie der Erschöpfung von IP-Adressen für Knoten und Pods, zur Fehlerbehebung bei Netzwerkkonfigurationsfehlern, die Clusteroperationen blockieren (z. B. Bereichskonflikte), zur Verwaltung von CIDR-Bereichen für IP-Adressen und zur korrekten Konfiguration von Funktionen wie Standard-SNAT, Cloud NAT und Dual-Stack-Netzwerken.

Auf dieser Seite erfahren Anwendungsentwickler auch, wie sich zugrunde liegende Netzwerkbeschränkungen wie der erschöpfte IP-Adressraum auf ihre Arbeitslasten auswirken können, was zu Problemen wie dem fehlgeschlagenen Planen von Pods führt. Entwickler konfigurieren VPCs zwar nicht direkt, aber wenn sie diese häufigen Probleme kennen, können sie besser mit Plattformadministratoren und ‑betreibern zusammenarbeiten, um Probleme schneller zu beheben. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir inGoogle Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Problem mit aufgebrauchten 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 die Überwachung der IP-Adressennutzung in GKE verwenden, um potenzielle Probleme mit der Erschöpfung von IP-Adressen zu erkennen und zu beheben.

Die IP-Adressauslastung wird in GKE anhand von Daten aus Network Analyzer-Insights und anderen GKE-Datenquellen berechnet. Diese Überwachung ist für alle VPC-nativen Cluster verfügbar.

So rufen Sie die IP-Adressennutzung 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 untersuchen möchten. Dadurch wird die Seite Details des Clusters geöffnet.

  3. Rufen Sie die Seite IP-Auslastung 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-Nutzung.

    • 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 sehen Sie den Prozentsatz der zugewiesenen IP-Adressen im IP-Adressbereich Ihres Pods. In GKE werden alle IP-Adressen im zugewiesenen CIDR-Bereich eines Knotens als zugewiesen betrachtet, unabhängig davon, ob einzelne IP-Adressen Pods zugewiesen sind. Das 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, sehen Sie deren kombinierte Gesamtauslastung.

  5. Wenn Sie eine detaillierte Ansicht der IP-Adressnutzung aufrufen möchten, einschließlich CIDR-Bereichen, Subnetzinformationen und Empfehlungen, klicken Sie auf Details einblenden.

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 weitere Pod-IPv4-Adressbereiche mit nicht zusammenhängenden Multi-Pod-CIDRs hinzu. Mit dieser Funktion können Sie Ihren Pods weitere IPv4-Adressen hinzufügen, ohne Ihren Cluster neu erstellen oder neue Subnetze konfigurieren zu müssen.
  • Fügen Sie dem Cluster weitere Subnetze mit zusätzlichen IPv4-Adressbereichen hinzu. Mit dieser Funktion können für neue Knotenpools IP-Adressen aus neu hinzugefügten Subnetzen verwendet werden.
  • 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 Bereiche außerhalb von RFC 1918 (einschließlich des Adressbereichs der Klasse E) in Betracht ziehen.

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 freier 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.

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.

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-Maskierungs-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-Maskierungs-Agent konfiguriert ist, werden die Standardregeln für die IP-Maskierung überschrieben. Prüfen Sie, ob im IP-Maskierungs-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 Firewallregel mit den ipAllocationPolicy-Blockierungsinformationen des Clusters.

Nächste Schritte