Umgebung mit einem VPC-Netzwerk verbinden

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

Auf dieser Seite wird erläutert, wie Ihre Umgebung auf ein VPC-Netzwerk in Managed Airflow (3. Generation) zugreifen kann. Außerdem finden Sie hier eine Anleitung zum Verbinden einer Umgebung mit einem VPC-Netzwerk und zum Deaktivieren einer zuvor konfigurierten Verbindung.

VPC-Netzwerkzugriff

In Managed Airflow (3. Generation) können Sie den Zugriff auf ein VPC-Netzwerk für eine Umgebung aktivieren.

Wenn Sie den Zugriff auf ein VPC-Netzwerk für eine Umgebung aktivieren, gilt Folgendes:

  • Airflow-Komponenten Ihrer Umgebung können auf private Netzwerkendpunkte in Ihrem VPC-Netzwerk zugreifen. Beispielsweise kann Ihr DAG-Code über eine konfigurierte Airflow-Verbindung auf Ressourcen in Ihrem VPC-Netzwerk zugreifen.

  • Wenn in Ihrer Umgebung Private IP networking verwendet wird, wird der gesamte Traffic an Ihr VPC-Netzwerk weitergeleitet, mit Ausnahme des Traffics zu Google APIs, Diensten und Domains, die für Umgebungen mit privaten IP-Adressen über den privater Google-Zugriff verfügbar sind. Mit dieser Methode können Ihre Airflow-Komponenten auch eine Verbindung zu Privately Used Public IPs (PUPI) herstellen, die in GKE konfiguriert sind, da der Traffic über das VPC-Netzwerk weitergeleitet wird, anstatt an das öffentliche Internet gesendet zu werden.

  • Je nach Konfiguration Ihres VPC-Netzwerks kann eine Umgebung mit privaten IP-Adressen über Ihr VPC-Netzwerk auf das Internet zugreifen.

  • Private DNS-Zonen, die in Ihrem VPC-Netzwerk definiert sind, sind automatisch für die Airflow-Komponenten Ihrer Umgebung verfügbar.

  • In der Umgebung werden zwei IP-Adressen in Ihrem VPC-Subnetzwerk reserviert und während der Wartung und bei Upgrades werden zwei zusätzliche IP-Adressen verwendet. Achten Sie darauf, dass in Ihrem VPC-Subnetzwerk vier IP-Adressen pro Umgebung verfügbar sind.

Managed Airflow verwendet einen Netzwerkanhang, um Ihre Umgebung mit einem VPC-Netzwerk zu verbinden:

  • Wenn Sie ein VPC-Netzwerk und ein Subnetzwerk angeben, erstellt Managed Airflow in Ihrem Projekt einen neuen Netzwerkanhang. Dieser Anhang wird gelöscht, wenn Sie eine Umgebung löschen, die Verbindung zu einem VPC-Netzwerk deaktivieren oder die VPC-Verbindungsparameter überschreiben.

  • Wenn Sie einen vorhandenen Netzwerkanhang angeben, muss er sich im selben Projekt wie die Umgebung befinden. Dieser Anhang wird nicht gelöscht, wenn Sie eine Umgebung löschen, die Verbindung deaktivieren oder die VPC-Verbindungsparameter überschreiben.

  • Im gemeinsam genutzten VPC-Netzwerk:

    • Stellen Sie sicher, dass Sie die freigegebene VPC-Netzwerkfunktion für Managed Airflow konfiguriert haben. Informationen zum Konfigurieren von Projekten und Berechtigungen für Managed Airflow finden Sie unter Gemeinsam genutzte VPC konfigurieren.

    • Nachdem das gemeinsam genutzte VPC-Netzwerk konfiguriert wurde, können Sie Ihre Umgebung mit einem VPC-Netzwerk aus dem Hostprojekt verbinden. Wenn Sie einen vorhandenen Netzwerk-Anhang verwenden, muss er im Dienstprojekt (in dem sich die Umgebung befindet) erstellt und an ein freigegebene VPC-Netzwerk angehängt werden.

Einschränkungen für transitives DNS-Peering in Managed Airflow (Gen 3)

