Esegui la migrazione da Cloud Run a Google Kubernetes Engine

Cloud Run e Kubernetes utilizzano entrambi immagini container standard come artefatti di deployment e un modello API dichiarativo con risorse che possono essere rappresentate in file YAML con la stessa struttura standard.

Introduzione

L'API Cloud Run Admin v1 è progettata per massimizzare la portabilità con Kubernetes. Ad esempio, le risorse dell'API Cloud Run Admin condividono le stesse convenzioni di struttura e gli stessi nomi degli attributi delle risorse Kubernetes. Consulta il riferimento YAML del servizio Cloud Run.

L'API Cloud Run Admin v1 implementa la specifica dell'API Knative Serving, ma non è necessario eseguire la migrazione a Knative per spostare i workload di Cloud Run in un cluster Kubernetes come GKE.

Guida rapida

Questa guida rapida è un esempio di migrazione semplice.

Confronto semplice delle risorse

Confronta il seguente semplice servizio Cloud Run denominato my-app con il deployment Kubernetes equivalente. Nota che i file YAML sono quasi identici.

Tuttavia, le parti in blue sono diverse e devono essere modificate. Le parti in green devono essere aggiunte.

Servizio Cloud RunDeployment Kubernetes
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

Esegui la migrazione di un servizio Cloud Run a GKE

  1. Scarica il file YAML del servizio nella directory attuale:

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

  2. Modifica il file YAML in modo che corrisponda a un deployment Kubernetes:

    • Per l'attributo "kind": sostituisci il valore "Service" con "Deployment"
    • Per l'attributo "apiVersion": sostituisci il valore "serving.knative.dev/v1" con "apps/v1"
    • Sostituisci metadata.namespace con lo spazio dei nomi del cluster GKE in cui vuoi eseguire il deployment, ad esempio default.
    • Aggiungi una nuova etichetta in metadata e spec.template.metadata.
    • Imposta un numero fisso di istanze ("repliche") utilizzando spec.template.spec.replicas e imposta un selettore di etichette in spec.template.spec.selector.

  3. Installa e utilizza lo strumento a riga di comando kubectl per eseguire il deployment del file my-app.yaml nel tuo cluster GKE:

    kubectl apply -f ./my-app.yaml

  4. Esponi il deployment come servizio:

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

Considerazioni sulla migrazione da Cloud Run a GKE

Cluster:

Prezzi

Cloud Run addebita le risorse utilizzate, mentre GKE addebita le risorse di cui è stato eseguito il provisioning.

Sicurezza:

  • A differenza di Cloud Run, la chiamata di un servizio GKE non è soggetta a un'autorizzazione invoker IAM.

  • Poiché GKE non fornisce un isolamento efficace tra i container, valuta l'utilizzo di GKE Sandbox se devi eseguire codice sconosciuto o non attendibile.

Networking

Cloud Run richiede un connettore di accesso VPC serverless per accedere ad altre risorse in un VPC. I workload GKE si trovano direttamente in un VPC e non richiedono un connettore.

Funzionalità non supportate da Google Kubernetes Engine

Le seguenti funzionalità di Cloud Run non sono disponibili su GKE:

Esegui la migrazione delle risorse Cloud Run

Le sezioni seguenti descrivono la migrazione delle risorse utilizzate in Cloud Run, come servizi, job e secret di Cloud Run.

Esegui la migrazione dei servizi Cloud Run

Puoi eseguire la migrazione di un servizio Cloud Run alle seguenti risorse su GKE:

  1. Deployment Kubernetes per creare istanze (chiamate "pod" in Kubernetes).
  2. Servizi Kubernetes per esporre il deployment in un endpoint specifico.
  3. Horizontal Pod Autoscaler di Kubernetes: per la scalabilità automatica del deployment.

