Fehlerbehebung bei Cloud NAT

In diesem Leitfaden erfahren Sie, wie Sie herausfinden, warum Ihre Arbeitslasten (Pods oder VMs) mit Cloud NAT nicht auf externe Netzwerke zugreifen können. Als Entwickler interagieren Sie hauptsächlich mit der CloudNatGateway-Ressource. Der Status dieser Ressource ist Ihre primäre Quelle für die Fehlersuche.

Hinweise

Um Fehler bei einer Cloud NAT-Konfiguration zu beheben, benötigen Sie Folgendes:

  • Die erforderlichen Identitäts- und Zugriffsrollen. Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen eine oder beide der folgenden Rollen zuzuweisen:
    • Cloud NAT-Betrachter (cloud-nat-viewer): Diese Rolle bietet schreibgeschützten Zugriff auf Cloud NAT-Ressourcen. Mit dieser Rolle können Sie mit der Diagnose des Problems beginnen.
    • Cloud NAT Developer (cloud-nat-developer): Diese Rolle bietet die erforderlichen Berechtigungen für Anwendungsbetreiber zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) von Cloud NAT-Objekten in den zugewiesenen Projekten. Mit dieser Rolle können Sie viele der auf dieser Seite beschriebenen Korrekturen vornehmen.
    • Für einige spezifische Diagnosemaßnahmen und Korrekturen sind möglicherweise zusätzliche Rollen erforderlich.

Erste Diagnose

Bevor Sie sich mit Fehlercodes befassen, sollten Sie prüfen, ob die grundlegenden Ressourcen vorhanden und erreichbar sind.

Befehl:

kubectl get cloudnatgateway GATEWAY_NAME -n PROJECT_NAMESPACE -o yaml

Ersetzen Sie Folgendes:

  • GATEWAY_NAME: Name der CloudNatGateway-Ressource.
  • PROJECT_NAMESPACE: Der Namespace Ihres Projekts.

Statusbedingungen prüfen:Ein fehlerfreies Gateway muss alle der folgenden Bedingungen auf True gesetzt haben:

  • Ready: Globaler Systemdiagnosestatus.
  • SubnetsReady: Die IP-Pool-Konfiguration ist gültig.
  • PerimeterConfigurationReady: Die Upstream-Netzwerkinfrastruktur ist konfiguriert.
  • EgressRoutesReady: Die Routingrichtlinien für Ihre Pods sind aktiv.

Wenn einer dieser Werte False ist, prüfen Sie die Felder reason und message in der Statusausgabe und sehen Sie in den Tabellen in den folgenden Abschnitten nach.

Referenz für Fehlercodes und Problembehebung

Die von kubectl get cloudnatgateway zurückgegebenen Fehlercodes lassen sich in drei Hauptkategorien einteilen.

Subnetzfehler (SubnetsReady ist „False“)

Diese Bedingung weist auf Probleme mit dem dem Gateway zugewiesenen IP-Adresspool hin.

Fehlercode Bedeutung Schritte zur Abhilfe
CloudNATSelectorFieldOverlapsCode Konfigurationskonflikt: Die workloadSelector dieses Gateways entspricht den gleichen Arbeitslasten wie bei einem anderen Gateway in Ihrem Projekt. Der Traffic kann nicht deterministisch weitergeleitet werden.
  1. Alle Cloud NAT-Gateways in Ihrem Projekt auflisten: kubectl get cloudnatgateway
  2. Vergleichen Sie die workloadSelector dieses Gateways mit anderen.
  3. Ändern Sie die Labels so, dass kein einzelner Pod/keine einzelne VM von mehr als einem Gateway ausgewählt wird.
CloudNATSubnetRefsFieldInvalidCode

Ungültiges Subnetz. Das in subnetRefs angegebene Subnetz ist nicht nutzbar. Häufige Gründe:

  • Das Subnetz ist nicht vorhanden.
  • Das Subnetz hat nicht den Status Ready.
  • Das Subnetz gehört nicht zum Typ „Leaf“.
  1. Prüfen Sie, ob das Subnetz vorhanden ist: kubectl get subnet <SUBNET_NAME>
  2. Prüfen Sie, ob der Subnetzstatus Ready lautet.
  3. Das Subnetz type muss Leaf sein. Cloud NAT kann keine Root- oder Loopback-Subnetze verwenden.
