Google Distributed Cloud (GDC) mit Air Gap unterstützt Standardcluster, einen Kubernetes-Cluster mit Self-Service und einem einzelnen Projekt, der von der Anwendungsoperatorgruppe verwaltet wird und 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.
Hinweise
Bevor Sie ein Gateway einrichten, müssen Sie die entsprechenden IAM-Berechtigungen (Identity and Access Management) abrufen, dafür sorgen, dass Ihr Projekt eine geeignete Netzwerkrichtlinie hat, und den Egress aktivieren.
Weitere Informationen finden Sie unter Vorbereitung für 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
Cloud NAT-Gateways können so konfiguriert werden, dass sie ausgehenden Traffic für die Arbeitslasten in Standardclustern auf zwei Arten verarbeiten:
- Gateway auf Projektebene:Ein Gateway, das für den gesamten Arbeitslasttraffic in Clustern innerhalb eines Projekts gilt, einschließlich aller freigegebenen und Standardcluster. Dies ist die Konfiguration, die unter Cloud NAT-Gateway erstellen beschrieben wird.
- Clusterbezogenes Gateway:Ein Gateway, das nur für Arbeitslasten in einem einzelnen angegebenen Standardcluster gilt. Dies ist der auf dieser Seite gezeigte Gatewaytyp.
Diese beiden Methoden sind ausschließlich für Arbeitslasten vorgesehen und gelten nicht für die Knoten, aus denen ein Standardcluster besteht. Wenn Sie Cloud NAT für die Knoten aktivieren möchten, die einen Standardcluster bilden, 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 beliebigen Cloud NAT-Gateways mit Projektbereich.
In diesem Fall konzentrieren wir uns auf die Clusterfilterfunktion für Cloud NAT-Standardcluster und erstellen eine Einrichtung, die dem ersten Szenario ähnelt. Wir geben jedoch den Namen des Standardclusters user-vc-1 an, in dem sich die Endpunkte befinden, über die der Traffic durch das Gateway geleitet wird. Daher ist dieses Gateway 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 das Cloud NAT-Gateway richtig konfiguriert ist, sollte im Feld für den Statuszustand der Zustand des Typs Ready auf true festgelegt 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
Test-Traffic
Testen Sie den Traffic, indem Sie von einem der Pods oder VMs, die dem Gateway im Standardcluster zugewiesen sind, den Befehl curl an einen externen Endpunkt ausgeben. Der empfangende Endpunkt sollte ein Paket von einer der Ausgangs-IPs sehen, die dem Gateway zugeordnet sind. Endpunkte in freigegebenen Clustern mit denselben Labels KÖNNEN keinen ausgehenden Traffic über dieses Gateway senden.
Einschränkungen für clusterspezifische Gateway-Konfigurationen
Arbeitslastlabel-Abgleichsmuster (workloadSelector.labelSelector.workloads.matchLabels) von Gateways mit Clusterbereich DÜRFEN sich NICHT mit den Arbeitslastlabel-Abgleichsmustern anderer Gateways mit Projektbereich überschneiden. Wie unter Einschränkungen für die Cloud NAT-Konfiguration beschrieben, darf sich der workloadSelector.labelSelector.workloads.matchLabels nicht zwischen Gateways im selben Projekt und in derselben Zone überschneiden.
Die anderen Einschränkungen, die unter Einschränkungen für die Cloud NAT-Konfiguration aufgeführt sind, gelten auch für Gateway-Konfigurationen auf Clusterebene.