Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Verwenden Sie diese Anleitung, um Ihre Arbeitslasten zu Cloud Run zu migrieren. Im Allgemeinen müssen Sie bei der Migration Ihrer Arbeitslasten alle Kubernetes-basierten Features portieren und dann alle vorhandenen Dienste in Cloud Run noch einmal bereitstellen.
Hauptvorteile der Migration zu Cloud Run:
Vollständig verwaltetes serverloses Produkt, das die Knative Serving API-Spezifikation implementiert und sich an den Containervertrag hält.
Mit IAM in Cloud Run haben Sie die gleiche Kontrolle über den Zugriff auf Ihre Ressourcen. Ziehen Sie auch die Verwendung der Dienstidentität in Betracht.
Hinweise zur Migration
Sie müssen die folgenden Unterschiede zwischen den Produkten prüfen und verstehen, damit Sie alle Abhängigkeiten und Anforderungen portieren können.
Secrets
In Cloud Run können Sie Secrets als Umgebungsvariablen oder Volumes bereitstellen. Secrets mit vertraulichen Informationen sollten jedoch im Secret Manager gespeichert werden.
Die Cloud Run DomainMapping API ist mit Knative Serving kompatibel. Cloud Run bietet jedoch Domainzuordnung in einer Teilmenge der verfügbaren Cloud Run-Standorte.
Eine empfohlene Alternative besteht darin, den globalen HTTP(S)-Load-Balancer für Ihre benutzerdefinierten Domains zu verwenden.
VPC-Konnektivität
Cloud Run-Dienste befinden sich außerhalb Ihrer VPC. Für die Kommunikation mit Ressourcen innerhalb einer VPC müssen Sie den Connector für serverlosen VPC-Zugriff verwenden.
Steuerelemente für eingehenden Traffic
Wenn Ihr Knative Serving-Dienst für ein privates internes Netzwerk konfiguriert ist und einen internen Load Balancer (ILB) verwendet, können Sie Ihren Cloud Run-Dienst auf Ingress = Internal konfigurieren.
Wenn Sie Ihre Dienste auf internal konfigurieren, wird der Zugriff innerhalb Ihrer VPC oder anderer Cloud Run-Dienste eingeschränkt.
Dienst-zu-Dienst-Kommunikation
Dienst migrieren
Zum Migrieren eines Dienstes müssen Sie Ihren Knative Serving-Dienst exportieren, die exportierte YAML-Datei bearbeiten und dann den neu konfigurierten Dienst in Cloud Run bereitstellen.
Exportieren Sie Ihren Knative Serving-Dienst mit dem folgenden Befehl in eine lokale YAML-Datei:
SERVICE durch den Namen Ihres Knative Serving-Dienstes.
NAMESPACE durch den Namespace, in dem Ihr Dienst ausgeführt wird.
CLUSTER durch den Namen des Clusters, in dem Ihr Dienst ausgeführt wird.
FILENAME durch einen eindeutigen Dateinamen Ihrer Wahl.
Ändern Sie die exportierte Datei FILENAME.yaml für Cloud Run:
Sie müssen den Kubernetes-Namespace suchen und durch die ID Ihres Google Cloud-Projekts ersetzen. Ersetzen Sie beispielsweise namespace:default durch namespace:my-unique-id.
Konfigurieren Sie den Zugriff auf Ihren Cloud Run-Dienst:
Standardmäßig ist ein Cloud Run-Dienst nicht extern zugänglich. Wenn Sie Ihren Dienst im Internet freigeben und nicht authentifizierte Anfragen zulassen möchten, müssen Sie den öffentlichen (nicht authentifizierten) Zugriff zulassen.
Informationen zum Konfigurieren dieses Dienstes für rein internen Zugriff wie zwischen Ihren Cloud Run-Diensten finden Sie unter Dienst-zu-Dienst-Authentifizierung.
Sie können in der Google Cloud Console auf der Seite „Dienste” auf den angezeigten URL-Link klicken, um den eindeutigen und stabilen Endpunkt Ihres bereitgestellten Dienstes zu öffnen.
Nachdem Sie Ihre neu bereitgestellten Dienste getestet haben und für die Migration des gesamten Produktionstraffics bereit sind, können Sie Ihre benutzerdefinierte Domain konfigurieren und Ihre DNS-Einträge mit Ihrem Registrator aktualisieren. Folgen Sie der Anleitung unter Benutzerdefinierte Domains zuordnen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-04-22 (UTC)."],[],[],null,["# Migrating a Knative serving service to Cloud Run\n\nUse this guide to migrate your workloads to Cloud Run. In general,\nmigrating your workloads requires you to port over any of the Kubernetes-based\nfeatures and then redeploy each of your existing services to Cloud Run.\n\nKey benefits of migrating to Cloud Run:\n\n- Fully managed serverless product that implements the\n [Knative Serving API specification](https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md)\n and adheres to the container contract.\n\n- The [v1 Admin API of Cloud Run](/run/docs/reference/rest) is designed\n to maximize portability with Knative serving.\n\n- The user experience is similar across Cloud Run and Knative serving:\n\n - The `gcloud run` command group is used across both products.\n - Similar user interface layout and behavior in Google Cloud console.\n\nBefore you begin\n----------------\n\nThe following Google Kubernetes Engine features are not supported in Cloud Run,\nincluding:\n\n- Cluster and pod features, for example [Startup, Liveness and Readiness\n probes, and Service Discovery](/kubernetes-engine/docs/concepts/kubernetes-engine-overview).\n- Configuration:\n - [ConfigMaps](/anthos/run/archive/docs/configuring/using-configmaps) - You can transform your ConfigMaps into secrets with Secret Manager.\n - [NVIDIA GPUs](/anthos/run/archive/docs/configuring/compute-power-gpu)\n- Access controls:\n\n - [GKE specific IAM\n roles](/anthos/run/docs/deploying#permissions_required_to_deploy)\n - [Workload Identity](/anthos/run/archive/docs/configuring/workload-identity)\n - [Cluster multi-tenancy](/anthos/run/archive/docs/multi-tenancy)\n\n You can use\n [IAM in Cloud Run](/run/docs/securing/managing-access)\n to achieve the same control over access to your resources. Also consider\n using [Service identity](/run/docs/securing/service-identity).\n\nMigration considerations\n------------------------\n\nYou must review and understand the following differences across the products to\nensure that you can port over all your dependencies and requirements.\n\n### Secrets\n\nIn Cloud Run, you can choose to mount secrets as environment variables\nor volumes, but secrets with sensitive information should be stored in\n[Secret Manager](/secret-manager).\n\nImportant differences between\n[secrets in Secret Manager](/secret-manager/docs/overview) and\n[Kubernetes secrets](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names):\n\nLearn how to use Secret Manager to\n[create versioned secrets](/secret-manager/docs/creating-and-accessing-secrets#create)\nfor the secret keys of your Knative serving services.\n\n### Networking\n\nUse the following information to help you port over your existing network\nconfiguration to Cloud Run.\n\nService Endpoints\n: The\n [Kubernetes Endpoints](/kubernetes-engine/docs/concepts/service#service_endpoints)\n of your Knative serving services are not supported in Cloud Run.\n [Learn more about the unique endpoints in Cloud Run](/run/docs/resource-model).\n\nDomains Mappings\n: The Cloud Run\n [DomainMapping API](/run/docs/reference/rest/v1/namespaces.domainmappings#DomainMapping)\n is compatible with Knative serving. However, Cloud Run offers\n domain mapping in a subset of the available\n [Cloud Run locations](/run/docs/locations#domains).\n A recommended alternative is to leverage\n [Global HTTP(S) Load Balancer](/run/docs/mapping-custom-domains) for your\n custom domains.\n\nVPC connectivity\n: Cloud Run services reside outside your VPC. To communicate with\n resources within a VPC, you must use the\n [Serverless VPC Access Connector](/run/docs/securing/using-vpc-service-controls).\n\nIngress controls\n: If your Knative serving service is configured for a private internal\n network and uses an internal load balancer (ILB), you can configure your\n Cloud Run service to [`Ingress = Internal`](/run/docs/securing/ingress).\n Configuring your services to `internal` restricts access to within your VPC or\n other Cloud Run services.\n [Learn more about service to service communication](/run/docs/authenticating/service-to-service).\n\nMigrating a service\n-------------------\n\nTo migrate a service, you must export your Knative serving service, edit\nthe exported YAML file, and then deploy your reconfigured service to\nCloud Run.\n| **Note:** If you obtain and use the [original YAML configuration file](/anthos/run/docs/deploying#yaml) that you initially created for Knative serving, you can skip the export and modify steps. With the original YAML configuration file, you can simply [deploy it directly to Cloud Run](#deploy) to create your services.\n\n1. Export your Knative serving service to a local YAML file by running\n the following command:\n\n gcloud run services describe \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e --format export --namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e --cluster \u003cvar translate=\"no\"\u003eCLUSTER\u003c/var\u003e --platform gke \u003e \u003cvar translate=\"no\"\u003eFILENAME\u003c/var\u003e.yaml\n\n Replace:\n - \u003cvar translate=\"no\"\u003eSERVICE\u003c/var\u003e with the name of your Knative serving service.\n - \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e with the namespace where your service is running.\n - \u003cvar translate=\"no\"\u003eCLUSTER\u003c/var\u003e with the name of the cluster where your service is running.\n - \u003cvar translate=\"no\"\u003eFILENAME\u003c/var\u003e with a unique filename of your choice.\n2. Modify the exported \u003cvar translate=\"no\"\u003eFILENAME\u003c/var\u003e`.yaml` file for\n Cloud Run:\n\n - You must search and replace the Kubernetes namespace with the ID of your Google Cloud project. For example, you must replace `namespace:`*`default`* with `namespace:`**`my-unique-id`**.\n - You must update all configurations for any of the [unsupported features](#before_you_begin).\n - You must delete any of the following attributes and their values:\n\n - `metadata.annotations.kubectl.kubernetes.io/last-applied-configuration`\n - `metadata.managedFields`\n - `spec.template.spec.containers.readinessProbes`\n - `spec.template.spec.enableServiceLinks`\n\n For example, you might need to remove the following configuration from\n under the `spec:` \\\u003e `template:` \\\u003e `spec:` \\\u003e `containers:` attributes: \n\n ...\n readinessProbe:\n successThreshold: 1\n tcpSocket: {}\n ...\n\n3. Deploy the modified `.yaml` file to Cloud Run using the\n `--platform managed` flag. [Learn more about deploying](/run/docs/deploying).\n\n Note that you can use the same Google Cloud project for Cloud Run. \n\n gcloud run services replace \u003cvar translate=\"no\"\u003eFILENAME\u003c/var\u003e.yaml --platform managed --region \u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e\n\n Replace:\n - \u003cvar translate=\"no\"\u003eFILENAME\u003c/var\u003e with the name of the exported configuration file that you created.\n - \u003cvar translate=\"no\"\u003eREGION\u003c/var\u003e with a [supported\n Cloud Run location](/run/docs/locations). For example: `us-central1`\n4. Configure access to your Cloud Run service:\n\n - By default, a Cloud Run service is not externally accessible. To\n publicly expose your service to the internet and allow unauthenticated\n requests, you must\n [allow public (unauthenticated) access](/run/docs/authenticating/public).\n\n - To configure this service for private internal-only access like between\n your Cloud Run services, see\n [Authenticating service-to-service](/run/docs/authenticating/service-to-service).\n\n5. In the Google Cloud console, within your services page, you can click the\n displayed URL link to open the unique and stable endpoint of your deployed\n service.\n\n [Go to Cloud Run](https://console.cloud.google.com/run)\n\nMigrating traffic to your service\n---------------------------------\n\nAfter you have tested your newly deployed services and are ready to migrate all\nof your production traffic, you can configure your custom domain and update your\nDNS records with your registrar. Follow the instructions at\n[Mapping custom domains](/run/docs/mapping-custom-domains)."]]