Die Einschränkungen für transitives DNS-Peering gelten für eine Managed Airflow (Gen 3)-Umgebung auf folgende Weise:

  • Cloud DNS hat eine Beschränkung von einem transitiven Hop, was bedeutet, dass insgesamt nur zwei Hops unterstützt werden.
  • In Managed Airflow (3. Generation) werden die Komponenten Ihrer Umgebung im Mandantenprojekt ausgeführt und kommunizieren über ein DNS-Peering mit dem Projekt, in dem sich die Umgebung befindet. Der transitive Hop wird vom DNS-Peering des Mandantenprojekts verwendet, sodass insgesamt nur ein Hop möglich ist.

Interner IP-Bereich der Umgebung

Für Managed Airflow-Umgebungen (3. Generation) sind mehrere IP-Adressen für die Komponenten erforderlich, die im Mandantenprojekt ausgeführt werden, z. B. der Cluster der Umgebung und der Cloud SQL-Proxy. Diese IP-Adressen stammen aus dem internen IP-Bereich der Umgebung.

  • Der standardmäßige interne IP-Bereich ist 100.64.128.0/20.

  • Sie können beim Erstellen einer Umgebung einen anderen internen IP-Bereich angeben. Für diesen Bereich muss eine /20-Maske verwendet werden.

  • Sie können den internen IP-Bereich einer vorhandenen Umgebung nicht ändern.

Der interne IP-Bereich interagiert auf folgende Weise mit Ihrem VPC-Netzwerk:

  • Der interne IP-Bereich darf nicht mit dem VPC-Subnetzwerk in Konflikt stehen, mit dem die verwaltete Airflow-Umgebung verbunden ist. Es ist nicht möglich, eine Verbindung mit einem VPC-Subnetzwerk zu aktivieren, das sich mit dem internen IP-Bereich überschneidet.

  • Wenn sich der interne IP-Bereich einer Umgebung mit den Bereichen Ihres VPC-Netzwerks überschneidet, sind Endpunkte aus Ihrem VPC-Netzwerk mit sich überschneidenden IP-Adressen nicht über die Umgebung erreichbar.

    Wenn der interne Bereich beispielsweise 100.64.128.0/20 ist, schlägt jede Anfrage an den 100.64.128.1-Endpunkt in Ihrem VPC-Netzwerk fehl, da die Anfrage das Mandantenprojekt nicht verlässt.

  • Der interne IP-Bereich ist nicht reserviert. Sie können denselben internen IP-Bereich für mehrere Umgebungen ohne zusätzliche Einrichtung verwenden, da die internen VPC-Netzwerke, die von verschiedenen Umgebungen verwendet werden, getrennt sind.

  • Sie können die IP-Adressen des internen Bereichs für andere Zwecke verwenden, solange DAGs und Aufgaben in Ihrer Umgebung keine Anfragen an sie senden.

Verbindung zu einem VPC-Netzwerk herstellen

Console

  1. Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.

    Zur Seite Umgebungen

  2. Klicken Sie in der Liste der Umgebungen auf den Namen Ihrer Umgebung. Die Seite Umgebungsdetails wird geöffnet.

  3. Rufen Sie den Tab Umgebungskonfiguration auf.

  4. Suchen Sie im Bereich Netzwerkkonfiguration nach dem Element Netzwerkverbindung und klicken Sie auf Bearbeiten.

  5. Gehen Sie im Dialogfeld Netzwerkverbindung so vor:

    • Wenn Sie einen neuen Netzwerkanhang erstellen möchten, wählen Sie in der Liste Netzwerkanhang die Option Neuen Netzwerkanhang erstellen aus. Wählen Sie in den Listen Netzwerk und Subnetzwerk ein VPC-Netzwerk und ein Subnetzwerk aus.

    • Wenn Sie einen vorhandenen Netzwerkanhang verwenden möchten, wählen Sie in der Liste Netzwerkanhang einen Anhang aus.

  6. Klicken Sie auf Speichern.

gcloud

Mit den folgenden Google Cloud CLI-Argumenten werden Parameter für die VPC-Netzwerkverbindung angegeben:

  • --network: VPC-Netzwerk-ID.
  • --subnetwork: VPC-Subnetzwerk-ID.
  • --network-attachment: Verwenden Sie stattdessen einen vorhandenen Netzwerkanhang.

