Standard-NAT für ausgehenden Traffic für Projekte verwalten

Auf dieser Seite wird die jetzt eingestellte NAT-Konfiguration für ausgehenden Traffic für das Standardprojekt beschrieben, mit der Arbeitslasten Verbindungen außerhalb der Organisation herstellen können. Auf dieser Seite finden Sie auch eine Anleitung zur Migration zur empfohlenen Lösung Cloud NAT.

Übersicht

Auf dieser Seite werden die Maßnahmen beschrieben, die Sie für die Egress-Verbindung auf einer VM oder einem Pod in einem Projekt ergreifen müssen, damit Arbeitslasten die Organisation verlassen können. Dabei wird die (eingestellte) NAT-Konfigurationsoption für den Standard-Egress des Projekts verwendet.

In dieser Anleitung wird beschrieben, wie Sie Bereitstellungen ein erforderliches Label hinzufügen, um ausgehenden Traffic explizit zu aktivieren und Arbeitslasten die Kommunikation außerhalb der Organisation zu ermöglichen.

Standardmäßig verhindert Google Distributed Cloud (GDC) mit Air Gap, dass Arbeitslasten in einem Projekt die Organisation verlassen. Arbeitslasten können die Organisation verlassen, wenn Ihr Plattformadministrator den Schutz vor Datenexfiltration für das Projekt deaktiviert hat. PAs können das Label networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" an das Projekt anhängen. Zusätzlich zum Deaktivieren des Schutzes vor Datenexfiltration muss der Application Operator (AO) dem Pod-Arbeitslast das Label egress.networking.gke.io/enabled: true hinzufügen, um die Egress-Konnektivität für diesen Pod zu aktivieren. Wenn Sie eine bekannte IP-Adresse für das Projekt zuweisen und verwenden, wird eine Quell-NAT (Network Address Translation) für den ausgehenden Traffic der Organisation ausgeführt.

Sie können ausgehende Verbindungen von Arbeitslasten in einem Pod oder einer VM verwalten.

Ausgehenden Traffic von Arbeitslasten in einem Pod verwalten

Wenn Sie Arbeitslasten in einem Pod für die Egress-Konnektivität konfigurieren möchten, müssen Sie zuerst dafür sorgen, dass der Schutz vor Daten-Exfiltration für das Projekt deaktiviert ist. Achten Sie dann darauf, dass dem Pod das Label egress.networking.gke.io/enabled: true hinzugefügt wird. Wenn Sie ein Konstrukt auf höherer Ebene wie Deployment oder Daemonset verwenden, um Gruppen von Pods zu verwalten, müssen Sie das Pod-Label in diesen Spezifikationen konfigurieren.

Im folgenden Beispiel wird gezeigt, wie Sie ein Deployment aus der zugehörigen Manifestdatei erstellen. Die Beispieldatei enthält den Wert egress.networking.gke.io/enabled: true im Feld labels, um ausgehenden Traffic aus dem Projekt explizit zu aktivieren. Dieses Label wird jedem Pod im Deployment hinzugefügt und ermöglicht es Arbeitslasten in den Pods, die Organisation zu verlassen.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
        egress.networking.gke.io/enabled: true
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
EOF

Ersetzen Sie Folgendes:

  • USER_CLUSTER_KUBECONFIG: Die kubeconfig-Datei für den Nutzercluster, in dem Sie Containerarbeitslasten bereitstellen.

  • DEPLOYMENT_NAME: Die kubeconfig-Datei für den Nutzercluster, in dem Sie Containerarbeitslasten bereitstellen.

  • APP_NAME: Der Name der Anwendung, die im Deployment ausgeführt werden soll.

  • NUMBER_OF_REPLICAS: Die Anzahl der replizierten Pod-Objekte, die vom Deployment verwaltet werden.

  • CONTAINER_NAME: Der Name des Containers.

  • CONTAINER_IMAGE: Der Name des Container-Images. Sie müssen den Container Registry-Pfad und die Version des Images angeben, z. B. REGISTRY_PATH/hello-app:1.0.

Beispiel:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
        egress.networking.gke.io/enabled: true
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0

Ausgehenden Traffic von Arbeitslasten in einer VM verwalten

Wenn Sie Arbeitslasten in einer VM für die Egress-Konnektivität konfigurieren möchten, können Sie die GDC-Konsole für die VM-Konfiguration verwenden oder eine VirtualMachineExternalAccess-Ressource erstellen. Informationen zum Aktivieren des externen Zugriffs für eine VM zur Datenübertragung finden Sie im Abschnitt Mit VMs verbinden unter Externen Zugriff aktivieren.

Zu Cloud NAT migrieren

Da Cloud NAT in Version 1.15 verfügbar ist, wird die standardmäßige NAT-Konfiguration für den Projekt-Egress pro Projekt eingestellt. Es wird empfohlen, dass Nutzer ihre Konfigurationen für ausgehenden Traffic von der standardmäßigen NAT-Konfiguration für ausgehenden Traffic des Projekts zu Cloud NAT migrieren.

Das Standard-NAT für ausgehenden Traffic auf Projektebene und Cloud NAT sind nicht miteinander kompatibel. Mit anderen Worten: Ein bestimmter Pod- oder VM-Endpunkt kann nur einen der beiden verwenden. Wenn Sie Endpunkte von einer Konfiguration in die andere migrieren möchten, müssen Sie sie in der einen deaktivieren und in der anderen aktivieren.

Deaktivieren Sie zuerst die alte Konfiguration der Endpunkte, die Sie migrieren möchten. Dazu gibt es zwei mögliche Vorgehensweisen:

  • Standard-NAT für ausgehenden Traffic für das gesamte Projekt deaktivieren: Deaktivieren Sie die Standard-NAT für ausgehenden Traffic für alle Endpunkte im Projekt, indem Sie dem Projekt das Label networking.gdc.goog/allocate-egress-ip: "false" zuweisen.
  • Standard-Egress-NAT auf Projektebene pro Endpunkt deaktivieren: Deaktivieren Sie das Standard-Egress-NAT auf Projektebene für einen bestimmten Pod- oder VM-Endpunkt, indem Sie das Label egress.networking.gke.io/enabled:"true" aus dem Pod oder der VM entfernen.

Um die Migration fortzusetzen, kann jeder Endpunkt, der aus dem Standard-NAT für ausgehenden Traffic entfernt wird, einem Cloud NAT-Gateway hinzugefügt werden. Dazu müssen Sie dem Endpunkt Labels hinzufügen, die mit den Labelselektoren des ausgewählten Gateways übereinstimmen.

Eine Anleitung zum Einrichten von Cloud NAT finden Sie unter Cloud NAT und auf den folgenden Seiten.

Tracking ausgehender IP-Adressen

Bei der Standard-NAT für ausgehenden Traffic sind die ausgehenden IP-Adressen, die für die NAT für ausgehenden Traffic verwendet werden, im Status des Projekts enthalten. Bei Cloud NAT enthält das Projektobjekt keine Egress-IP-Adressen. Stattdessen kann der Nutzer die vom Cloud NAT-Gateway verwendeten IPs auflisten, indem er die dem Gateway zugewiesenen Subnetze auflistet.