Von Cloud Run zu Google Kubernetes Engine 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, aber Sie müssen nicht zu Knative migrieren, um Ihre Cloud Run-Arbeitslasten auf eine Kubernetes-Cluster wie GKE zu bewegen.

Kurzanleitung

Diese Kurzanleitung bietet eine einfache Migration.

Einfacher Ressourcenvergleich

Vergleichen Sie den folgenden einfachen Cloud Run-Dienst namens my-app mit der entsprechenden Bereitstellung von Kubernetes. Beachten Sie, dass die YAML-Dateien fast identisch sind.

Die Teile in blue sind allerdings unterschiedlich und müssen geändert werden. Die Teile in green sollten hinzugefügt werden.

Cloud Run-Dienst	Kubernetes-Deployment
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' spec: template: spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world	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

Cloud Run-Dienst

Kubernetes-Deployment

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

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

Einfachen Cloud Run-Dienst zu GKE migrieren

Laden Sie die YAML-Dienstdatei in das aktuelle Verzeichnis herunter:

gcloud run services describe my-app --format export > my-app.yaml

Ändern Sie die YAML-Datei so, dass sie einem Kubernetes-Deployment entspricht:
- Ersetzen Sie für das Attribut kind den Wert Service durch Deployment.
- Ersetzen Sie für das Attribut apiVersion den Wert serving.knative.dev/v1 durch apps/v1.
- Ersetzen Sie metadata.namespace durch den Namespace des GKE-Clusters, in dem Sie die Bereitstellung vornehmen möchten, z. B. default.
- Fügen Sie ein neues Label unter metadata und spec.template.metadata hinzu.
- Legen Sie eine feste Anzahl von Instanzen ("Replikate") mit spec.template.spec.replicas fest und legen Sie eine Labelauswahl in spec.template.spec.selector fest.
Installieren Sie und verwenden Sie das kubectl-Befehlszeilentool, um die Datei my-app.yaml in Ihrem GKE-Cluster bereitzustellen:
```
kubectl apply -f ./my-app.yaml
```

Geben Sie das Deployment als Dienst frei:

kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080

Überlegungen bei der Migration von Cloud Run zu GKE

Cluster

Cloud Run ist eine vollständig verwaltete Plattform, während GKE mehr Plattformverwaltung erfordert. Wenn Sie noch keinen GKE-Cluster erstellt haben, verwenden Sie GKE Autopilot.
Die Skalierbarkeit von GKE-Arbeitslasten ist durch die Größe des Clusters eingeschränkt. Wenn Sie keinen Autopilot-Cluster verwenden, sollten Sie die automatische Knotenbereitstellung und einen Cluster Autoscaler verwenden, um die Größe des Clusters zu ändern.
Cloud Run bietet eineIntegrierte zonale Redundanz Migrieren Sie daher zu einerregionaler Cluster und stellen Sie genügend Replikate bereit, um sicherzustellen, dass Ihr Dienst gegen einen zonalen Ausfall in der ausgewählten Google Cloud-Region resistent ist.

Preise

Cloud Run berechnet genutzte Ressourcen, während GKE bereitgestellte Ressourcen für sie bereitstellt.

Sicherheit

Im Gegensatz zu Cloud Run unterliegt das Aufrufen eines GKE-Dienstes nicht einer IAM-Aufrufer-Berechtigung.
Da GKE keine starke Isolation zwischen Containern bietet, sollten Sie die Verwendung von GKE Sandbox in Betracht ziehen, wenn Sie unbekannten oder nicht vertrauenswürdigen Code ausführen müssen.

Netzwerk

Cloud Run benötigt einen Connector für serverlosen VPC-Zugriff, um auf andere Ressourcen in einer VPC zuzugreifen. GKE-Arbeitslasten befinden sich direkt in einer VPC und benötigen keinen Connector.

Von Google Kubernetes Engine nicht unterstützte Features

Die folgenden Cloud Run-Funktionen sind in GKE nicht verfügbar:

Konfigurationsversionsverwaltung über Überarbeitungen
Trafficaufteilung für graduelle Rollouts und Rollbacks von Überarbeitungen
CPU nur während der Anfrageverarbeitung zugewiesen
CPU-Boost
Sitzungsaffinität
Labels auf GKE-Arbeitslasten sind keine Google Cloud-Labels
Tags auf Arbeitslasten

Cloud Run-Ressourcen migrieren

