Fehlerbehebung bei Cloud NAT

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

Hinweis

Für die Fehlerbehebung bei einer Cloud NAT-Konfiguration benötigen Sie Folgendes:

  • Die erforderlichen Identitäts- und Zugriffsrollen. Bitten Sie Ihren IAM-Projektadministrator, Ihnen eine oder beide der folgenden Rollen zuzuweisen:
    • Cloud NAT-Betrachter (cloud-nat-viewer): Diese Rolle bietet Lesezugriff 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 Anwendungsoperatoren, um Cloud NAT-Objekte in ihren zugewiesenen Projekten zu erstellen, zu lesen, zu aktualisieren und zu löschen (CRUD). Mit dieser Rolle können Sie viele der auf dieser Seite beschriebenen Korrekturen vornehmen.
    • Für einige spezifische Diagnosemaßnahmen und Fehlerbehebungen 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: Bei einem fehlerfreien Gateway müssen alle folgenden Bedingungen auf True gesetzt sein:

  • Ready: Globaler Integritätsstatus.
  • SubnetsReady: Die IP-Pool-Konfiguration ist gültig.
  • PerimeterConfigurationReady: Die vorgelagerte 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 sich die Tabellen in den folgenden Abschnitten an.

Fehlercode-Referenz und -Behebung

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

Subnetzfehler (SubnetsReady ist „False“)

Dieser Zustand weist auf Probleme mit dem IP-Adresspool hin, der dem Gateway zugewiesen ist.

Fehlercode Bedeutung Schritte zur Fehlerbehebung
CloudNATSelectorFieldOverlapsCode Konfigurationskonflikt. Der workloadSelector dieses Gateways stimmt mit denselben Arbeitslasten wie ein anderes Gateway in Ihrem Projekt überein. Der Traffic kann nicht deterministisch weitergeleitet werden.
  1. Listen Sie alle Cloud NAT-Gateways in Ihrem Projekt auf: kubectl get cloudnatgateway
  2. Vergleichen Sie die workloadSelector dieses Gateways mit anderen.
  3. Ändern Sie die Labels so, dass kein einzelner Pod bzw. keine einzelne VM von mehr als einem Gateway ausgewählt wird.
CloudNATSubnetRefsFieldInvalidCode

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

  • Subnetz ist nicht vorhanden.
  • Subnetz befindet sich nicht im Status Ready.
  • Das Subnetz ist nicht vom 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. Achten Sie darauf, dass das Subnetz type den Typ Leaf hat. 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 an ein Gateway angehängt werden.
  1. Wählen Sie ein anderes Subnetz für dieses Gateway aus.
  2. Oder entfernen Sie das Subnetz zuerst aus dem anderen Gateway.
UNETAPIServerErrorCode Systemfehler. Der Controller kann nicht mit dem API-Server kommunizieren, um Subnetze zu validieren. Maßnahme: Wahrscheinlich handelt es sich um ein vorübergehendes Problem mit der Plattform. 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 Fehlerbehebung
NET-E0305 Konfigurationskonflikt. (Wie oben). Sich überschneidende Selektoren verhindern, dass das System die richtige Routinggruppe berechnet.
  1. Listen Sie alle Cloud NAT-Gateways in Ihrem Projekt auf: kubectl get cloudnatgateway
  2. Vergleichen Sie die workloadSelector dieses Gateways mit anderen.
  3. Ändern Sie die Labels so, dass kein einzelner Pod bzw. keine einzelne VM von mehr als einem Gateway ausgewählt wird.
NET-E0301 Ressourcenerschöpfung/Knotenausfall. Die Konfiguration wurde erstellt, aber Ihre IP-Adressen für ausgehenden Traffic konnten keinem fehlerfreien physischen Knoten zugewiesen werden. Das bedeutet in der Regel, dass entweder das Subnetz keine IP-Adressen mehr hat oder die Gateway-Knoten ausgefallen sind.
  1. Prüfen Sie die Nutzung Ihres [Subnetzes](/distributed-cloud/hosted/docs/1.16/gdcag/platform/pa-user/subnets-overview). Ist er voll?
  2. Wenn das Subnetz verfügbare IP-Adressen hat und Ready ist, deutet dies auf einen plattformseitigen Infrastrukturfehler hin (z.B. keine betriebsbereiten Gateway-Knoten verfügbar). Maßnahme: Wenden Sie sich an den Plattformadministrator.
NET-E0001 Systemfehler. Fehler bei der Kommunikation mit dem Controller. Maßnahme: Wenden Sie sich an den Plattformadministrator.

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

Diese Bedingung spiegelt den Status der Routingrichtlinien im Cluster wider.

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

Maßnahme: Dies ist ein interner Programmierfehler oder eine Statusinkonsistenz.

  1. Versuchen Sie, eine einfache Aktualisierung am Gateway vorzunehmen (z.B. ein Label zu bearbeiten), um einen Abgleich 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 der 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.

Fehlende VM-Annotation (nur virtuelle Maschinen)

VMs umgehen den Standardpfad für ausgehenden Pod-Traffic und benötigen eine explizite Anweisung, um Cloud NAT zu verwenden.

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

Ausgehender Traffic von Standardclusterknoten

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

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 NAT-Mechanismus für ausgehenden Standard-Traffic konfiguriert ist, während sie gleichzeitig von einem Cloud NAT-Gateway ausgewählt wird. Diese Kombination führt zu einer Kollision, bei der die Datenebene widersprüchliche Routinganweisungen erhält, was zu Paketverlusten oder nicht deterministischem Routingverhalten führt.

Pod-Kollisionen diagnostizieren

Für Pods wird die Standard-NAT für ausgehenden Traffic normalerweise durch Hinzufügen eines bestimmten Labels aktiviert. Ein Pod kann dieses Label nicht haben, wenn er gleichzeitig von einem Cloud NAT-Gateway als Ziel verwendet wird.

  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. Auf in Konflikt stehende Labels prüfen:

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

    Bedingung: Wenn BEIDE Bedingungen erfüllt sind, liegt eine Kollision vor.

  3. Lösung: Entfernen Sie das Legacy-Standardlabel für ausgehenden Traffic vom Pod (oder seinem übergeordneten Deployment/StatefulSet), damit Cloud NAT die exklusive Kontrolle übernehmen kann.

VM-Kollisionen diagnostizieren

Bei virtuellen Maschinen ist der Mechanismus anders. VMs mit VirtualMachineExternalAccess-Objekten (VMEA) sind häufig für den Standardzugriff konfiguriert. Wenn Sie Cloud NAT verwenden möchten, müssen Sie dies explizit aktivieren. Fügen Sie dazu eine Annotation hinzu, 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 Annotation prüfen:

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

    Bedingung: Wenn die VM mit einem Gateway übereinstimmt, aber NICHT diese Annotation hat, kollidiert der Traffic mit dem Standard-System für ausgehenden Traffic.

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

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