CloudNATSubnetAlreadyInUseCode Subnetzkonflikt: Das von Ihnen angeforderte Subnetz gehört bereits einem anderen Cloud NAT-Gateway. Ein Subnetz kann jeweils nur mit einem Gateway verbunden sein.
  1. Wählen Sie ein anderes Subnetz für dieses Gateway aus.
  2. Alternativ können Sie das Subnetz zuerst vom anderen Gateway entfernen.
UNETAPIServerErrorCode Systemfehler Der Controller kann nicht mit dem API-Server kommunizieren, um Subnetze zu validieren. Maßnahme:Wahrscheinlich handelt es sich dabei um ein vorübergehendes Plattformproblem. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Plattformadministrator.

Fehler bei der Perimeterkonfiguration (PerimeterConfigurationReady ist „False“)

Diese Bedingung spiegelt den Status der Perimeter-Gateways wider.

Fehlercode Bedeutung Schritte zur Abhilfe
NET-E0305 Konfigurationskonflikt: Wie oben. Überlappende Selektoren verhindern, dass das System die richtige Routinggruppe berechnet.
  1. Alle Cloud NAT-Gateways in Ihrem Projekt auflisten: kubectl get cloudnatgateway
  2. Vergleichen Sie die workloadSelector dieses Gateways mit anderen.
  3. Ändern Sie die Labels so, dass kein einzelner Pod/keine einzelne VM von mehr als einem Gateway ausgewählt wird.
NET-E0301 Ressourcenerschöpfung / Knotenausfall: Das System hat die Konfiguration erstellt, konnte aber keine gesunden physischen Knoten für die Zuweisung Ihrer Egress-IPs finden. Das bedeutet in der Regel, dass entweder keine IP-Adressen mehr im Subnetz verfügbar sind oder die Gateway-Knoten ausgefallen sind.
  1. Prüfen Sie die [Subnetznutzung](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/subnets-overview). Ist er voll?
  2. Wenn das Subnetzwerk kostenlose IPs hat und Ready ist, deutet dies auf einen Infrastrukturfehler auf Plattformseite hin (z.B. sind keine fehlerfreien Gateway-Knoten verfügbar). Aktion: Wenden Sie sich an den Plattformadministrator.
NET-E0001 Systemfehler Die Kommunikation mit dem Controller ist fehlgeschlagen. Maßnahme:Wenden Sie sich an den Plattformadministrator.

Fehler bei der Route für ausgehenden Traffic (EgressRoutesReady ist „False“)

Diese Bedingung spiegelt den Status der Routingrichtlinien im Cluster wider.

Fehlercode Bedeutung Schritte zur Abhilfe
NET-E0305 Konfigurationskonflikt: Wie oben.
  1. Alle Cloud NAT-Gateways in Ihrem Projekt auflisten: kubectl get cloudnatgateway
  2. Vergleichen Sie die workloadSelector dieses Gateways mit anderen.
  3. Ändern Sie die Labels so, dass kein einzelner Pod/keine einzelne VM von mehr als einem Gateway ausgewählt wird.
NET-E0304 Fehler bei der Programmierung. Das System konnte die Routingregeln (BPF) für Ihre spezifischen Gateway-IPs nicht programmieren.

Aktion:Dies ist ein interner Programmierfehler oder eine Statusinkonsistenz.

  1. Nehmen Sie eine einfache Änderung am Gateway vor, z.B. bearbeiten Sie ein Label, um eine Abstimmung auszulösen.
  2. Wenn das Problem weiterhin besteht, wenden Sie sich an den Plattformadministrator.

Weitere häufig auftretende Probleme

Wenn der Gateway-Status Ready: True ist, aber die Verarbeitung von Traffic weiterhin fehlschlägt, prüfen Sie die folgenden häufigen Fehlkonfigurationen:

Fehlende Berechtigung auf Projektebene

