Diese Seite wurde von der Cloud Translation API übersetzt.

Dual-Stack-Ressourcen einrichten

Mit Dual-Stack-Subnetzen können Ihre Cloud Run-Ressourcen IPv4- und IPv6-Traffic über ausgehenden Direct VPC-Traffic an ein VPC-Netzwerk senden. Sie können ein vorhandenes IPv4-Subnetz (Single-Stack) in ein Dual-Stack-Subnetz ändern.

Subnetztypen

VPC-Netzwerke unterstützen die folgenden Compute Engine-Subnetztypen:

Nur-IPv4-Subnetze (Single-Stack) mit nur IPv4-Subnetzbereichen
IPv4- und IPv6-Subnetze (Dual-Stack) mit IPv4- und IPv6-Subnetzbereichen

Einschränkungen bei Dual-Stack

Bevor Sie den Stacktyp einer vorhandenen Cloud Run-Ressource ändern, beachten Sie die folgenden Einschränkungen:

Dual-Stack-Unterstützung ist nur für Subnetze in einem VPC-Netzwerk im benutzerdefinierten Modus verfügbar. Damit der interne Zugriffstyp für Dual-Stack-Subnetze verfügbar ist, muss der interne IPv6-Bereich des VPC-Netzwerk aktiviert sein. Richten Sie das VPC-Netzwerk im benutzerdefinierten Modus ein oder konvertieren Sie es in den benutzerdefinierten Modus.
Im Vergleich zu reinen IPv4-Subnetzen kann es bei Dual-Stack-Subnetzen zu erhöhten Kaltstartlatenzen kommen, was die Geschwindigkeit einschränkt, mit der Ihre Anwendung skaliert werden kann.
NAT64 wird nicht unterstützt.

Hinweise

Der Cloud Run-Dienst-Agent muss die Rolle „Administrator öffentlicher IP-Adressen für Compute Engine“ (roles/compute.publicIpAdmin) haben, damit das Subnetz mit externen IPv6-Adressen verwendet werden kann.

Dual-Stack-Subnetz für eine Ressource hinzufügen

Dual-Stack-Subnetze haben sowohl IPv4- als auch IPv6-Adressbereiche.

So fügen Sie einer Cloud Run-Ressource ein Dual-Stack-Subnetz hinzu:

Console

In der Google Cloud Console:
1. Aktivieren Sie die Compute Engine API:
  
  Compute Engine-API aktivieren
2. Rufen Sie die Seite VPC-Netzwerke auf:
  
  Zur Seite VPC-Netzwerke
Klicken Sie auf VPC-Netzwerk erstellen, wenn Sie ein neues Netzwerk im benutzerdefinierten Modus erstellen. Wenn Sie ein vorhandenes VPC-Netzwerk verwenden, klicken Sie auf den Namen des VPC-Netzwerks, um die Seite VPC-Netzwerkdetails aufzurufen.
Wenn Sie ein neues Netzwerk erstellen oder ein vorhandenes konvertieren, geben Sie den Namen ein und achten Sie darauf, dass der Subnet creation mode (Modus für die Subnetzerstellung) auf Custom (Benutzerdefiniert) gesetzt ist. Wählen Sie dann Configure a ULA internal IPv6 range for this VPC Network (Internen ULA-IPv6-Bereich für dieses VPC-Netzwerk konfigurieren) aus.
Klicken Sie auf dem Tab Subnetze auf Subnetz hinzufügen. Führen Sie im angezeigten Bereich folgende Schritte aus:
1. Geben Sie einen Namen an.
2. Wählen Sie eine Region aus.
3. Wählen Sie für IP-Stack-Typ IPv4 und IPv6 (Dual-Stack) aus.
4. Geben Sie einen IPv4-Bereich ein. Dies ist der primäre IPv4-Bereich für das Subnetz.
5. Wählen Sie den IPv6-Zugriffstyp aus.
  
  Wenn die Option Intern nicht verfügbar ist und Sie sie benötigen, prüfen Sie, ob dem Netzwerk ein interner IPv6-Bereich zugewiesen ist.
6. Klicken Sie auf Hinzufügen.
Stellen Sie einen Cloud Run-Dienst bereit, führen Sie einen Job aus oder stellen Sie einen Worker-Pool bereit im Dual-Stack-Subnetz, das Sie erstellt haben. Geben Sie die erforderlichen Ressourcendetails ein und wählen Sie den neuen IPv6-Adressbereich aus. Gehen Sie dazu so vor:
1. Klicken Sie auf Container, Volumes, Netzwerk, Sicherheit und wählen Sie den Tab Netzwerk aus.
2. Klicken Sie auf Mit einer VPC für ausgehenden Traffic verbinden und dann auf Traffic direkt an eine VPC senden.
3. Wählen Sie das Netzwerk aus, das Sie im vorherigen Schritt erstellt haben.
4. Klicken Sie auf das Feld Subnetz, um den neu erstellten IPv6-Adressbereich auszuwählen.
Die Ressource wird automatisch mit dem Stack-Typ des Subnetzes bereitgestellt.

gcloud

Führen Sie den Befehl gcloud compute networks create aus, um ein Netzwerk im benutzerdefinierten Modus zu erstellen, das Dual-Stack-Subnetze unterstützt.