Neuer Netzwerkanhang

Führen Sie den folgenden Google Cloud CLI-Befehl aus, um Ihre Umgebung über eine neue Netzwerkverbindung mit einem VPC-Netzwerk zu verbinden:

gcloud beta composer environments update ENVIRONMENT_NAME \
  --location LOCATION \
  --network NETWORK_ID \
  --subnetwork SUBNETWORK_ID

Ersetzen Sie Folgendes:

  • ENVIRONMENT_NAME: der Name der Umgebung
  • LOCATION: die Region, in der sich die Umgebung befindet
  • NETWORK_ID: VPC-Netzwerk-ID
  • SUBNETWORK_ID: VPC-Subnetzwerk-ID

Beispiel:

gcloud beta composer environments update example-environment \
  --location us-central1 \
  --network projects/example-project/global/networks/example-network \
  --subnetwork projects/example-project/regions/us-central1/subnetworks/example-subnetwork

Vorhandener Netzwerkanhang

Führen Sie den folgenden Google Cloud CLI-Befehl aus, um Ihre Umgebung über eine neue Netzwerkverbindung mit einem VPC-Netzwerk zu verbinden:

gcloud beta composer environments update ENVIRONMENT_NAME \
  --location LOCATION \
  --network-attachment NETWORK_ATTACHMENT_ID

Ersetzen Sie Folgendes:

  • ENVIRONMENT_NAME: der Name der Umgebung
  • LOCATION: die Region, in der sich die Umgebung befindet
  • NETWORK_ATTACHMENT_ID: Der Netzwerkanhang im Format projects/{project}/regions/{region}/networkAttachments/{networkAttachment}.

Beispiel:

gcloud beta composer environments update example-environment \
  --location us-central1 \
  --network-attachment projects/example-project/regions/us-central1/networkAttachments/example-network-attachment

API

  1. Erstellen Sie eine environments.patch-API-Anfrage.

  2. In dieser Anfrage:

    • So erstellen Sie einen neuen Netzwerkanhang:

      1. Geben Sie im updateMask-Parameter die config.node_config.network,config.node_config.subnetwork-Maske an.

      2. Geben Sie im Anfragetext in den Feldern network und subnetwork Ihre VPC-Netzwerk- und Subnetzwerk-IDs an.

    • So verwenden Sie eine vorhandene Netzwerkverbindung:

      1. Geben Sie im Parameter updateMask die Maske config.node_config.composer_network_attachment an.

      2. Geben Sie im Anfragetext einen Wert für die vorhandene Netzwerkverbindung im Format projects/{project}/regions/{region}/networkAttachments/{networkAttachment} an.

Beispiel (neuer Netzwerkanhang):

// PATCH https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment?updateMask=
// config.node_config.network,config.node_config.subnetwork

"config": {
  "nodeConfig": {
    "network": "projects/example-project/global/networks/example-network",
    "subnetwork": "projects/example-project/regions/us-central1/subnetworks/example-subnetwork"
  }
}

Beispiel (vorhandener Netzwerkanhang):

// PATCH https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment?updateMask=
// config.node_config.composer_network_attachment

"config": {
  "nodeConfig": {
    "composerNetworkAttachment": "projects/example-project/regions/us-central1/networkAttachments/example-network-attachment"
  }
}

Terraform

Die folgenden Felder im node_config-Block geben Parameter für die VPC-Netzwerkverbindung an:

  • network: VPC-Netzwerk-ID.
  • subnetwork: VPC-Subnetzwerk-ID.
  • composer_network_attachment: Verwenden Sie stattdessen einen vorhandenen Netzwerkanhang.

Neuer Netzwerkanhang

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    node_config {
      network = NETWORK_ID
      subnetwork = SUBNETWORK_ID
    }

  }
}

Ersetzen Sie Folgendes:

  • ENVIRONMENT_NAME: der Name Ihrer Umgebung
  • LOCATION: die Region, in der sich die Umgebung befindet.
  • NETWORK_ID: VPC-Netzwerk-ID
  • SUBNETWORK_ID: VPC-Subnetzwerk-ID

