Sie können Ihren Cloud Run -Dienst oder -Job aktivieren, um Traffic an ein VPC-Netzwerk zu senden. Verwenden Sie dazu ausgehenden Direct VPC-Traffic ; dabei ist kein Connector für Serverloser VPC-Zugriff erforderlich.
Cloud Run-Dienste und ‑Jobs unterstützen keinen eingehenden Direct VPC-Traffic. Informationen zum Konfigurieren von Direct VPC-Ingress nur für Worker-Pools finden Sie unter Eingehender Traffic für Cloud Run-Worker-Pools.
Hinweis
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 freigegebene VPC 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 Vermeidung der Ausschöpfung von IP-Adressen für die Verwendung alternativer IP-Adressbereiche.
Beschränkungen
Die folgenden Einschränkungen gelten für Cloud Run -Dienste und -Jobs:
- 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 oder die Startprüfung mit geeigneten Konfigurationen für Zeitraum und Grenzwert festgelegt werden, um als Wiederholungsversuch zu fungieren.
- 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 einSIGCONT-Signal. Nachdem der Container dasSIGCONT-Signal erhalten hat, wiederholen Sie die Verbindung. - Wenn Sie ausgehenden Direct VPC-Traffic verwenden, kann es bei Cloud NAT zu Kaltstartverzögerungen von 30 Sekunden oder mehr beim Starten von Instanzen kommen. Für eine bessere Startleistung empfehlen wir die Verwendung von Connectors für serverlosen VPC-Zugriff mit Cloud NAT.
- 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 ausgehendem Direct VPC-Traffic 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 und ‑Jobs 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.
- Das Network Intelligence Center unterstützt nur Konnektivitätstests und Flow Analyzer für IPv4- und IPv6-Subnetzbereiche.
- Cloud Run -Dienste und ‑Jobs unterstützen keinen direkten eingehenden VPC-Traffic.
Die folgenden Elemente werden vom ausgehendem Direct VPC-Traffic nicht unterstützt:
- VPC-Flusslogs geben nicht den Namen der Cloud Run-Überarbeitung an.
- Logging von VPC-Firewallregeln
- Paketspiegelung
- 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.
- Prüfen Sie den ausgehenden Traffic mit Cloud Next Generation Firewall Enterprise, z. B. mit dem Dienst zur Einbruchserkennung und -abwehr, dem URL-Filterdienst und der TLS-Prüfung.
Zuweisung von IP-Adressen
Wenn Sie Ihren Cloud Run -Dienst 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 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-Zuordnung 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 oder -Jobs löschen oder noch einmal bereitstellen, um das Subnetz nicht mehr zu verwenden. Warten Sie dann 1–2 Stunden.
IP-Adressverbrauch für Dienste
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 ihre IP-Adressen bis zu 20 Minuten lang bei. Reservieren Sie insgesamt mindestens die doppelte Anzahl an 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, belegt 22 Minuten lang 1 IP-Adresse pro Aufgabe (bei 3 Ausführungen werden IP-Adressen gleichzeitig belegt), wie im folgenden Beispiel dargestellt. 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:
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.getcompute.subnetworks.getcompute.subnetworks.usefür das Projekt oder das jeweilige Subnetzcompute.addresses.getcompute.addresses.listcompute.addresses.create(nur für Dual-Stack-Subnetze mit externen IPv6-Adressen erforderlich)compute.addresses.delete(nur für Dual-Stack-Subnetze mit externen IPv6-Adressen erforderlich)compute.addresses.createInternalcompute.addresses.deleteInternalcompute.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 zu. Für Subnetze mit externen IPv6-Adressen ist auch die Rolle Administrator öffentlicher IP-Adressen für Compute Engine (roles/compute.publicIpAdmin) erforderlich.Wenn Sie beispielsweise die Rolle „Compute Network User“ zuweisen möchten, führen Sie den folgenden Befehl aus:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.s3ns-system.iam.gserviceaccount.com" \ --role "roles/compute.networkUser"
Ersetzen Sie Folgendes:
- PROJECT_ID: die Projekt-ID.
- PROJECT_NUMBER: Die Projektnummer, in der Sie Ihre Cloud Run-Ressource bereitstellen.
Cloud Run-Ressourcen mit einem VPC-Netzwerk verbinden
Je nach Cloud Run-Ressource finden Sie die Anleitung in einem der folgenden Abschnitte:
Dienst mit einem VPC-Netzwerk verbinden
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 dieCloud de Confiance Console, die Google Cloud CLI, YAML oder Terraform konfigurieren.
Console
Rufen Sie in der Cloud de Confiance by S3NS Console Cloud Run auf:
Klicken Sie auf Dienst erstellen, wenn Sie einen neuen Dienst für die Bereitstellung konfigurieren. Wenn Sie einen vorhandenen Dienst konfigurieren und bereitstellen, klicken Sie auf den Dienst.
Wenn Sie einen neuen Dienst konfigurieren, füllen Sie die Seite mit den anfänglichen Diensteinstellungen wie gewünscht aus und klicken Sie dann auf Container, Netzwerk, Sicherheit, um die Seite zur Dienstkonfiguration zu maximieren.
Klicken Sie auf den Tab Netzwerk.
Klicken Sie auf Mit einer VPC für ausgehenden Traffic verbinden.
Klicken Sie auf Traffic direkt an eine VPC senden.
Wählen Sie im Feld Netzwerk das VPC-Netzwerk aus, an das Sie Traffic senden möchten.
Wählen Sie im Feld Subnetz das Subnetz aus, von dem Ihr Dienst IP-Adressen empfängt. Sie können mehrere Dienste im selben Subnetz bereitstellen.
Optional: Geben Sie die Namen der Netzwerk-Tags ein, die Sie Ihrem Dienst oder Ihren Diensten zuordnen möchten. Netzwerktags werden auf Versionsebene angegeben. Jede Dienstversion kann unterschiedliche Netzwerk-Tags haben, z. B.
network-tag-2.Wählen Sie für Traffic-Routing eine der folgenden Optionen:
- Nur Anfragen an private IPs an die VPC weiterleiten, um nur Traffic an interne Adressen über das VPC-Netzwerk zu senden.
- Gesamten Traffic an die VPC weiterleiten, um den gesamten ausgehenden Traffic über das VPC-Netzwerk zu senden.
Klicken Sie für einen neuen Dienst auf Erstellen. Klicken Sie für einen vorhandenen Dienst auf Unterschied ansehen und erneut bereitstellen und dann auf Änderungen bereitstellen.
Klicken Sie auf den Dienst und dann auf den Tab Netzwerk, um zu prüfen, ob sich der Dienst in Ihrem VPC-Netzwerk befindet. Netzwerk und Subnetz werden auf der VPC-Karte aufgeführt.
Sie können nun Anfragen von Ihrem Cloud Run-Dienst an eine beliebige Ressource im VPC-Netzwerk senden, je nach Ihren Firewallregeln.
gcloud
Dienst
So stellen Sie einen Cloud Run-Dienst ohne Connector über die Google Cloud CLI bereit:
Aktualisieren Sie die Komponenten von
gcloudauf die neueste Version:gcloud components update
Die Compute Engine API muss für das Projekt aktiviert sein:
gcloud services enable compute.googleapis.com
Stellen Sie Ihren Cloud Run-Dienst mit folgendem Befehl bereit:
gcloud run deploy SERVICE_NAME \ --image=IMAGE_URL \ --network=NETWORK \ --subnet=SUBNET \ --network-tags=NETWORK_TAG_NAMES \ --vpc-egress=EGRESS_SETTING \ --region=REGION
Ersetzen Sie:
- SERVICE_NAME durch den Namen Ihres Cloud Run-Dienstes.
IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat das FormatLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.- NETWORK durch den Namen Ihres VPC-Netzwerks. 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.
- SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Dienste oder Jobs im selben Subnetz bereitstellen oder ausführen.
- Optional: NETWORK_TAG_NAMES durch die durch Kommas getrennten Namen der Netzwerk-Tags ersetzen, die Sie mit einem Dienst verknüpfen 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.
- REGION durch eine Region für Ihren Dienst.
Führen Sie folgenden Befehl aus, um zu prüfen, ob sich Ihr Dienst in Ihrem VPC-Netzwerk befindet:
gcloud run services describe SERVICE_NAME \ --region=REGION
Ersetzen Sie:
SERVICE_NAMEdurch den Namen des Dienstes.REGIONdurch die Region, die Sie im vorherigen Schritt für Ihren Dienst angegeben haben.
Die Ausgabe sollte die Einstellung für Netzwerk, Subnetz und ausgehenden Traffic enthalten, zum Beispiel:
VPC access: Network: default Subnet: subnet Egress: private-ranges-only
Sie können nun Anfragen von Ihrem Cloud Run-Dienst an eine beliebige Ressource im VPC-Netzwerk senden, je nach Ihren Firewallregeln.
Funktion
So stellen Sie eine Cloud Run-Funktion ohne Connector über die Google Cloud CLI bereit:
Aktualisieren Sie die Komponenten von
gcloudauf die neueste Version:gcloud components update
Die Compute Engine API muss für das Projekt aktiviert sein:
gcloud services enable compute.googleapis.com
Stellen Sie Ihre Cloud Run-Funktion mit dem folgenden Befehl bereit:
gcloud run deploy FUNCTION_NAME \ --image=IMAGE_URL \ --network=NETWORK \ --subnet=SUBNET \ --network-tags=NETWORK_TAG_NAMES \ --vpc-egress=EGRESS_SETTING \ --region=REGION \ --function=FUNCTION_ENTRYPOINT
Ersetzen Sie:
- FUNCTION_NAME durch den Namen Ihrer Cloud Run-Funktion.
IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. Wenn Sie Artifact Registry verwenden, muss das Repository REPO_NAME bereits erstellt sein. Die URL hat das FormatLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG.- NETWORK durch den Namen Ihres VPC-Netzwerks. 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.
- SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Dienste oder Jobs im selben Subnetz bereitstellen oder ausführen.
- Optional: NETWORK_TAG_NAMES mit den kommagetrennten Namen der Netzwerk-Tags, die Sie einer Funktion zuordnen möchten. Bei Funktionen werden Netzwerk-Tags auf Versionsebene angegeben. Jede Revision 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.
- REGION durch eine Region für Ihre Funktion.
- Optional: FUNCTION_ENTRYPOINT durch den Einstiegspunkt zur Funktion in Ihrem Quellcode. Dies ist der Code, der von Cloud Run ausgeführt wird, wenn Ihre Funktion ausgeführt wird. Der Wert dieses Flags muss ein Funktionsname oder ein voll qualifizierter Klassenname sein, der in Ihrem Quellcode vorhanden ist.
Führen Sie folgenden Befehl aus, um zu prüfen, ob sich Ihre Funktion in Ihrem VPC-Netzwerk befindet:
gcloud run services describe FUNCTION_NAME \ --region=REGION
Ersetzen Sie:
FUNCTION_NAMEdurch den Namen Ihrer Funktion.REGIONdurch die Region für Ihre Funktion, die Sie im vorherigen Schritt angegeben haben.
Die Ausgabe sollte die Einstellung für Netzwerk, Subnetz und ausgehenden Traffic enthalten, zum Beispiel:
VPC access: Network: default Subnet: subnet Egress: private-ranges-only
Sie können nun Anfragen von Ihrer Cloud Run-Funktion an eine beliebige Ressource im VPC-Netzwerk senden, je nach Ihren Firewallregeln.
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. 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.
- SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Dienste oder Jobs 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.tfFolgendes hinzu:
Optional: Veröffentlichen Sie Ihren Dienst, wenn Sie den nicht authentifizierten Zugriff auf den Dienst zulassen möchten.
Job mit einem VPC-Netzwerk verbinden
Durch ausgehenden Direct VPC-Traffic kann Ihr Cloud Run-Job Traffic ohne Connector für serverlosen VPC-Zugriff an ein VPC-Netzwerk senden. Sie können auch Netzwerk-Tags direkt zu Cloud Run-Jobs hinzufügen, um eine detailliertere Netzwerksicherheit zu erhalten, z. B. durch Anwenden von VPC-Firewallregeln.
Sie können ausgehenden Direct VPC-Traffic mit einem Job über dieCloud de Confiance Console, die Google Cloud CLI oder YAML konfigurieren.
Console
Klicken Sie auf den Tab Jobs und füllen Sie die Seite mit den anfänglichen Jobeinstellungen wie gewünscht aus, wenn Sie einen neuen Job konfigurieren. Klicken Sie auf den Job und dann auf Bearbeiten, wenn Sie einen vorhandenen Job konfigurieren.
Klicken Sie auf Container, Variablen und Secrets, Verbindungen, Sicherheit, um die Seite mit den Jobattributen zu maximieren.
Klicken Sie auf den Tab Verbindungen.
Klicken Sie auf Mit einer VPC für ausgehenden Traffic verbinden.
Klicken Sie auf Traffic direkt an eine VPC senden.
Wählen Sie im Feld Netzwerk das VPC-Netzwerk aus, an das Sie Traffic senden möchten.
Wählen Sie im Feld Subnetz das Subnetz aus, von dem Ihr Job IP-Adressen empfängt. Sie können mehrere Jobs im selben Subnetz ausführen.
Wählen Sie für Traffic-Routing eine der folgenden Optionen:
- Nur Anfragen an private IPs an die VPC weiterleiten, um nur Traffic an interne Adressen über das VPC-Netzwerk zu senden.
- Gesamten Traffic an die VPC weiterleiten, um den gesamten ausgehenden Traffic über das VPC-Netzwerk zu senden.
Optional: Geben Sie die Namen der Netzwerk-Tags ein, die Sie Ihrem Dienst oder Ihren Diensten zuordnen möchten. Netzwerktags werden auf Versionsebene angegeben. Jede Dienstversion kann unterschiedliche Netzwerk-Tags haben, z. B.
network-tag-2.Optional: Geben Sie die Namen der Netzwerk-Tags ein, die Sie Ihrem Job oder Ihren Jobs zuordnen möchten. Bei Jobs werden Netzwerk-Tags auf Ausführungsebene angegeben. Jede Jobausführung kann unterschiedliche Netzwerk-Tags haben, z. B.
network-tag-2.Klicken Sie auf Erstellen oder Aktualisieren.
Klicken Sie auf den Job und dann auf den Tab Konfiguration, um zu prüfen, ob sich der Job in Ihrem VPC-Netzwerk befindet. Netzwerk und Subnetz werden auf der VPC-Karte aufgeführt.
Sie können Ihren Cloud Run-Job jetzt ausführen und Anfragen vom Job an eine beliebige Ressource im VPC-Netzwerk senden, je nach Firewallregeln.
gcloud
So erstellen Sie einen Cloud Run-Job ohne Connector über die Google Cloud CLI:
Aktualisieren Sie die Komponenten von
gcloudauf die neueste Version:gcloud components update
Die Compute Engine API muss für das Projekt aktiviert sein:
gcloud services enable compute.googleapis.com
Erstellen Sie mit folgendem Befehl einen Cloud Run-Job:
gcloud run jobs create JOB_NAME \ --image=IMAGE_URL \ --network=NETWORK \ --subnet=SUBNET \ --network-tags=NETWORK_TAG_NAMES \ --vpc-egress=EGRESS_SETTING \ --region=REGION
Ersetzen Sie:
- JOB_NAME durch den Namen Ihres Cloud Run-Jobs.
IMAGE_URL: ein Verweis auf das Container-Image, z. B.us-docker.pkg.dev/cloudrun/container/job:latest- NETWORK durch den Namen Ihres VPC-Netzwerks. 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.
- SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Dienste oder Jobs im selben Subnetz bereitstellen oder ausführen.
- Optional: Ersetzen Sie NETWORK_TAG_NAMES durch die Namen der Netzwerk-Tags, die Sie einem Job zuordnen möchten. Für Jobs werden Netzwerk-Tags auf Ausführungsebene angegeben. Jede Jobausführung 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.
- REGION durch eine Region für Ihren Job.
Führen Sie folgenden Befehl aus, um zu prüfen, ob sich der Job in Ihrem VPC-Netzwerk befindet:
gcloud run jobs describe JOB_NAME \ --region=REGION
Ersetzen Sie:
JOB_NAMEdurch den Namen des Jobs.REGIONdurch die Region für Ihren Job, die Sie im vorherigen Schritt angegeben haben.
Die Ausgabe sollte den Namen Ihres Netzwerks und des Subnetzes enthalten, zum Beispiel:
VPC network: Network: default Subnet: default
Sie können Ihren Cloud Run-Job jetzt ausführen und Anfragen vom Job an eine beliebige Ressource im VPC-Netzwerk senden, je nach Firewallregeln.
YAML
Wenn Sie einen neuen Job erstellen, überspringen Sie diesen Schritt. Wenn Sie einen vorhandenen Job aktualisieren, laden Sie die zugehörige YAML-Konfiguration herunter:
gcloud run jobs describe JOB_NAME --format export > job.yaml
Aktualisieren Sie die folgenden Attribute:
apiVersion: run.googleapis.com/v1 kind: Job metadata: name: JOB_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:
- JOB_NAME durch den Namen Ihres Cloud Run-Jobs. Jobnamen dürfen maximal 49 Zeichen lang sein und pro Region und Projekt nur einmal vorkommen.
- REGION durch die Region für Ihren Cloud Run-Job; diese muss der Region Ihres Subnetzes entsprechen.
- NETWORK durch den Namen Ihres VPC-Netzwerks. 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.
- SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Dienste oder Jobs im selben Subnetz bereitstellen oder ausführen.
- Optional: Ersetzen Sie NETWORK_TAG_NAMES durch die Namen der Netzwerk-Tags, die Sie einem Job zuordnen möchten. Für Jobs werden Netzwerk-Tags auf Ausführungsebene angegeben. Jede Jobausführung 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 Job-Container-Images.
Erstellen oder aktualisieren Sie den Dienst mit dem folgenden Befehl:
gcloud run jobs replace job.yaml
Dual-Stack (IPv4 und IPv6) einrichten
Informationen zum Hinzufügen eines Dual-Stack-Subnetzes mit einem IPv6-Bereich für eine Cloud Run-Ressource finden Sie unter Dual-Stack einrichten.
Zugriff mit Firewallregeln einschränken
Sie können den Zugriff auf Ressourcen in einem VPC-Netzwerk mithilfe von VPC-Firewallregeln einschränken. Fügen Sie diese Einschränkungen mit einer der folgenden Strategien hinzu:
- Erstellen Sie eine Firewallregel für eingehenden Traffic, die mithilfe des IP-Bereichs des Subnetzes auf Ihren Dienst oder Job verweist.
Erstellen Sie eine Firewallregel für ausgehenden Traffic, die auf Ihren Dienst oder Job verweist.
Verweisen Sie in der Firewallregel für ausgehenden Traffic auf Ihren Dienst oder Job mithilfe des verknüpften Dienstkontos Dienstidentität, des IP-Bereichs des Subnetzes oder der zugehörigen Netzwerk-Tags.
Netzwerk-Tags für ausgehenden Traffic
Mit Netzwerktags in Egress-Firewallregeln können Sie eine zusätzliche Ebene der Netzwerksicherheit hinzufügen.
Console
So ordnen Sie einem Dienst oder Job Netzwerk-Tags zu:
Rufen Sie in der Cloud de Confiance -Console die Seite Cloud Run auf.
Klicken Sie auf den Dienst oder Job, dem Sie Netzwerk-Tags zuordnen möchten, und dann bei Jobs auf Bearbeiten.
Klicken Sie für Dienste auf den Tab Netzwerk und für Jobs auf den Tab Verbindungen.
Achten Sie darauf, dass Sie Mit einer VPC für ausgehenden Traffic verbinden und Traffic direkt an eine VPC senden ausgewählt haben.
Wählen Sie im Feld Subnetz das Subnetz aus, von dem Ihr Dienst IP-Adressen empfängt. Sie können mehrere Dienste oder Jobs im selben Subnetz bereitstellen oder ausführen.
Geben Sie im Feld Netzwerk-Tags die Namen der Netzwerk-Tags ein, die Sie Ihrem Dienst oder Job zuordnen möchten.
Klicken Sie bei Jobs auf Aktualisieren. Klicken Sie bei Diensten auf Unterschied ansehen und erneut bereitstellen und dann auf Änderungen bereitstellen.
Bei Diensten kann jede Dienstversion einen anderen Satz von Netzwerk-Tags haben, da Netzwerk-Tags auf Versionsebene angegeben werden. Bei Jobs hat eine Jobausführung dieselben Netzwerk-Tags wie der Job, als die Ausführung des Jobs erstellt wurde.
gcloud
Verwenden Sie den Befehl gcloud run deploy, um einem Dienst oder Job Netzwerk-Tags zuzuweisen:
gcloud run deploy SERVICE_JOB_NAME \ --image=IMAGE_URL \ --network=NETWORK \ --subnet=SUBNET \ --network-tags=NETWORK_TAG_NAMES \ --region=REGION
Ersetzen Sie Folgendes:
- SERVICE_JOB_NAME durch den Namen Ihres Dienstes oder Jobs.
- IMAGE_URL: Die Image-URL des Dienstes oder Jobs.
- NETWORK durch den Namen Ihres VPC-Netzwerks.
- SUBNET durch den Namen Ihres Subnetzes. Geben Sie entweder ein VPC-Netzwerk oder ein Subnetz oder beides an. Wenn Sie nur ein Netzwerk angeben, verwendet das Subnetz denselben Namen wie das Netzwerk. Sie können mehrere Dienste oder Jobs im selben Subnetz bereitstellen oder ausführen.
- NETWORK_TAG_NAMES durch den Namen Ihres Netzwerk-Tags oder eine durch Kommas getrennte Liste von Netzwerk-Tags ersetzen.
- REGION durch den Namen Ihrer Region.
Bei Diensten kann jede Dienstversion einen anderen Satz von Netzwerk-Tags haben, da Netzwerk-Tags auf Versionsebene angegeben werden. Bei Jobs hat eine Jobausführung dieselben Netzwerk-Tags wie der Job, als die Ausführung des Jobs erstellt wurde.
Cloud Run-Ressource trennen
Je nach Cloud Run-Ressource finden Sie die Anleitung in einem der folgenden Abschnitte:
Dienst trennen
Console
So entfernen Sie Ihren Dienst aus dem VPC-Netzwerk:
Klicken Sie auf den Dienst.
Klicken Sie auf den Tab Netzwerk.
Heben Sie die Markierung von Mit einer VPC für ausgehenden Traffic verbinden auf.
Klicken Sie auf Unterschied ansehen und erneut bereitstellen und dann auf Änderungen bereitstellen.
Klicken Sie auf den Tab Netzwerk, um zu prüfen, dass sich der Dienst nicht mehr in Ihrem VPC-Netzwerk befindet. Netzwerk und Subnetz werden nicht mehr auf der VPC-Karte aufgeführt.
So entfernen Sie nur die Netzwerk-Tags, während der Dienst mit dem VPC-Netzwerk verbunden bleibt:
Klicken Sie auf den Dienst, der die zu entfernenden Netzwerk-Tags enthält.
Klicken Sie auf den Tab Netzwerk.
Löschen Sie die Namen der Netzwerk-Tags, die nicht mehr mit Ihrem Dienst verknüpfen sein sollen.
Klicken Sie auf Unterschied ansehen und erneut bereitstellen und dann auf Änderungen bereitstellen.
gcloud
Führen Sie folgenden Befehl aus, um Ihren Dienst aus dem VPC-Netzwerk zu entfernen:
gcloud run services update SERVICE_NAME --region=REGION \ --clear-network
Führen Sie folgenden Befehl aus, um nur die Netzwerk-Tags zu entfernen, während der Dienst mit dem VPC-Netzwerk verbunden bleibt:
gcloud run services update SERVICE_NAME --region=REGION \ --clear-network-tags
Ersetzen Sie Folgendes:
- SERVICE_NAME: Der Name Ihres Cloud Run-Dienstes.
- REGION: Die Region für Ihren Cloud Run-Dienst.
YAML
So entfernen Sie Ihren Dienst aus dem VPC-Netzwerk:
Laden Sie die YAML-Konfiguration des Dienstes herunter:
gcloud run services describe SERVICE_NAME --format export > service.yaml
Entfernen Sie folgenden Inhalt aus der
service.yaml-Datei:run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
Wo
- NETWORK ist der Name des VPC-Netzwerks.
- SUBNET: Der Name Ihres Subnetzes.
- Optional: NETWORK_TAG_NAMES: die Namen der Netzwerktags, wenn Sie diese mit einem Dienst verknüpft haben.
Stellen Sie die Dienstversion über folgenden Befehl bereit:
gcloud run services replace service.yaml
So entfernen Sie nur die Netzwerk-Tags, während der Dienst mit dem VPC-Netzwerk verbunden bleibt:
Laden Sie die YAML-Konfiguration des Dienstes herunter:
gcloud run services describe SERVICE_NAME --format export > service.yaml
Entfernen Sie die Variable
tagsaus dem Inhalt derservice.yaml-Datei und lassen Sie die Variablennetworkundsubnetworkan ihrem Ort, wie im folgenden Beispiel gezeigt:run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'
Wo
- NETWORK ist der Name des VPC-Netzwerks.
- SUBNET: Der Name Ihres Subnetzes.
Stellen Sie die Dienstversion über folgenden Befehl bereit:
gcloud run services replace service.yaml
Job trennen
Console
So entfernen Sie Ihren Job aus dem VPC-Netzwerk:
Klicken Sie auf den Job, den Sie entfernen möchten, und dann auf Neue Überarbeitung bearbeiten und bereitstellen.
Klicken Sie auf den Tab Verbindungen.
Heben Sie die Markierung von Mit einer VPC für ausgehenden Traffic verbinden auf.
Klicken Sie auf Aktualisieren.
Klicken Sie auf den Tab Konfiguration, um zu prüfen, dass sich der Job nicht mehr in Ihrem VPC-Netzwerk befindet. Netzwerk und Subnetz werden nicht mehr auf der VPC-Karte aufgeführt.
So entfernen Sie nur die Netzwerk-Tags, während der Job mit dem VPC-Netzwerk verbunden bleibt:
Klicken Sie auf den Job, der die zu entfernenden Netzwerk-Tags enthält, und dann auf Neue Überarbeitung bearbeiten und bereitstellen.
Klicken Sie auf den Tab Verbindungen.
Löschen Sie die Namen der Netzwerk-Tags, die nicht mehr mit Ihrem Job verknüpfen sein sollen.
Klicken Sie auf Aktualisieren.
gcloud
Führen Sie folgenden Befehl aus, um Ihren Job aus dem VPC-Netzwerk zu entfernen:
gcloud run jobs update JOB_NAME --region=REGION \ --clear-network
Führen Sie folgenden Befehl aus, um nur die Netzwerk-Tags zu entfernen, während der Job mit dem VPC-Netzwerk verbunden bleibt:
gcloud run jobs update JOB_NAME --region=REGION \ --clear-network-tags
Ersetzen Sie Folgendes:
- JOB_NAME: Der Name Ihres Cloud Run-Jobs.
- REGION: Die Region für Ihren Cloud Run-Job.
YAML
So entfernen Sie Ihren Job aus dem VPC-Netzwerk:
Laden Sie die YAML-Konfiguration des Jobs herunter:
gcloud run jobs describe JOB_NAME --format export > job.yaml
Entfernen Sie folgenden Inhalt aus der
job.yaml-Datei:run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
Ersetzen Sie Folgendes:
- NETWORK ist der Name des VPC-Netzwerks.
- SUBNET: Der Name Ihres Subnetzes.
- Optional: NETWORK_TAG_NAMES durch die Namen der Netzwerktags, wenn Sie diese mit einem Job verknüpft haben.
Stellen Sie den Job mit folgendem Befehl noch einmal bereit:
gcloud run jobs replace job.yaml
So entfernen Sie nur die Netzwerk-Tags, während der Job mit dem VPC-Netzwerk verbunden bleibt:
Laden Sie die YAML-Konfiguration des Jobs herunter:
gcloud run jobs describe JOB_NAME --format export > job.yaml
Entfernen Sie die Variable
tagsaus dem Inhalt derjob.yaml-Datei und lassen Sie die Variablennetworkundsubnetworkan ihrem Ort, wie im folgenden Beispiel gezeigt:run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'
Ersetzen Sie Folgendes:
- NETWORK ist der Name des VPC-Netzwerks.
- SUBNET: Der Name Ihres Subnetzes.
Stellen Sie den Job mit folgendem Befehl noch einmal bereit:
gcloud run jobs replace job.yaml
Fehlerbehebung
Subnetz kann nicht gelöscht werden
Wenn Sie ein Subnetz löschen möchten, müssen Sie zuerst alle Ressourcen löschen oder neu bereitstellen, die es verwenden. Wenn Cloud Run ein Subnetz verwendet, trennen Sie die Verbindung zum Dienst oder Job von Cloud Run vom VPC-Netzwerk oder verschieben Sie es vor dem Verschieben in ein anderes Subnetz, bevor Sie das Subnetz löschen.
Direct VPC-Subnetz für ausgehenden Traffic hat keine IPv4-Adressen mehr
Der folgende Fehler tritt auf, wenn Sie versuchen, die Bereitstellung durchzuführen:
Instance failed to start because of insufficient free IP addresses in the subnetwork SUBNET_ID when attempting to create an address in the subnetwork. Please consider moving to a subnetwork with more available IP addresses.
Wenn das Subnetz des VPC-Netzwerk keine IPv4-Adressen mehr hat, wird dies von Cloud Logging protokolliert. In diesem Fall kann Cloud Run keine weiteren Dienstinstanzen oder Jobaufgaben mehr starten, bis weitere IPv4-Adressen verfügbar sind.
Hier finden Sie Strategien zur Behebung dieses Problems.
Zugewiesene IP-Adressen anzeigen
Sie können eine reservierte Adresse nicht manuell löschen. Der folgende Fehler tritt auf, wenn Sie versuchen, eine für Cloud Run zugewiesene IP-Adresse zu löschen:
The address resource 'ADDRESS_NAME' is already being used by '//serverless.googleapis.com/projects/PROJECT_ID/locations/REGION/addressReservations/ADDRESS_NAME'
Um zu sehen, welche IP-Adressen Cloud Run zugewiesen hat, rufen Sie in derCloud de Confiance Console die Seite „IP-Adressen“ auf und suchen Sie nach Adressen, bei denen die Spalte Wird verwendet von auf Serverlos festgelegt ist.
Alternativ können Sie den folgenden Befehl über die Google Cloud CLI ausführen:
gcloud compute addresses list --filter="purpose=SERVERLESS"
Probleme mit benutzerdefinierter MTU
Wenn Probleme mit einer benutzerdefinierten MTU auftreten, verwenden Sie die Standard-MTU-Einstellung für Cloud Run.