In den folgenden Abschnitten werden Migrationsressourcen beschrieben, die in Cloud Run verwendet werden, z. B. Cloud Run-Dienste, -Jobs und -Secrets.

Cloud Run-Dienste migrieren

Sie können einen Cloud Run-Dienst zu den folgenden Ressourcen in GKE migrieren:

Kubernetes-Bereitstellung zum Erstellen von Instanzen (in Kubernetes „Pods“ genannt).
Kubernetes-Dienste, um das Deployment an einem bestimmten Endpunkt freizugeben.
Horizontales Pod-Autoscaling von Kubernetes: Automatische Skalierung der Bereitstellung

Die Attribute einer Kubernetes-Bereitstellung sind den Attributen eines Cloud Run-Dienstes übergeordnet. Wie in der Kurzanleitung gezeigt, müssen Sie nach dem Ändern der Attribute apiVersion und kind in apps/v1 und Deployment auch Folgendes ändern:

Ersetzen Sie namespace durch den GKE-Cluster-Namespace, in dem die Bereitstellung erfolgen soll, z. B. default.
serviceAccountName sollte auf ein Kubernetes-Dienstkonto verweisen, das optional als IAM-Dienstkonto mit der Workload Identity Federation for GKE fungieren kann.
Fügen Sie unter metadata.labels und spec.template.metadata.labels einen LABEL hinzu, der zum Auswählen des Deployments und der Pods verwendet wird. Beispiele: app: NAME
Unter spec.template:
- Fügen Sie das Attribut replicas hinzu, um eine Anzahl von "Instanzen" anzugeben.
- Fügen Sie das Attribut selector.matchLabels hinzu, das für das Label LABEL auswählt.
Wenn Ihr Cloud Run-Dienst Secrets bereitstellt, finden Sie weitere Informationen unter Secrets migrieren.
Wenn der migrierte Cloud Run-Dienst auf Ressourcen in einer Virtual Private Cloud zugreift, müssen Sie keinen Connector für serverlosen VPC-Zugriff verwenden.

Nachdem Sie das Kubernetes-Deployment erstellt haben, erstellen Sie einen Kubernetes-Dienst für die Bereitstellung:

apiVersion: v1
kind: Service
metadata:
  name: NAME
spec:
  selector:
    LABEL
  ports:
    - protocol: TCP
      port: 80
      targetPort: PORT

Ersetzen Sie:

NAME durch den Namen des Dienstes.
LABEL durch das in der Bereitstellung definierte Label. Beispiel: app: NAME.
PORT ist der containerPort des Containers, der Anfragen im Cloud Run-Dienst empfängt. Der Standardwert ist 8080.

Anschließend können Sie optional ein horizontales Kubernetes Pod-Autoscaling erstellen, um die Anzahl der Pods automatisch zu skalieren. Folgen Sie der Dokumentation zu Horizontalem Pod-Autoscaling in Kubernetes, um einen HorizontalPodAutoscaler zu erstellen. Verwenden Sie die Werte für die Mindestinstanzen (autoscaling.knative.dev/minScale) und die maximale Anzahl von Instanzen (autoscaling.knative.dev/maxScale) Ihres Cloud Run-Dienstes als Werte für die minReplicas und maxReplicas Attribute HorizontalPodAutoscaler.

Cloud Run-Jobs migrieren

Sie können einen Cloud Run-Job zu einem Kubernetes-Job in GKE migrieren.

Im Gegensatz zu Cloud Run-Jobs werden Kubernetes-Jobs beim Erstellen ausgeführt. Wenn Sie den Job noch einmal ausführen möchten, müssen Sie einen neuen Job erstellen.

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

Cloud Run-Job	Kubernetes-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	apiVersion: batch/v1 kind: Job metadata: name: my-job spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job

Cloud Run-Job

Kubernetes-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

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

Secrets migrieren

Sie können vorhandene Secrets in Secret Manager beibehalten oder zu Kubernetes-Secrets migrieren.

Wenn Sie Secrets in Secret Manager behalten möchten, müssen Sie Ihre Verwendung in GKE aktualisieren.

Beachten Sie die folgenden Unterschiede zwischen Secret Manager- und Kubernetes-Secrets, wenn Sie sich von Secret Manager zu Kubernetes-Secrets migrieren:

Zulässige Zeichen in Namen:
- Kubernetes-Secrets: [a-z0-9-.]{1,253}
- Secret Manager-Secrets: [a-zA-Z0-9_-]{1,255}
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.

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.