Esegui la migrazione da Kubernetes a Cloud Run

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 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 devi utilizzare Knative nel tuo cluster Kubernetes esistente per eseguire la migrazione di alcuni dei tuoi carichi di lavoro Kubernetes a Cloud Run.

La risorsa principale di Cloud Run è il servizio. Puoi considerare un servizio Cloud Run come un'astrazione di alto livello che assomiglia a un deployment Kubernetes con un gestore della scalabilità automatica dei pod e un endpoint unici. Un "pod" in Kubernetes corrisponde a un'"istanza" in Cloud Run. Ti consigliamo di trasformare i deployment Kubernetes in servizi Cloud Run, un servizio alla volta. Potrai anche unire alcune configurazioni di Horizontal Pod Autoscaler di Kubernetes e dei servizi Kubernetes nel servizio Cloud Run.

Cloud Run non ha il concetto di spazio dei nomi, ma il progettoGoogle Cloud viene utilizzato come limite di isolamento tra le risorse. Quando esegui la migrazione a Cloud Run da Kubernetes, ti consigliamo di creare un Google Cloud progetto per ogni spazio dei nomi. Nel file YAML di un servizio Cloud Run, il valore dello spazio dei nomi è il numero di progetto Google Cloud .

Cloud Run ha una ridondanza a livello di zona integrata, il che significa che non devi eseguire il provisioning della replica per garantire che il tuo servizio sia resiliente a un'interruzione del servizio a livello di zona nella regione Google Cloud selezionata.

Guida rapida

Questa guida rapida è un esempio di migrazione semplice.

Confronto semplice delle risorse

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

Le parti in blue sono diverse e devono essere modificate. Le parti in red devono essere eliminate perché Cloud Run ha un gestore della scalabilità automatica integrato.

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

Migrare un semplice deployment Kubernetes a Cloud Run

1. Scarica il file YAML del deployment nella directory corrente con:

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

2. Modifica il file YAML in modo che corrisponda a un servizio Cloud Run. Aggiorna il file my-app.yaml:

   • Per l'attributo "kind": sostituisci il valore "Deployment" con "Service"
   • Per l'attributo "apiVersion": sostituisci il valore "apps/v1" con "serving.knative.dev/v1"
   • Elimina l'attributo metadata.namespace o modifica il relativo valore in modo che corrisponda al numero di progetto Google Cloud .
   • Elimina spec.replicas e spec.selector

3. Esegui il deployment del file my-app.yaml in Cloud Run utilizzando il seguente comando, sostituendo REGION con la regione Google Cloud desiderata, ad esempio europe-west1:

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

La chiamata di un servizio Cloud Run è protetta da un'autorizzazione IAM. Se vuoi esporre pubblicamente il nuovo servizio Cloud Run a internet e consentire le chiamate non autenticate, esegui questo comando:

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

Funzionalità non supportate da Cloud Run

Possono essere migrati solo i carichi di lavoro adatti a Cloud Run.

In particolare, le seguenti funzionalità di Kubernetes non sono supportate da Cloud Run:

• Numeri fissi di replicas (una soluzione alternativa è utilizzare lo stesso numero di istanze minime e massime
• Mappe di configurazione (soluzione alternativa disponibile)
• Strategie di scalabilità automatica orizzontale del pod personalizzate
• Service Discovery
• Disco locale (temporaneo e permanente)

Quando esegui la migrazione di un file YAML da un deployment Kubernetes a un servizio Cloud Run, il comando gcloud run services replace restituisce un messaggio di errore chiaro per qualsiasi attributo non supportato da Cloud Run. Elimina o aggiorna questi attributi, quindi ripeti il comando finché non va a buon fine.

Per un elenco esaustivo degli attributi supportati da Cloud Run, consulta il riferimento YAML.

Esegui la migrazione delle risorse Kubernetes

Migra i secret Kubernetes

Come Kubernetes, Cloud Run supporta il montaggio dei secret come variabili di ambiente o volumi, ma i secret devono essere archiviati in Secret Manager.

Esistono diverse differenze importanti 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 versionati, mentre i secret di Kubernetes non lo sono.
• Payload: i secret di Secret Manager contengono un singolo []byte, mentre i secret Kubernetes contengono un map<string, string>.

Segui la documentazione di Secret Manager per creare un secret e aggiungere una nuova versione del secret per ogni chiave secret da cui dipende la tua app Kubernetes.

Esegui la migrazione di ConfigMap di Kubernetes

Cloud Run non ha un equivalente di Kubernetes ConfigMaps, ma poiché i ConfigMaps possono essere considerati Secret non criptati, puoi trasformare i tuoi ConfigMaps in secret in Secret Manager. Consulta le istruzioni riportate in Migrazione dei secret di Kubernetes.

Migra un deployment Kubernetes

Il deployment Kubernetes è la risorsa che esegue il mapping più vicino al servizio Cloud Run. Ti consigliamo di iniziare dal file YAML del deployment Kubernetes e di modificarlo per trasformarlo in un servizio Cloud Run.

Le principali modifiche richieste sono:

• namespace deve essere sostituito con il numero di progetto Google Cloud .
• Le etichette (metadata.labels e spec.template.metadata.labels) devono essere etichette valide Google Cloud .
• I container devono essere archiviati in un registro dei container supportato.
• Potrebbe essere necessario modificare i limiti di CPU e memoria.
• Quando viene fatto riferimento a un secret, l'attributo "key" viene utilizzato per acquisire la versione in Secret Manager, mentre "latest" fa riferimento alla versione più recente del secret.
• serviceAccountName deve fare riferimento a un service account nel progetto Google Cloud attuale
• I riferimenti a ConfigMap (configMapKeyRef) devono essere sostituiti con riferimenti a secret (secretKeyRef)

Se il deployment di Kubernetes accede ad altre risorse nel cluster Kubernetes o a risorse su un VPC, devi connettere il servizio Cloud Run al VPC appropriato.

Migrazione di un servizio Kubernetes

I servizi Cloud Run espongono automaticamente un endpoint unico che indirizza il traffico al container con un containerPort. Dopo aver eseguito la migrazione del deployment Kubernetes a un servizio Cloud Run, non è necessario eseguire la migrazione dei servizi Kubernetes che indirizzavano il traffico a questo deployment.

Migrazione di un HorizontalPodAutoscaler di Kubernetes

I servizi Cloud Run hanno uno strumento di scalabilità automatica orizzontale integrato: Cloud Run scala automaticamente i pod (chiamati "istanze") utilizzando una combinazione di fattori entro i limiti del numero minimo e massimo di istanze definito.

Esegui la migrazione degli attributi minReplicas e maxReplicas di HorizontalPodAutoscaler alle annotazioni autoscaling.knative.dev/minScale e autoscaling.knative.dev/maxScale del servizio Cloud Run. Consulta la documentazione sulla configurazione delle istanze minime e delle istanze massime.

Migrazione di un job Kubernetes

perché un job Kubernetes è simile a un'esecuzione di job Cloud Run. Puoi eseguire la migrazione a un job Cloud Run ed eseguire il job.

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

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

Strategia di migrazione

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