Ausgehender Direct VPC-Traffic mit einem VPC-Netzwerk

Sie können Ihren Cloud Run-Dienst, -Job oder -Worker-Pool so aktivieren, dass Traffic an ein VPC-Netzwerk über ausgehenden Direct VPC-Traffic gesendet wird, ohne dass ein Connector für Serverloser VPC-Zugriff erforderlich ist.

Hinweise

• Wenn Sie in Ihrem Projekt noch kein VPC-Netzwerk haben, erstellen Sie eins.

• Wenn Sie eine freigegebene VPC mit Cloud Run-Diensten oder -Jobs verwenden, finden Sie weitere Informationen unter Verbindung zu einem freigegebenen VPC-Netzwerk herstellen.

• Sehen Sie sich die folgenden Abschnitte zur Konfiguration von IP-Adressen an:

  • IP-Adressenzuweisung für Informationen zur Zuweisung von IP-Adressen aus Ihrem Subnetz.

  • Strategien zur Ausschöpfung von IP-Adressen für die Verwendung alternativer IP-Adressbereiche.

Beschränkungen

Die folgenden Einschränkungen gelten für Cloud Run-Dienste, -Jobs und -Worker-Pools:

• Wenn Sie ausgehenden Direct VPC-Traffic verwenden, kann es beim Starten der Instanz zu Verzögerungen beim Herstellen der Verbindung von einer Minute oder länger kommen. Wir empfehlen, eine HTTP-Startprüfung zu konfigurieren, die eine Verbindung zu einem von der Anwendung verwendeten Ausgangsziel testet, bevor die Anwendung Anfragen akzeptiert. Für diesen Test der ausgehenden Verbindung sollten entweder Wiederholungsversuche implementiert werden oder die Startprüfung sollte mit geeigneten Konfigurationen für Zeitraum und Grenzwert festgelegt werden, um als Wiederholungsversuch zu fungieren.
• Cloud Run unterstützt einen Durchsatz von bis zu 1 Gbit/s pro Instanz. Das Überschreiten dieses Betrags führt zu einer Leistungsdrosselung.

• Ein Cloud Run-Nutzungskontingent begrenzt die maximale Anzahl von Instanzen, die Sie für die Verwendung von Direct VPC-Egress konfigurieren können. Die maximale Anzahl wird pro Cloud Run-Revision oder Jobausführung konfiguriert. Informationen zum Erhöhen der Standardlimits finden Sie hier.

• Bei Cloud Run-Diensten, ‑Jobs und ‑Worker-Pools kann es während der Wartung der Netzwerkinfrastruktur zu Verbindungsunterbrechungen kommen. Wir empfehlen die Verwendung von Clientbibliotheken, bei denen gelegentlich Verbindungen zurückgesetzt werden können ohne dass es Probleme gibt.
• Die Unterstützung für direkten VPC-Ausgang für internen IPv6-Traffic ist nur in der Vorschau verfügbar.
• Privates NAT ist nur in der Vorschau verfügbar.

Die folgenden Elemente werden vom ausgehendem Direct VPC-Traffic nicht unterstützt:

• VPC-Flusslogs geben nicht den Namen des Cloud Run-Dienstes oder der Cloud Run-Überarbeitung an.
• VPC-Flusslogs werden nicht von Nicht-VM-Ressourcen wie Cloud Run oder lokalen Maschinen gemeldet.
• Paketspiegelung
• Network Intelligence Center, einschließlich Konnektivitätstests
• Externer IPv6-Traffic über ein VPC-Netzwerk
• Netzwerktags oder Dienstidentität in Firewallregeln für eingehenden Traffic.
• Firewallregeln können Resource Manager-Tags, die mit Cloud Run-Arbeitslasten verknüpft sind, nicht verwenden.
• Bei Cloud Run-Jobs, die länger als eine Stunde ausgeführt werden, kann es zu Verbindungsunterbrechungen kommen. Diese können bei Wartungsereignissen auftreten, bei denen der Job von einer Maschine auf eine andere migriert wird. Der Container erhält 10 Sekunden vor dem Ereignis ein SIGTSTP-Signal, Nach dem Ereignis erhält er ein SIGCONT-Signal. Nachdem der Container das SIGCONT-Signal erhalten hat, wiederholen Sie die Verbindung.

Zuweisung von IP-Adressen

Wenn Sie Ihren Cloud Run-Dienst, -Job oder -Worker-Pool in einem VPC-Netzwerk platzieren möchten, geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, hat das Subnetz denselben Namen wie das Netzwerk. Cloud Run weist IP-Adressen aus Ihrem Subnetz zu.

IP-Adressen sind sitzungsspezifisch. Erstellen Sie also keine Richtlinien, die auf einzelnen IP-Adressen basieren. Wenn Sie eine Richtlinie anhand von IP-Adressen erstellen müssen, z. B. in Firewallregeln, müssen Sie den IP-Adressbereich des gesamten Subnetzes verwenden.

Wenn Sie das von Ihrem Dienst, Job oder Worker-Pool verwendete Netzwerk oder Subnetz ändern möchten, stellen Sie eine neue Überarbeitung bereit oder führen Sie eine neue Jobaufgabe aus, die die neuen Netzwerk- und Subnetzwerte verwendet.

Hoch- und herunterskalieren

Damit bei einem Trafficanstieg schnell eine vertikale Skalierung möglich ist, reserviert Cloud Run IP-Adressen in Blöcken von 16 Adressen (28-Subnetzmaske). Sehen Sie nach, welche IP-Adressen Cloud Run zugewiesen hat. Damit Sie genügend IPv4-Adressen für die Verwendung in Cloud Run haben, muss der IPv4-Adressbereich Ihres Subnetzes mindestens /26 sein.