Ihr Projekt muss explizit für ausgehenden Traffic autorisiert sein.

  • Prüfen:Hat Ihre Projektressource das Label networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true"?
  • Lösung:Bitten Sie Ihren Projektadministrator, dieses Label anzuwenden.

VM-Annotation fehlt (nur Virtual Machines)

VMs umgehen den Standardpfad für ausgehenden Pod-Traffic und benötigen explizite Anweisungen zur Verwendung von Cloud NAT.

  • Prüfen:Hat das VirtualMachineExternalAccess-Objekt (VMEA) für Ihre VM die Annotation egress.networking.gke.io/use-cloud-nat: "true"?
  • Korrektur:Fügen Sie dem VMEA-Objekt die Annotation hinzu.

Ausgehender Traffic von Knoten in Standardclustern

Wenn Sie einen Standardcluster ausführen, benötigen die Knoten selbst die Berechtigung für ausgehenden Traffic.

  • Prüfen:Hat das Objekt Cluster das Label cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true"?
  • Lösung:Bitten Sie Ihren Plattformadministrator, das Clusterobjekt zu labeln.

Kollision zwischen Standard-NAT für ausgehenden Traffic und Cloud NAT

Ein häufiger Konfigurationsfehler tritt auf, wenn eine Arbeitslast für die Verwendung des alten Standard-NAT-Mechanismus für ausgehenden Traffic konfiguriert ist und gleichzeitig von einem Cloud NAT-Gateway ausgewählt wird. Diese Kombination führt zu einem Konflikt, bei dem die Datenebene widersprüchliche Routinganweisungen erhält, was zu Paketverlusten oder einem nicht deterministischen Routingverhalten führt.

Pod-Kollisionen diagnostizieren

Für Pods wird die Standard-NAT für ausgehenden Traffic in der Regel durch Hinzufügen eines bestimmten Labels aktiviert. Ein Pod kann dieses Label nicht haben, wenn er auch auf ein Cloud NAT-Gateway ausgerichtet ist.

  1. Ziel-Pod identifizieren:Rufen Sie die Labels des Pods ab, bei dem Verbindungsprobleme auftreten.

    kubectl get pod <POD_NAME> -n <NAMESPACE> --show-labels

  2. Nach in Konflikt stehenden Labels suchen:

    • Cloud NAT-Auswahl:Stimmen die Labels des Pods mit dem workloadSelector eines CloudNatGateway im Namespace überein?
    • Standard-Egress-Label:Hat der Pod das Label egress.networking.gke.io/enabled: "true"?

    Bedingung:Wenn BEIDE zutreffen, liegt eine Kollision vor.

  3. Lösung:Entfernen Sie das alte Standardlabel für ausgehenden Traffic aus dem Pod (oder dem übergeordneten Deployment/StatefulSet), damit Cloud NAT die exklusive Steuerung übernehmen kann.

VM-Kollisionen diagnostizieren

Bei virtuellen Maschinen ist der Mechanismus anders. VMs mit VirtualMachineExternalAccess-Objekten (VMEA) sind oft für den Standardzugriff konfiguriert. Um Cloud NAT zu verwenden, müssen sie dies explizit aktivieren, indem sie eine Annotation hinzufügen, um den Standardpfad zu deaktivieren und den Cloud NAT-Pfad zu aktivieren.

  1. VMEA identifizieren:Suchen Sie das VirtualMachineExternalAccess-Objekt, das der VM zugeordnet ist.

    kubectl get vmea -n <NAMESPACE>

  2. Auf fehlende Annotationen prüfen:

    • Cloud NAT-Auswahl:Stimmen die Labels der VM mit einem CloudNatGateway überein?
    • Opt-in-Anmerkung:Prüfen Sie die VMEA auf die Anmerkung egress.networking.gke.io/use-cloud-nat: "true".

    Bedingung:Wenn die VM mit einem Gateway übereinstimmt, aber diese Anmerkung FEHLT, kommt es zu einem Konflikt mit dem standardmäßigen System für ausgehenden Traffic.

  3. Lösung:Fügen Sie dem VMEA-Objekt die Annotation hinzu.

    kubectl annotate vmea <VMEA_NAME> -n <NAMESPACE> egress.networking.gke.io/use-cloud-nat="true"