Verwenden Sie das --enable-ula-internal-ipv6-Flag, um interne IPv6-Bereiche in allen Subnetzen dieses Netzwerks zu konfigurieren. Mit dieser Option wird ein ULA-Präfix /48 aus dem Bereich fd20::/20 zugewiesen, der von Google Cloud für interne IPv6-Subnetzbereiche verwendet wird.
```
gcloud compute networks create NETWORK \
  --subnet-mode=custom \
  --enable-ula-internal-ipv6
```
Ersetzen Sie NETWORK durch den Namen des VPC-Netzwerks, das das neue Subnetz enthält.
Führen Sie den folgenden Befehl aus, um ein Netzwerk im benutzerdefinierten Modus zu konvertieren oder zu aktualisieren, damit es Dual-Stack-Subnetze unterstützt:
```
gcloud compute networks update NETWORK \
  --subnet-mode=custom \
  --enable-ula-internal-ipv6
```
Ersetzen Sie NETWORK durch den Namen des VPC-Netzwerks, das das neue Subnetz enthält.
Führen Sie den Befehl subnets create mit den Dual-Stack-Einstellungen aus, um ein Dual-Stack-Subnetz mit einem IPv6-Bereich zu erstellen:
```
gcloud compute networks subnets create SUBNET \
  --network=NETWORK \
  --range=PRIMARY_IPv4_RANGE \
  --stack-type=IPV4_IPV6 \
  --ipv6-access-type=IPV6_ACCESS_TYPE \
  --region=REGION
```
Ersetzen Sie Folgendes:
- SUBNET: ein Name für das neue Subnetz.
- NETWORK: der Name des VPC-Netzwerks mit dem neuen Subnetz.
- PRIMARY_IPv4_RANGE: der primäre IPv4-Bereich für das neue Subnetz in CIDR-Notation. Weitere Informationen finden Sie unter IPv4-Subnetzbereiche.
- IPV6_ACCESS_TYPE: Der IPv6-Zugriffstyp für das neue Subnetz, entweder internal oder external.
- REGION: die Google Cloud Region, in der das neue Subnetz erstellt wird.
Stellen Sie einen Cloud Run-Dienst bereit, führen Sie einen Job aus oder stellen Sie einen Worker-Pool bereit im Dual-Stack-Subnetz, das Sie erstellt haben. Die Ressource wird automatisch mit dem Stack-Typ des Subnetzes bereitgestellt.

YAML

Wenn Sie einen neuen Dienst erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Dienst aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
```
gcloud run services describe SERVICE --format export > service.yaml
```
Aktualisieren Sie die folgenden Attribute:
```
apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: SERVICE_NAME
    labels:
      cloud.googleapis.com/location: REGION
  spec:
    template:
      metadata:
        annotations:
          run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
          run.googleapis.com/vpc-access-egress: EGRESS_SETTING
      spec:
        containers:
        - image: IMAGE
```
Ersetzen Sie:
- SERVICE_NAME durch den Namen Ihres Cloud Run-Dienstes. Dienstnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen.
- REGION durch die Region für Ihren Cloud Run-Dienst; diese muss der Region Ihres Subnetzes entsprechen.
- NETWORK durch den Namen Ihres VPC-Netzwerks.
- SUBNET durch den Namen Ihres Subnetzes. Sie können mehrere Dienste, Jobs oder Worker-Pools im selben Subnetz bereitstellen oder ausführen.
- Optional: Ersetzen Sie NETWORK_TAG_NAMES durch die Namen der Netzwerk-Tags, die Sie einem Dienst zuordnen möchten. Bei Diensten werden Netzwerk-Tags auf Versionsebene angegeben. Jede Dienstversion kann unterschiedliche Netzwerk-Tags haben, z. B. network-tag-2.
- EGRESS_SETTING durch einen Wert für die Einstellung für ausgehenden Traffic:
  - all-traffic: Sendet den gesamten ausgehenden Traffic über das VPC-Netzwerk.
  - private-ranges-only: Sendet nur Traffic an interne Adressen über das VPC-Netzwerk.
- IMAGE durch die URL Ihres Dienst-Container-Images.
Sie können auch weitere Konfigurationen angeben, z. B. Umgebungsvariablen oder Speicherlimits.
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
```
gcloud run services replace service.yaml
```

Terraform

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

Fügen Sie der Datei main.tf Folgendes hinzu:

/**
 * Copyright 2024 Google LLC
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

# Example configuration of a Cloud Run service with direct VPC

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    vpc_access {
      network_interfaces {
        network    = "default"
        subnetwork = "default"
        tags       = ["tag1", "tag2", "tag3"]
      }
    }
  }
}

Optional: Veröffentlichen Sie Ihren Dienst, wenn Sie den nicht authentifizierten Zugriff auf den Dienst zulassen möchten.

Subnetz von Single-Stack in Dual-Stack ändern

Informationen zum Hinzufügen eines IPv6-Subnetzbereichs zu einem vorhandenen Nur-IPv4-Subnetz in einem VPC-Netzwerk im benutzerdefinierten Modus finden Sie unter Stack-Typ eines Subnetzes in Dual-Stack ändern. Stellen Sie dann den Cloud Run-Dienst bereit, führen Sie den Job aus oder stellen Sie den Worker-Pool bereit.

Subnetz von Dual-Stack in Single-Stack ändern

Informationen zum Ändern des Dual-Stack-Subnetzes einer Ressource in ein Single-Stack-Subnetz finden Sie unter Dual-Stack-Subnetz in „Nur IPv4“ ändern. Stellen Sie dann den Cloud Run-Dienst bereit, führen Sie den Job aus oder stellen Sie den Worker-Pool bereit.

Netzwerk und Subnetz prüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob sich Ihre Ressource im VPC-Netzwerk befindet:

gcloud run services describe SERVICE_NAME --region=REGION

Ersetzen Sie REGION durch die Google Cloud Region, in der das neue Subnetz erstellt wurde.

Die folgende Beispielausgabe zeigt Ihr Netzwerk und Subnetz:

  VPC Access:
    Network:        example-network
    Subnet:         example-subnet
    Egress:         private-ranges-only