In diesem Leitfaden werden die neuesten und ursprünglichen Google Cloud Optionen für die Bereitstellung von Funktionen verglichen. Auf dieser Seite finden Sie Informationen für Nutzer, die zuvor Funktionen mit der Cloud Functions API erstellt haben und zur Cloud Run Admin API wechseln. Auf dieser Seite werden die wichtigsten Unterschiede in verschiedenen Bereichen wie Konzepten, Konfiguration, Bereitstellung sowie Triggern und Wiederholungen beschrieben.
Vergleich
Es gibt zwei Versionen von Cloud Run Functions:
Cloud Run Functions ist die neueste Version von Funktionen, die als Dienst in Cloud Run bereitgestellt werden. Sie können auf eine der folgenden Arten erstellt werden:
- Cloud Run Admin API (empfohlen): Mit dieser API erstellte Funktionen (z. B. mit derGoogle Cloud Console,
gcloud run
, der REST API oder Terraform) können ausschließlich über die Cloud Run Admin API verwaltet werden. - Cloud Functions v2 API: Mit dieser API erstellte Funktionen (z. B. mit
gcloud functions
, der REST API oder Terraform) können sowohl mit der Cloud Run Admin API als auch mit der Cloud Functions v2 API verwaltet werden. Wenn Sie diese API verwenden, geben Sie den Trigger beim Bereitstellen der Funktion an. Hier erfahren Sie, wie Sie eine Funktion der v2 API trennen, damit sie ausschließlich über die Cloud Run Admin API verwaltet werden kann.
- Cloud Run Admin API (empfohlen): Mit dieser API erstellte Funktionen (z. B. mit derGoogle Cloud Console,
Cloud Run Functions (1. Generation), früher Cloud Functions (1. Generation), ist die ursprüngliche Version von Funktionen mit eingeschränkten Ereignistriggern, Laufzeiten und Konfigurierbarkeit. Informationen zum Upgraden von Funktionen der 1. Generation auf Cloud Run
Wenn Sie Funktionen direkt in Cloud Run bereitstellen, werden sie automatisch als Container erstellt und als Cloud Run-Dienst bereitgestellt.
Konzepte
In der folgenden Tabelle werden die konzeptionellen Unterschiede für Funktionen zusammengefasst.
Cloud Run Functions | Cloud Run-Funktionen (1. Generation) | |
---|---|---|
Früherer Produktname | Cloud Functions (2nd gen) | Cloud Functions (1. Generation) |
Ressourcenmodell | Eine Funktion ist ein Cloud Run-Dienst, der aus Quellcode bereitgestellt wird. | Eine Funktion wird aus Quellcode bereitgestellt. |
Terminologie für Funktionstypen |
|
|
Zugewiesene HTTPS-URL | run.app Funktionen, die mit der Cloud Functions v2 API erstellt wurden, haben auch einen cloudfunctions.net -Endpunkt. |
cloudfunctions.net |
Image-Registry | Nur Artifact Registry | Artifact Registry oder Container Registry (eingestellt) |
IAM-Rollen für die Bereitstellung |
|
|
Interne Infrastruktur | Cloud Run | Google intern |
Preismodell | Cloud Run-Preise | Preise für Cloud Run-Funktionen (1. Generation) |
Konfiguration
Cloud Run erstellt Funktionen in Containern und stellt sie als Dienste bereit. Wenn Sie eine Funktion in Cloud Run bereitstellen, haben Sie vollständigen Zugriff und Kontrolle über das Verhalten der Funktion. Sie können beispielsweise Direct VPC aktivieren, GPUs konfigurieren und Volume-Mounts verwenden.
In der folgenden Tabelle sind die Konfigurationsunterschiede für Funktionen zusammengefasst:
Cloud Run Functions | Cloud Run-Funktionen (1. Generation) | |
---|---|---|
Zeitüberschreitung bei Anfrage |
|
|
Instanzgröße | Bis zu 16 GiB RAM mit 4 vCPUs | Bis zu 8 GB RAM mit 2 vCPUs |
Gleichzeitigkeit | Bis zu 1.000 gleichzeitige Anfragen pro Funktionsinstanz | 1 gleichzeitige Anfrage pro Funktionsinstanz |
Traffic-Aufteilung | Unterstützt | Nicht unterstützt |
Bereitstellung
Seit August 2024 können Sie Cloud Run verwenden, um Funktionen bereitzustellen und zu verwalten, die mit der Cloud Functions V2 API erstellt wurden. Diese Änderung hat folgende Auswirkungen:
- Funktionsmetadaten wie die Laufzeit-ID und Build-Konfigurationen werden in der Cloud Run-Dienstdefinition gespeichert.
- Sie können Ihre Funktion sicher mit der Cloud Run Admin API bearbeiten.
- Sie können sich auf die Cloud Run-Dienstdefinition als Quelle für Ihre Funktion verlassen.
Mit der Cloud Functions API können jedoch keine Funktionen geändert werden, die mit der Cloud Run Admin API erstellt wurden.
In der folgenden Tabelle sind die Unterschiede beim Erstellen, Bereitstellen, Bearbeiten und Verwalten von Funktionen zusammengefasst:
Cloud Run Functions | Cloud Run-Funktionen (1. Generation) | |
---|---|---|
Google Cloud Console | Cloud Run | Cloud Run-Funktionen (1. Generation) |
Cloud SDK |
|
|
REST API |
|
|
Terraform |
|
Trigger und Wiederholungsversuche
In der folgenden Tabelle werden Trigger und Wiederholungsversuche für Funktionen verglichen:
Cloud Run Functions | Cloud Run-Funktionen (1. Generation) | |
---|---|---|
Funktion auslösen und aufrufen | Bei Funktionen, die mit der Cloud Run Admin API erstellt wurden, geben Sie Trigger beim Bereitstellen der Funktion an. Dies kann in der Google Cloud Console oder nach der Bereitstellung der Funktion mit der gcloud CLI erfolgen. Bei Funktionen, die mit der Cloud Functions v2 API erstellt wurden, geben Sie Trigger im Rahmen der Funktionsbereitstellung an. |
Sie geben Trigger im Rahmen der Funktionsbereitstellung an. |
Ereignistypen | Unterstützung für jeden von Eventarc unterstützten Ereignistyp, einschließlich über 90 Ereignisquellen über Cloud-Audit-Logs. | Direkte Unterstützung für Ereignisse aus 7 Quellen: |
Neuversuche | Aktualisieren Sie für Funktionen, die mit der Cloud Run Admin API erstellt wurden, die Wiederholrichtlinie in Eventarc und konfigurieren Sie ein Thema für unzustellbare Nachrichten in Pub/Sub. Bei Funktionen, die mit der Cloud Functions v2 API erstellt wurden, geben Sie Wiederholungsversuche als Teil der Funktionsbereitstellung mit dem Flag --retry an.
|
Sie geben Wiederholungsversuche im Rahmen der Funktionsbereitstellung mit dem Flag --retry an. |
Funktion trennen
Funktionen, die mit der Cloud Functions v2 API erstellt wurden (z. B. mit gcloud functions
, der REST API oder Terraform), können von ihrer vorhandenen API-Umgebung getrennt werden. Nachdem Sie eine Funktion getrennt haben, können Sie sie nur noch über die Cloud Run Admin API verwalten. Das kann sinnvoll sein, wenn Ihre Arbeitslasten innerhalb der run.googleapis.com
API-Grenze für Assured Workloads bleiben müssen oder wenn Sie sicherstellen möchten, dass Ihre Arbeitslasten die Cloud Run-SKU verwenden.
Weitere Informationen finden Sie unter Funktionen verwalten.