Beispiel (neuer Netzwerkanhang):

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    node_config {
      network = "projects/example-project/global/networks/example-network"
      subnetwork = "projects/example-project/regions/us-central1/subnetworks/example-subnetwork"
    }

    ... other configuration parameters
  }
}

Vorhandener Netzwerkanhang

Daher wird der Anhang nicht mehr in der Umgebung verwendet. Damit das nicht passiert, müssen Sie dafür sorgen, dass Terraform Änderungen am Parameter producer_accept_lists des Anhangs ignoriert. Gehen Sie dazu so vor:

resource "google_compute_network_attachment" "NETWORK_ATTACHMENT_ID" {
  lifecycle {
    ignore_changes = [producer_accept_lists]
  }
  # ... other configuration parameters
}

Geben Sie diesen Anhang anschließend für eine Umgebung an. Sie können auch einen Anhang angeben, der nicht in Terraform verwaltet wird. Weitere Informationen finden Sie im Beispiel.

resource "google_composer_environment" "example" {
  name = "example-environment"
  region = "us-central1"
  config {
    node_config {
      composer_network_attachment = google_compute_network_attachment.NETWORK_ATTACHMENT_ID.id
    }
    # ... other configuration parameters
  }
}

Ersetzen Sie Folgendes:

  • ENVIRONMENT_NAME: der Name Ihrer Umgebung
  • LOCATION: die Region, in der sich die Umgebung befindet.
  • NETWORK_ATTACHMENT_ID ist die ID des Netzwerkanhangs.

Beispiel (vorhandener Netzwerkanhang):

resource "google_compute_network_attachment" "example" {
  lifecycle {
    ignore_changes = [producer_accept_lists]
  }
  # ... other configuration parameters
}

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    node_config {
      # Attachment is managed in Terraform:

      composer_network_attachment = google_compute_network_attachment.NETWORK_ATTACHMENT_ID.id

      # Attachment is not managed in Terraform:

      # composer_network_attachment = projects/example-project/regions/us-central1/networkAttachments/example-network-attachment
    }
    # ... other configuration parameters
  }
}

Verbindung zu einem VPC-Netzwerk deaktivieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.

    Zur Seite Umgebungen

  2. Klicken Sie in der Liste der Umgebungen auf den Namen Ihrer Umgebung. Die Seite Umgebungsdetails wird geöffnet.

  3. Rufen Sie den Tab Umgebungskonfiguration auf.

  4. Suchen Sie im Bereich Netzwerkkonfiguration nach dem Element Netzwerkverbindung und klicken Sie auf Bearbeiten.

  5. Wählen Sie im Dialogfeld Netzwerkverbindung die Option Keine aus und klicken Sie auf Speichern.

gcloud

Das Argument --disable-vpc-connectivity deaktiviert die VPC-Netzwerkverbindung Ihrer Umgebung:

gcloud beta composer environments update ENVIRONMENT_NAME \
  --location LOCATION \
  --disable-vpc-connectivity

Ersetzen Sie Folgendes:

  • ENVIRONMENT_NAME: der Name der Umgebung
  • LOCATION: die Region, in der sich die Umgebung befindet

Beispiel:

gcloud beta composer environments update example-environment \
  --location us-central1 \
  --disable-vpc-connectivity

API

  1. Erstellen Sie eine environments.patch-API-Anfrage.

  2. In dieser Anfrage:

    1. Geben Sie im updateMask-Parameter die config.node_config.network,config.node_config.subnetwork-Maske an.

    2. Geben Sie im Anfragetext in den Feldern network und subnetwork leere Werte an.

Beispiel:

// PATCH https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment?updateMask=
// config.node_config.network,config.node_config.subnetwork

"config": {
  "nodeConfig": {
    "network": "",
    "subnetwork": ""
  }
}

Terraform

Es ist nicht möglich, ein VPC-Netzwerk mit Terraform zu trennen. Stattdessen können Sie ein anderes VPC-Netzwerk anhängen oder das Netzwerk mit anderen Tools wie der Google Cloud CLI trennen.