Für eine effiziente IP-Zuweisung und einfachere Verwaltung platzieren Sie mehrere Ressourcen im selben Subnetz. Wenn Ihr IPv4-Adressbereich begrenzt ist, finden Sie weitere Optionen unter Unterstützte IPv4-Bereiche.

Wenn Sie das Subnetz löschen möchten, müssen Sie zuerst Ihre Cloud Run-Dienste, -Jobs oder -Worker-Pools löschen oder noch einmal bereitstellen, um das Subnetz nicht mehr zu verwenden. Warten Sie dann 1–2 Stunden.

IP-Adressenverbrauch für Dienste und Worker-Pools

Im stabilen Zustand verwendet Cloud Run doppelt so viele IP-Adressen wie die Anzahl der Instanzen. Wenn eine Revision herunterskaliert wird, behält Cloud Run die zugehörigen IP-Adressen bis zu 20 Minuten lang bei. Reservieren Sie insgesamt mindestens das Doppelte der Anzahl der IP-Adressen plus einen Puffer für Überarbeitungen.

Wenn Sie beispielsweise die Überarbeitungen so aktualisieren, dass revision 1 von 100 Instanzen auf null skaliert wird, während revision 2 von null auf 100 skaliert wird, behält Cloud Run die revision 1-IP-Adressen für bis zu 20 Minuten nach dem Herunterskalieren bei. Während des 20-minütigen Aufbewahrungszeitraums müssen Sie mindestens 400 IP-Adressen ((100 + 100) * 2) reservieren.

IP-Nutzung für Jobs

Bei Cloud Run-Jobs belegt jede Aufgabe für die Dauer ihrer Ausführung plus 7 Minuten nach Abschluss eine IP-Adresse. Achten Sie darauf, dass Ihr Subnetz groß genug ist, um alle gleichzeitigen Ausführungen von Job-Tasks zu ermöglichen. Es ist ein Subnetz mit einer Mindestreservierung von /26 erforderlich.

Beispiel:

• Ein Job mit einer einzelnen Aufgabe, der täglich ausgeführt wird und immer mindestens 7 Minuten vor der nächsten Ausführung abgeschlossen wird, belegt maximal eine IP-Adresse im Subnetz.
• Ein Job mit 10 Aufgaben, der alle 10 Minuten ausgeführt wird und bei dem jede Aufgabe 15 Minuten lang ausgeführt wird, verbraucht 1 IP-Adresse für 22 Minuten pro Aufgabe (bei 3 Ausführungen werden IP-Adressen gleichzeitig verwendet), wie im folgenden Beispiel gezeigt. Für den Job werden daher im stabilen Zustand 30 IP-Adressen benötigt.

  

• Für einen Job mit einer einzelnen Aufgabe, der 1 Minute dauert und 100-mal pro Minute ausgeführt wird, sind je nach genauer Ausführungszeit etwa 800 IP-Adressen erforderlich.

Unterstützte IPv4-Bereiche

Cloud Run unterstützt die folgenden IPv4-Bereiche für Ihr Subnetz:

• RFC 1918
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
• RFC 6598
  • 100.64.0.0/10
• Klasse E
  • 240.0.0.0/4

IAM-Berechtigungen einrichten

Achten Sie darauf, dass Cloud Run Zugriff auf das VPC-Netzwerk hat. Verwenden Sie dazu eine der folgenden Methoden:

• Rolle „Cloud Run-Dienst-Agent“: Standardmäßig hat der Cloud Run-Dienst-Agent die Rolle Cloud Run-Dienst-Agent (roles/run.serviceAgent), die die erforderlichen Berechtigungen enthält.

• Benutzerdefinierte Berechtigungen: Für eine detaillierte Kontrolle erteilen Sie dem Cloud Run-Dienst-Agent die folgenden zusätzlichen Berechtigungen für das Projekt:

  • compute.networks.get
  • compute.subnetworks.get
  • compute.subnetworks.use für das Projekt oder das jeweilige Subnetz
  • compute.addresses.get
  • compute.addresses.list
  • compute.addresses.createInternal
  • compute.addresses.deleteInternal
  • compute.regionOperations.get

• Rolle „Compute-Netzwerknutzer“: Wenn Sie die Standardrolle „Cloud Run-Dienst-Agent“ oder die benutzerdefinierten Berechtigungen nicht verwenden, weisen Sie die Rolle Compute-Netzwerknutzer (roles/compute.networkUser) ) für das Dienstkonto von Cloud Run-Dienst-Agent mit dem folgenden Befehl zu:

  gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com" \
  --role "roles/compute.networkUser"

  Ersetzen Sie Folgendes:

  • PROJECT_ID: die Projekt-ID.
  • PROJECT_NUMBER: Die Projektnummer, in der Sie Ihren Cloud Run-Dienst, -Job oder -Worker-Pool bereitstellen.

Cloud Run-Ressource bereitstellen

Je nach Cloud Run-Ressource finden Sie die Anleitung in einem der folgenden Abschnitte:

• Service bereitstellen
• Job erstellen
• Worker-Pool bereitstellen

Service bereitstellen

Durch ausgehenden Direct VPC-Traffic kann Ihr Cloud Run-Dienst Traffic ohne Connector für serverlosen VPC-Zugriff an ein VPC-Netzwerk senden. Die Netzwerkkosten werden wie der Dienst selbst auf null skaliert. Sie können Netzwerk-Tags auch direkt zu Cloud Run-Dienstüberarbeitungen hinzufügen, um eine detailliertere Netzwerksicherheit zu erhalten, z. B. durch Anwenden von VPC-Firewallregeln.

Sie können ausgehenden Direct VPC-Traffic mit einem Dienst über dieGoogle Cloud Console, die Google Cloud CLI, YAML oder Terraform konfigurieren.