Cloud NAT-Gateways für Standardcluster

Google Distributed Cloud (GDC) air-gapped unterstützt Standardcluster, einen von der Gruppe der Anwendungs operatoren verwalteten Kubernetes-Cluster mit einem einzelnen Projekt und Self-Service, der mehr Flexibilität für benutzerdefinierte Arbeitslasten bietet. Auf dieser Seite wird beschrieben, wie Sie Cloud NAT für Standardcluster einrichten. Außerdem werden einige Einschränkungen für NAT-Konfigurationen für diesen Clustertyp beschrieben.

Vorbereitung

Bevor Sie ein Gateway einrichten, müssen Sie die entsprechenden Berechtigungen für Identity and Access Management (IAM) erhalten, sicherstellen, dass Ihr Projekt eine geeignete Netzwerkrichtlinie hat, und den ausgehenden Traffic aktivieren.

Weitere Informationen finden Sie unter Vorbereitung auf die Verwendung von Cloud NAT.

Das Cloud NAT-Gateway verwendet externe leaf-Subnetze als Eingaben. Weitere Informationen zum Konfigurieren externer Subnetze für Cloud NAT finden Sie unter Externe Subnetze für Cloud NAT erstellen.

Übersicht

Diagramm einer Cloud NAT-Gateway-Einrichtung für einen Standardcluster

Cloud NAT-Gateways können so konfiguriert werden, dass sie ausgehenden Traffic für die Arbeitslasten verarbeiten, die auf Standardclustern ausgeführt werden. Es gibt zwei Möglichkeiten:

  • Gateway mit Projektbereich:Ein Gateway, das für den gesamten Arbeitslasttraffic auf Clustern in einem Projekt gilt, einschließlich aller freigegebenen und Standardcluster. Dies ist die Konfiguration, die unter Cloud NAT-Gateway erstellen beschrieben wird.
  • Gateway mit Clusterbereich:Ein Gateway, das nur für Arbeitslasten in einem einzelnen angegebenen Standardcluster gilt. Dieser Gateway-Typ wird auf dieser Seite veranschaulicht.

Diese beiden Methoden gelten ausschließlich für Arbeitslasten und nicht für die Knoten, aus denen ein Standardcluster besteht. Wenn Sie Cloud NAT für die Knoten aktivieren möchten, aus denen ein Standardcluster besteht, fügen Sie dem Standardclusterobjekt das Label cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" hinzu.

Cloud NAT-Gateway erstellen

Das Erstellen eines Gateways für einen Standardcluster ist dasselbe wie das Erstellen eines Cloud NAT-Gateways mit Projektbereich.

In diesem Fall konzentrieren wir uns auf die Clusterfilterfunktion für Cloud NAT für Standardcluster und erstellen eine ähnliche Einrichtung wie im ersten Szenario. Wir geben jedoch den Namen des Standardclusters user-vc-1 an, in dem sich die Endpunkte befinden, die Traffic über das Gateway weiterleiten. Dadurch wird der Bereich dieses Gateways auf diesen bestimmten Cluster beschränkt.

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:    # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:           # Mutable
  - subnet-1
  - subnet-2

Mit dieser Konfiguration werden alle Arbeitslasten mit den Labels app: aa in allen Namespaces im Standardcluster user-vc-1 ausgewählt.

Status des Gateways prüfen

Prüfen Sie den Status der Gateways mit dem folgenden kubectl-Befehl.

export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"

Wenn die Konfiguration korrekt ist, sollte im Feld für die Statusbedingung des Cloud NAT-Gateways die Bedingung vom Typ Ready auf true gesetzt sein und die Subnetze als OK gekennzeichnet sein, wie in der folgenden Beispielausgabe zu sehen ist:

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:       # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:       # Mutable
  - subnet-1
  - subnet-2
status:
  conditions:
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: SubnetsReady
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: PerimeterConfigurationReady
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: EgressRoutesReady
  subnets:
  - name: subnet-1
    status: OK
  - name: subnet-2
    status: OK

Traffic testen

Testen Sie den Traffic, indem Sie einen curl-Befehl von einem der Pods oder VMs, die dem Gateway im Standardcluster zugewiesen sind, an einen externen Endpunkt senden. Der empfangende Endpunkt sollte ein Paket von einer der ausgehenden IPs sehen, die dem Gateway zugeordnet sind. Endpunkte in freigegebenen Clustern mit denselben Labels können ausgehenden Traffic **nicht** über dieses Gateway weiterleiten.

Einschränkungen für clusterspezifische Gateway-Konfigurationen

Die Arbeitslastlabel-Übereinstimmungen (workloadSelector.labelSelector.workloads.matchLabels) von Gateways mit Clusterbereich dürfen sich NICHT mit den Arbeitslastlabel-Übereinstimmungen von anderen Gateways mit Projektbereich ÜBERSCHNEIDEN. Wie unter Einschränkungen für die Cloud NAT Konfiguration beschrieben, dürfen sich die workloadSelector.labelSelector.workloads.matchLabels nicht zwischen Gateways im selben Projekt und in derselben Zone überschneiden.

Die anderen unter Einschränkungen für die Cloud NAT Konfiguration aufgeführten Einschränkungen gelten auch für Gateway-Konfigurationen mit Clusterbereich.