Fehlerbehebung bei der IP-Adressverwaltung in VPC-Clustern

Dieser Abschnitt enthält 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' is exhausted.
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 --project=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 --project=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:

  • --project: Der PROJECT_ID
  • --universe-domain: Die Domain Trusted Partner Sovereign Cloud, auf der die Ressource gehostet wird
  • --parameter oder -p: Runbook-Parameter

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 Firewallregeln mit den ipAllocationPolicy-Blockierungsinformationen des Clusters.

Der Private Service Connect-Endpunkt wird beim Löschen des Clusters möglicherweise weitergegeben

Symptome

In Ihrem Private Service Connect-basierten Cluster wird unter „Private Service Connect“ kein verbundener Endpunkt angezeigt.

Sie können das Subnetz oder VPC-Netzwerk, dem der Endpunkt zugewiesen ist, nicht löschen. Es wird eine Fehlermeldung wie die folgende angezeigt:

projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Mögliche Ursachen

In GKE-Clustern, die Private Service Connect verwenden, wird ein Private Service Connect-Endpunkt mithilfe einer Weiterleitungsregel bereitgestellt, die eine interne IP-Adresse für den Zugriff auf die Steuerungsebene des Clusters im Netzwerk der Steuerungsebene zuweist. Um die Kommunikation zwischen der Steuerungsebene und den Knoten mit Private Service Connect zu schützen, hält GKE den Endpunkt unsichtbar. Er ist weder in der Google Cloud Console noch in der gcloud CLI zu sehen.

Lösung

Führen Sie die folgenden Schritte aus, um zu verhindern, dass der Private Service Connect-Endpunkt vor dem Löschen des Clusters preisgegeben wird:

  1. Weisen Sie dem GKE-Dienstkonto die Rolle Kubernetes Engine Service Agent role zu.
  2. Die Berechtigungen compute.forwardingRules.* und compute.addresses.* dürfen dem GKE-Dienstkonto nicht ausdrücklich verweigert werden.

Wenn der Private Service Connect-Endpunkt gehackt wurde, wenden Sie sich an den Support.

Nächste Schritte