Fehlerbehebung bei der IP-Adressverwaltung in VPC-Clustern

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

In diesem Dokument erfahren Sie, wie Sie Probleme im Zusammenhang mit der IP-Adress zuweisung, der Netzwerkstabilität und erweiterten Netzwerkfunktionen in VPC-nativen GKE-Clustern beheben.

Diese Informationen richten sich in erster Linie an Plattformadministratoren und -betreiber, die die Netzwerkinfrastruktur des Clusters verwalten. Sie helfen auch Anwendungsentwicklern zu verstehen, wie sich zugrunde liegende Netzwerkeinschränkungen wie ein aufgebrauchter IP-Adress bereich auf ihre Arbeitslasten auswirken können. Entwickler konfigurieren VPCs zwar nicht direkt, aber das Wissen um diese häufigen Probleme hilft ihnen, besser mit Plattformadministratoren und -betreibern zusammenzuarbeiten, um Probleme schneller zu lösen. 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.

Ausschöpfung von 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-Adressauslastung in GKE verwenden, um potenzielle Probleme mit der Ausschöpfung von IP-Adressen zu erkennen und zu beheben.

GKE berechnet die IP-Adressauslastung anhand von Daten aus Network Analyzer-Insights und anderen GKE-Datenquellen. Diese Überwachung 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 untersuchen möchten. Dadurch wird die Seite Details des Clusters geöffnet.

  3. Rufen Sie die IP-Auslastung Seite auf. Verwenden Sie dazu eine der folgenden Methoden:

    • Wählen Sie den Tab Beobachtbarkeit aus und klicken Sie 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. GKE betrachtet alle IP-Adressen im zugewiesenen CIDR Bereich eines Knotens als zugewiesen, unabhängig davon, ob einzelne IP-Adressen Pods zugewiesen sind. Das bedeutet, dass der Prozentsatz den gesamten Pod-Bereich für einen Knoten widerspiegelt und nicht nur die verwendeten IP-Adressen. Wenn Cluster dieselben IP-Adressbereiche verwenden, zeigt der Prozentsatz der Auslastung ihre kombinierte Gesamtauslastung an.

  5. Wenn Sie eine detaillierte Ansicht der IP-Adressnutzung einschließlich CIDR-Bereichen, Subnet informationen und Empfehlungen sehen möchten, klicken Sie auf Details anzeigen.

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

  • Fügen Sie weitere Pod-IPv4-Adressbereiche hinzu, indem Sie nicht zusammenhängende Multi-Pod CIDR verwenden. 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 dem Cluster weitere Subnetze mit zusätzlichen IPv4-Adressbereichen 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 dieser Methode werden weniger IP-Adressen für jeden Knoten reserviert, was dazu beitragen kann, den gesamten IP-Adressverbrauch im Netzwerkbereich Ihres Clusters zu verwalten. Weitere Informationen finden Sie unter Maximale Anzahl von Pods pro Knoten.
  • Wenn Sie nicht genügend IP-Adressbereiche oder RFC 1918-Adressraum haben, sollten Sie Bereiche außerhalb von RFC 1918 in Betracht ziehen (einschließlich des Adressbereichs der Klasse E).

Spezifische Netzwerkprobleme beheben

In den folgenden Abschnitten finden Sie Anleitungen zum Beheben von Problemen im Zusammenhang mit VPC-nativen Clustern. Sie können auch Statistiken zur GKE-IP-Adressauslastung ansehen.

gcpdiag

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 kostenloser 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 Knotenzahl in verkleinerten 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 einer hohen initial_node_count erstellen und dann die Anzahl der Knoten verringern, reserviert GKE weiterhin IP-Adressraum basierend auf dem größeren Wert von initial_node_count des Knotenpools oder der aktuellen Anzahl von Knoten im Knoten pool. In dieser Situation kann es vorkommen, dass der Cluster eine Ausschöpfung der IP-Adressen meldet, obwohl 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.

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 gcpdiag Tool 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-Cluster 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 Blockierungsinformationen des Clusters ipAllocationPolicy.

Nächste Schritte