Gli attributi di un deployment Kubernetes sono un superset degli attributi di un servizio Cloud Run. Come mostrato nella guida rapida, dopo aver modificato gli attributi apiVersion e kind in apps/v1 e Deployment, devi anche modificare quanto segue:

  • Sostituisci namespace con lo spazio dei nomi del cluster GKE in cui eseguire il deployment, ad esempio default.
  • serviceAccountName deve fare riferimento a un account di servizio Kubernetes, che può facoltativamente fungere da account di servizio IAM con Workload Identity Federation for GKE.
  • Aggiungi un LABEL in metadata.labels e spec.template.metadata.labels che verrà utilizzato per selezionare il deployment e i pod. Ad esempio: app: NAME
  • In spec.template:
    • Aggiungi un attributo replicas per specificare un numero di "istanze".
    • Aggiungi un attributo selector.matchLabels che seleziona l'etichetta LABEL.
  • Se il tuo servizio Cloud Run monta secret, consulta Esegui la migrazione dei secret.
  • Se il servizio Cloud Run di cui è stata eseguita la migrazione accedeva alle risorse su un Virtual Private Cloud, non è necessario utilizzare un connettore di accesso VPC serverless.

Dopo aver creato il deployment Kubernetes, crea un servizio Kubernetes per esporlo:

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

Sostituisci:

  • NAME: con il nome del tuo servizio.
  • LABEL: con l'etichetta definita nel deployment. Ad esempio app: NAME.
  • PORT: con il valore containerPort del container che riceve le richieste nel servizio Cloud Run, il cui valore predefinito è 8080.

In seguito, puoi creare facoltativamente un Horizontal Pod Autoscaler di Kubernetes per scalare automaticamente il numero di pod. Segui la documentazione sulla scalabilità automatica orizzontale dei pod di Kubernetes per creare un HorizontalPodAutoscaler. Utilizza i valori numero minimo di istanze (autoscaling.knative.dev/minScale) e numero massimo di istanze (autoscaling.knative.dev/maxScale) del tuo servizio Cloud Run come valori per gli attributi minReplicas e maxReplicas HorizontalPodAutoscaler.

Esegui la migrazione dei pool di worker Cloud Run

Puoi eseguire la migrazione di un pool di worker Cloud Run a un deployment Kubernetes su GKE.

I seguenti esempi mostrano la differenza strutturale tra un pool di worker Cloud Run e un deployment Kubernetes.

Pool di worker Cloud RunDeployment Kubernetes
apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
  name: my-app
  annotations:
    run.googleapis.com/manualInstanceCount: '1'
spec:
template:
    metadata:
      labels:
      app: my-app
    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

Esegui la migrazione dei job Cloud Run

Puoi eseguire la migrazione di un job Cloud Run a un job Kubernetes su GKE.

A differenza dei job Cloud Run, i job Kubernetes vengono eseguiti quando vengono creati. Se vuoi eseguire nuovamente il job, devi crearne uno nuovo.

I seguenti esempi mostrano la differenza strutturale tra un job Cloud Run e un job Kubernetes:

Job Cloud RunJob Kubernetes
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

Esegui la migrazione dei secret

Puoi conservare i secret esistenti in Secret Manager o eseguirne la migrazione ai secret di Kubernetes.

Se scegli di conservare i secret in Secret Manager, dovrai aggiornare il modo in cui li utilizzi su GKE

Se scegli di eseguire la migrazione da Secret Manager ai secret di Kubernetes, considera queste differenze tra i secret di Secret Manager e i secret di Kubernetes:

  • Caratteri consentiti nei nomi:
  • Controllo delle versioni: i secret di Secret Manager sono sottoposti a controllo delle versioni, mentre i secret di Kubernetes no.
  • Payload: i secret di Secret Manager contengono un singolo []byte, mentre i secret di Kubernetes contengono un map<string, string>.

Strategia di migrazione

Dopo aver creato le risorse equivalenti, l'esposizione degli endpoint esterni dietro un bilanciatore del carico delle applicazioni esterno globale consente di eseguire gradualmente la migrazione del traffico tra Cloud Run e Google Kubernetes Engine (GKE).