Cloud NAT-Gateways mit Verbindungszeitlimits

Vorbereitung

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.

Cloud NAT-Gateways mit Verbindungszeitlimits erstellen und verwalten

In diesem Dokument wird beschrieben, wie Sie Cloud NAT-Gateways mit Verbindungstimeouts erstellen und verwalten. In diesem Anwendungsfall wird eine Einrichtung ähnlich dem ersten Szenario erstellt, aber es werden Zeitlimits für Verbindungen angegeben, die über das Cloud NAT-Gateway hergestellt werden.

Das folgende Diagramm zeigt ein Beispiel für die Einrichtung eines Gateways mit mehreren ausgehenden IP-Adressen: Diagramm mit einem Cloud NAT-Gateway mit mehreren Egress-IPs, das mit zwei Subnetzen verbunden ist.

Standardmäßig haben ausgehende Verbindungen, die über ein Cloud NAT-Gateway erstellt werden, die folgenden Zeitlimits. Sie können sie bei Bedarf manuell konfigurieren.

Zeitlimit Standard (Sekunden)
Nicht-TCP-Verbindungen 60
Inaktive TCP-Verbindungen 8000
Abbau von TCP-Verbindungen 10
TCP-Verbindungsaufbau 60

Cloud NAT-Gateway mit Zeitlimits erstellen

In diesem Beispiel wird ein einzelnes Cloud NAT-Gateway mit Verbindungstimeouts definiert. Wie im vorherigen Beispiel werden mit dieser Konfiguration die Egress-IPs aus subnet-1 und subnet-2 dem ausgehenden Traffic von Endpunkten mit dem Label app:aa zugewiesen. Außerdem werden mit dieser Konfiguration die Standardzeitüberschreitungen mit benutzerdefinierten Werten überschrieben.

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:   # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
  subnetRefs:          # Mutable
  - subnet-1
  - subnet-2
  connectionOptions:   # Mutable
    nonTCPTimeoutSeconds: 10            # All non-TCP connections. 60 by default
    tcpTimeoutSeconds: 900              # Established TCP connections. 8000 by default
    tcpTeardownTimeoutSeconds: 10       # TCP connection teardown. 10 by default
    tcpEstablishmentTimeoutSeconds: 10  # TCP connection establishment. 60 by default

Der Status der Gateways kann mit dem folgenden kubectl-Befehl geprüft werden.

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, wird im Feld „Statusbedingung“ die Bedingung vom Typ Ready mit dem Wert true angezeigt und die Subnetze sind als OK gekennzeichnet, 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
  subnetRefs:         # Mutable
  - subnet-1
  - subnet-2
  connectionOptions:   # Mutable
    nonTCPTimeoutSeconds: 10
    tcpTimeoutSeconds: 900
    tcpTeardownTimeoutSeconds: 10
    tcpEstablishmentTimeoutSeconds: 10
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

Wenn Sie prüfen möchten, ob die neue Konfiguration wirksam ist, können Sie den Status der Gateways prüfen.