Von Kubernetes zu Cloud Run migrieren

Cloud Run und Kubernetes verwenden beide Standard-Container-Images als Deployment-Artefakte. Sie verwenden beide ein deklaratives API-Modell mit Ressourcen, die in YAML-Dateien mit derselben Standardstruktur dargestellt werden können.

Einführung

Die Cloud Run Admin API v1 ist für eine maximale Portabilität mit Kubernetes ausgelegt. Die Cloud Run Admin API-Ressourcen haben beispielsweise die gleichen Strukturkonventionen und Attributnamen wie Kubernetes-Ressourcen. Siehe YAML-Referenz für Cloud Run-Dienste.

Die Cloud Run Admin API v1 implementiert die Knative Serving API-Spezifikation. Sie müssen jedoch nicht Knative in Ihrem vorhandenen Kubernetes-Cluster verwenden, um einige Ihrer Kubernetes-Arbeitslasten zu Cloud Run zu migrieren.

Die primäre Ressource von Cloud Run ist der Dienst. Sie können sich einen Cloud Run-Dienste als allgemeine Abstraktion vorstellen, die wie ein Kubernetes-Deployment mit einem integrierten Pod-Autoscaling und einem eindeutigen Endpunkt aussieht. Ein "Pod" in Kubernetes entspricht einer "Instanz" in Cloud Run. Wir empfehlen, Ihre Kubernetes-Deployments nacheinander in Cloud Run-Dienste zu transformieren. Sie können auch einige Konfigurationen von horizontalem Pod-Autoscaling und Kubernetes-Services mit dem Cloud Run-Dienst zusammenführen.

Cloud Run hat nicht das Konzept des Namespace. Stattdessen wird das Google Cloud-Projekt als Isolationsgrenze zwischen Ressourcen verwendet. Wenn Sie von Kubernetes zu Cloud Run migrieren, empfehlen wir, für jeden Namespace ein Google Cloud-Projekt zu erstellen. Im YAML-Format eines Cloud Run-Dienstes ist der Namespace-Wert die Google Cloud-Projektnummer.

Cloud Run hat eine integrierte zonale Redundanz. Dies bedeutet, dass Sie kein Replikat bereitstellen müssen, um zu gewährleisten, dass Ihr Dienst gegenüber einem zonalen Ausfall in der ausgewählten Google Cloud-Region resistent ist.

Kurzanleitung

Diese Kurzanleitung bietet ein einfaches Migrationsbeispiel.

Einfacher Ressourcenvergleich

Vergleichen Sie das folgende einfache Kubernetes-Deployment namens my-app mit dem entsprechenden Cloud Run-Dienst. Beachten Sie, dass die YAML-Dateien fast identisch sind.

Die Teile in blue sind unterschiedlich und müssen geändert werden. Die Teile in red sollten gelöscht werden, da Cloud Run ein integriertes Autoscaling hat.

Kubernetes-DeploymentCloud Run-Dienst
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world
  replicas: 3
  selector:
    matchLabels:
      app: my-app

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
  namespace: 'PROJECT_NUMBER'
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world

Einfaches Kubernetes-Deployment zu Cloud Run migrieren

  1. Laden Sie die YAML-Datei Ihres Deployments im aktuellen Verzeichnis mit folgendem Befehl herunter:

    kubectl get deployment  my-app -o yaml > my-app.yaml

  2. Ändern Sie die YAML-Datei so, dass sie einem Cloud Run-Dienst entspricht. Aktualisieren Sie die Datei my-app.yaml:

    • Ersetzen Sie für das Attribut kind den Wert Deployment durch Service.
    • Ersetzen Sie für das Attribut apiVersion den Wert apps/v1 durch serving.knative.dev/v1.
    • Löschen Sie das Attribut metadata.namespace oder ändern Sie seinen Wert entsprechend Ihrer Google Cloud-Projektnummer.
    • Löschen Sie spec.replicas und spec.selector.

  3. Stellen Sie die Datei my-app.yaml mit dem folgenden Befehl in Cloud Run bereit. Ersetzen Sie dabei REGION durch die gewünschte Google Cloud-Region, z. B. us-central1:

    gcloud run services replace my-app.yaml --region REGION

Das Aufrufen eines Cloud Run-Dienstes ist durch eine IAM-Berechtigung geschützt. Führen Sie den folgenden Befehl aus, wenn Sie den neuen Cloud Run-Dienst öffentlich im Internet freigeben und nicht authentifizierte Aufrufe zulassen möchten:

gcloud run services add-iam-policy-binding my-app --member="allUsers" --role="roles/run.invoker" --region REGION

Von Cloud Run nicht unterstützte Features

Es können nur Arbeitslasten migriert werden, die für Cloud Run geeignet sind.

Die folgenden Kubernetes-Features werden von Cloud Run nicht unterstützt:

  • Feste Anzahlen von replicas (Problemumgehung: Verwenden Sie dieselbe minimale und maximale Anzahl von Instanzen)
  • ConfigMaps (Problemumgehung verfügbar)
  • Benutzerdefinierte Strategien für horizontales Pod-Autoscaling
  • Diensterkennung