Cloud Run-Traffic über die Netzwerkverbindung weiterleiten

Wenn Sie den eingehenden Traffic zu internen Endpunkten für Ihren Cloud Run-Dienst einschränken, können Sie nicht über eine Managed Airflow-Umgebung auf diesen Endpunkt zugreifen. Der Zugriff ist eingeschränkt, da Airflow-Worker im Mandantenprojekt der Umgebung nicht zum selben VPC-Netzwerk wie die Umgebung gehören.

Optional können Sie den Traffic über die Netzwerkverbindung an den Endpunkt der Funktion weiterleiten, anstatt über die Standardroute zu Google APIs.

Nach der Änderung wird der Traffic zu den folgenden beiden Domains über die Netzwerkverbindung Ihrer Umgebung weitergeleitet:

  • .run.app
  • .cloudfunctions.net

Wenn Ihre App benutzerdefinierte Domains verwendet und Sie eine Umgebung mit privater IP-Adresse mit einem verbundenen VPC-Netzwerk verwenden, wird der Traffic zu Nicht-Google-Adressen standardmäßig über die Netzwerkverbindung der Umgebung geleitet.

Für eine Umgebung, in der die Verbindung auf diese Weise konfiguriert ist, gelten die folgenden Einschränkungen:

  • In der Umgebung muss ein privates IP-Netzwerk verwendet werden. Wenn in Ihrer Umgebung eine öffentliche IP-Adresse verwendet wird, können Sie den Netzwerktyp ändern.
  • Es ist nicht möglich, eine Umgebung von einem VPC-Netzwerk zu trennen. Wenn Sie die Verbindung trennen möchten, müssen Sie zuerst zur Standard-Routenführung zurückkehren.

So konfigurieren Sie das Traffic-Routing zu Cloud Run:

gcloud

Verwenden Sie beim Erstellen oder Aktualisieren der Umgebung das Argument --cloud-run-functions-routing:

  • (Standard) direct: Traffic wird auf dieselbe Weise an Cloud Run weitergeleitet wie an andere Google-APIs und ‑Dienste.
  • via-network-attachment: Leiten Sie den Traffic zu Cloud Run über die Netzwerkverbindung der Umgebung weiter.

Sie können dieses Argument im selben Vorgang wie das Verbinden des VPC-Netzwerks verwenden.

Führen Sie den folgenden Befehl in der gcloud CLI aus, um das Routing über die Netzwerkverbindung der Umgebung zu aktivieren:

gcloud beta composer environments update ENVIRONMENT_NAME \
  --location LOCATION \
  --cloud-run-functions-routing via-network-attachment

Ersetzen Sie Folgendes:

  • ENVIRONMENT_NAME: der Name der Umgebung
  • LOCATION: die Region, in der sich die Umgebung befindet

Beispiel:

gcloud beta composer environments update example-environment \
  --location us-central1 \
  --cloud-run-functions-routing via-network-attachment

API

  1. Erstellen Sie eine environments.patch-API-Anfrage.

  2. In dieser Anfrage:

    1. Geben Sie im updateMask-Parameter die node_config.TrafficRoutingConfig-Maske an.

    2. Geben Sie im Anfragetext im Feld cloud_run_functions_routing an, wie der Traffic zu Cloud Run weitergeleitet werden muss.

      • (Standard) DIRECT: Leiten Sie den Traffic an Cloud Run weiter, so wie an andere Google-APIs und ‑Dienste.
      • VIA_NETWORK_ATTACHMENT: Leiten Sie Traffic zu Cloud Run über die Netzwerkverbindung der Umgebung weiter.

Sie können dieses Argument im selben Vorgang wie das Verbinden des VPC-Netzwerks verwenden.

Beispiel:

// PATCH https://composer.googleapis.com/v1beta1/projects/example-project/
// locations/us-central1/environments/example-environment?updateMask=
// config.node_config.TrafficRoutingConfig

{
  "config": {
    "nodeConfig": {
      "trafficRoutingConfig": {
        "cloudRunFunctionsRouting": "VIA_NETWORK_ATTACHMENT"
      }
    }
  }
}

Nächste Schritte