Esegui la migrazione da Cloud Run a Google Kubernetes Engine

Cloud Run e Kubernetes utilizzano entrambi immagini container standard artefatti di deployment, entrambi usano un modello API dichiarativo con risorse possono essere rappresentati nei file YAML con la stessa struttura standard.

Introduzione

L'API Cloud Run Admin v1 è progettato per massimizzare la portabilità Ad esempio, le risorse dell'API Cloud Run Admin condividono la stessa struttura convenzioni e nomi degli attributi come risorse Kubernetes. Consulta il riferimento YAML del servizio Cloud Run.

La versione 1 dell'API Cloud Run Admin implementa la specifica dell'API Knative Serving, ma non è necessario eseguire la migrazione a Knative per spostare i carichi di lavoro 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 corrispondente deployment Kubernetes. Nota che i file YAML sono quasi identici.

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

Servizio Cloud Run	Deployment di 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 semplice servizio Cloud Run a GKE

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

   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 "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 di GKE cluster 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 usa lo strumento a riga di comando kubectl per eseguire il deployment del file my-app.yaml al 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 per la migrazione da Cloud Run a GKE

Cluster:

• Cloud Run è una piattaforma completamente gestita, mentre GKE richiede più gestione della piattaforma. Se non hai ancora creato un cluster GKE, utilizza GKE Autopilot.

• La scalabilità dei carichi di lavoro GKE è limitata dalla dimensione in un cluster Kubernetes. Se non utilizzi un cluster Autopilot, ti consigliamo di utilizzare il provisioning automatico dei nodi e un gestore della scalabilità automatica dei cluster per ridimensionare il cluster.

• Cloud Run dispone di una redundanza zonale integrata, quindi esegui la migrazione a un cluster regionale e esegui il provisioning di repliche sufficienti per garantire che il servizio sia resiliente a un interruzione di servizio zonale nella regione Google Cloud selezionata.

Prezzi

Cloud Run addebita le risorse utilizzate, mentre Addebiti di GKE per provisioning Google Cloud.

Sicurezza:

• A differenza di Cloud Run, il richiamo di un servizio GKE non è soggetto a un'autorizzazione invoker IAM.

• Poiché GKE non offre un solido isolamento tra i container, valuta la possibilità di utilizzare 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 in un VPC. I carichi di lavoro GKE si trovano direttamente in una VPC e non richiedono un connettore.

Funzionalità non supportate da Google Kubernetes Engine

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

• Controllo delle versioni della configurazione tramite le revisioni
• Suddivisione del traffico per implementazioni graduali e rollback delle revisioni
• CPU allocata solo durante l'elaborazione delle richieste
• Aumento della CPU
• Affinità sessione
• Le Etichette sui carichi di lavoro GKE non sono etichette Google Cloud
• Tag sui carichi di lavoro

Esegui la migrazione delle risorse Cloud Run

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

Esegui la migrazione dei servizi Cloud Run

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

1. Deployment di Kubernetes per creare istanze (chiamate "pod" in Kubernetes).
2. Servizi Kubernetes per esporre il deployment in un endpoint specifico.
3. Kubernetes Horizontal Pod Autoscaler: per eseguire 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 modificare anche quanto segue:

• Sostituisci namespace con lo spazio dei nomi del cluster GKE di cui eseguire il deployment, ad esempio default.
• serviceAccountName deve fare riferimento a un account di servizio Kubernetes, che può agire facoltativamente come account di servizio IAM con la federazione delle identità per i carichi di lavoro per GKE.
• Aggiungi LABEL alle ore metadata.labels e spec.template.metadata.labels che verrà usato per selezionare il deployment e i pod. Ad esempio: app: NAME
• Inferiore a spec.template:
  • Aggiungi un attributo replicas per specificare un numero di "istanze".
  • Aggiungi un attributo selector.matchLabels che selezioni l'etichetta LABEL.
• Se il tuo servizio Cloud Run monta i secret, consulta Eseguire la migrazione dei secret.
• Se il servizio Cloud Run migrato 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 esporre Questo:

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 tuo deployment. Ad esempio app: NAME.
• PORT: con containerPort del container che riceve richieste nel servizio Cloud Run, che per impostazione predefinita è 8080.

Se vuoi, puoi creare un Horizontal Pod Autoscaler di Kubernetes per scalare automaticamente il numero di pod. Segui la documentazione relativa alla scalabilità automatica pod orizzontale di Kubernetes per creare un HorizontalPodAutoscaler. Utilizza il numero minimo di istanze (autoscaling.knative.dev/minScale) e numero massimo di istanze (autoscaling.knative.dev/maxScale) del servizio Cloud Run come valori per minReplicas e Attributi maxReplicas HorizontalPodAutoscaler.

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 al momento della loro creazione. Se vuoi eseguire di nuovo il job, devi crearne uno nuovo.

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

Job Cloud Run	Job 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 mantenere i secret esistenti in Secret Manager o eseguirne la migrazione ai secret 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:
  • Secret Kubernetes: [a-z0-9-.]{1,253}
  • Secret di Secret Manager: [a-zA-Z0-9_-]{1,255}
• 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, esposizione degli endpoint esterni dietro un bilanciatore del carico delle applicazioni esterno globale consente di eseguire gradualmente la migrazione del traffico tra Cloud Run Google Kubernetes Engine (GKE).