Wenn Sie eine YAML-Datei von einem Kubernetes-Deployment zu einem Cloud Run-Dienst migrieren, gibt der Befehl gcloud run services replace für jedes Attribut, das von Cloud Run nicht unterstützt wird, eine klare Fehlermeldung zurück. Löschen oder aktualisieren Sie diese Attribute und wiederholen Sie den Befehl, bis der Vorgang erfolgreich war.

Eine vollständige Liste der von Cloud Run unterstützten Attribute finden Sie in der YAML-Referenz.

Kubernetes-Ressourcen migrieren

Kubernetes-Secrets migrieren

Wie Kubernetes unterstützt Cloud Run das Bereitstellen von Secrets als Umgebungsvariablen oder Volumes. Secrets sollten jedoch im Secret Manager gespeichert werden.

Es gibt mehrere wichtige Unterschiede zwischen Secret Manager-Secrets und Kubernetes-Secrets:

  • Zulässige Zeichen in Namen:
  • Versionsverwaltung: Secrets aus Secret Manager werden versioniert, Kubernetes-Secrets nicht.
  • Nutzlast: Secrets von Secret Manager enthalten ein einzelnes []byte, während Kubernetes-Secrets eine map<string, string> enthalten.

Folgen Sie der Dokumentation von Secret Manager, um ein Secret zu erstellen und eine neue Secret-Version für jeden Secret-Schlüssel hinzuzufügen, von dem Ihre Kubernetes-Anwendung abhängt.

Kubernetes-ConfigMaps migrieren

In Cloud Run gibt es kein Äquivalent für Kubernetes-ConfigMaps. Da ConfigMaps jedoch als unverschlüsselte Secrets angesehen werden können, können Sie Ihre ConfigMaps stattdessen in Secrets in Secret Manager umwandeln. Weitere Informationen finden Sie unter Kubernetes-Secrets migrieren.

Kubernetes-Deployment migrieren

Das Kubernetes-Deployment ist die Ressource, die dem Cloud Run-Dienst am nächsten ist. Es empfiehlt sich, die YAML-Datei Ihres Kubernetes-Deployments zu bearbeiten und in einen Cloud Run-Dienst umzuwandeln.

Die wichtigsten Änderungen sind folgende:

  • namespace muss durch die Google Cloud-Projektnummer ersetzt werden.
  • Labels (metadata.labels und spec.template.metadata.labels) müssen gültige Google Cloud-Labels sein.
  • Container müssen in einer unterstützten Container Registry gespeichert werden.
  • Möglicherweise müssen Sie die CPU- und Arbeitsspeicherlimits anpassen.
  • Wenn Sie auf ein Secret verweisen, wird mit dem Attribut key die Version in Secret Manager erfasst, wobei latest auf die neueste Version des Secrets verweist.
  • serviceAccountName sollte auf ein Dienstkonto im aktuellen Google Cloud-Projekt verweisen.
  • Verweise auf ConfigMaps (configMapKeyRef) sollten durch Verweise auf Secrets ersetzt werden (secretKeyRef).

Wenn Ihr Kubernetes-Deployment auf andere Ressourcen in Ihrem Kubernetes-Cluster oder auf Ressourcen in einer VPC zugreift, müssen Sie den Cloud Run-Dienst mit der entsprechenden VPC verbinden.

Kubernetes-Service migrieren

Cloud Run-Dienste stellen automatisch einen eindeutigen Endpunkt bereit, der Traffic mit einem containerPort an den Container weiterleitet. Nachdem Sie Ihr Kubernetes-Deployment zu einem Cloud Run-Dienst migriert haben, müssen Sie nicht die Kubernetes-Services migrieren, die den Traffic an dieses Deployment weiterleiten.

Kubernetes-HorizontalPodAutoscaler migrieren

Cloud Run-Dienste haben ein integriertes horizontales Autoscaling: Cloud Run skaliert die Pods ("Instanzen" genannt) automatisch mithilfe einer Kombination von Faktoren innerhalb der Grenzen der definierten minimalen und maximalen Anzahl von Instanzen.

Migrieren Sie die Attribute minReplicas und maxReplicas des HorizontalPodAutoscaler zu den Annotationen autoscaling.knative.dev/minScale und autoscaling.knative.dev/maxScale des Cloud Run-Dienstes. Mehr über die Konfiguration der minimalen Anzahl von Instanzen und der maximalen von Instanzen erfahren

Kubernetes-Job migrieren

Da ein Kubernetes-Job einer Cloud Run-Jobausführung ähnelt, können Sie zu einem Cloud Run-Job migrieren und den Job ausführen.

Die folgenden Beispiele zeigen den strukturellen Unterschied zwischen einem Kubernetes-Job und einem Cloud Run-Job:

Kubernetes-JobCloud Run-Job
apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - image: us-docker.pkg.dev/cloudrun/container/job

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      template:
        spec:
          containers:
          - image: us-docker.pkg.dev/cloudrun/container/job

Migrationsstrategie

Nachdem Sie die entsprechenden Ressourcen erstellt haben, können Sie den externen Endpunkt hinter einem globalen externen Application Load Balancer verfügbar machen, um den Traffic schrittweise zwischen Cloud Run und Google Kubernetes Engine (GKE) zu migrieren.