Esegui la migrazione da Kubernetes a Cloud Run

Cloud Run e Kubernetes utilizzano entrambi immagini container standard come artefatti di deployment e un modello di 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 di 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 utilizzare Knative nel cluster Kubernetes esistente per eseguire la migrazione di alcuni 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 autoscaler di pod integrato e un endpoint univoco. 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 Kubernetes Horizontal Pod Autoscaler e dei servizi Kubernetes nel servizio Cloud Run.

Cloud Run non ha il concetto di spazio dei nomi, ma il Google Cloud progetto 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 service, il valore dello spazio dei nomi è il Google Cloud numero di progetto.

Cloud Run ha una ridondanza a livello di zona integrata, il che significa che non devi eseguire il provisioning della replica per garantire la resilienza del servizio a un'interruzione a livello di zona nellaregione selezionata. Google Cloud

Guida rapida

Questa guida rapida è un esempio di una semplice migrazione.

Confronto semplice delle risorse

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

Le parti in blue sono diverse e devono essere modificate. Le parti in red devono essere eliminate perché Cloud Run ha un autoscaler 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

Esegui la migrazione di 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 modificane il valore in modo che corrisponda al tuo 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 desiderata, Google Cloud 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 l'accesso pubblico, esegui il seguente comando:

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

Funzionalità non supportate da Cloud Run

È possibile eseguire la migrazione solo dei carichi di lavoro che sono un fit per Cloud Run.

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

• Numeri fissi di replicas (una soluzione alternativa consiste nell'utilizzare lo stesso numero di minime e massime istanze
• Oggetti ConfigMap (soluzione alternativa disponibile)
• Strategie di Horizontal Pod Autoscaler 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.

Puoi consultare il riferimento YAML per un elenco esaustivo degli attributi supportati da Cloud Run.

Esegui la migrazione delle risorse Kubernetes

Esegui la migrazione dei 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 di Kubernetes contengono una 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 degli oggetti ConfigMap Kubernetes

Cloud Run non ha un equivalente degli oggetti ConfigMap Kubernetes ConfigMaps, ma poiché gli oggetti ConfigMap possono essere considerati secret non criptati, puoi trasformarli in secret in Secret Manager. Consulta le istruzioni in Esegui la migrazione dei secret Kubernetes.

Esegui la migrazione di un deployment Kubernetes

Il deployment Kubernetes esposto da un servizio è la risorsa che si avvicina di più a un 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:

• Lo namespace deve essere sostituito con il Google Cloud numero di progetto.
• Le etichette (metadata.labels e spec.template.metadata.labels) devono essere etichette Google Cloud valide.
• I container devono essere archiviati in un registro container supportato.
• I limiti diCPU e memoria potrebbero dover essere modificati.
• Quando fai riferimento a un secret, l'attributo "key" viene utilizzato per acquisire la versione in Secret Manager, con "latest" che fa riferimento alla versione più recente del secret.
• serviceAccountName deve fare riferimento a un service account in il progetto Google Cloud corrente.
• I riferimenti agli oggetti ConfigMap (configMapKeyRef) devono essere sostituiti con riferimenti ai secret (secretKeyRef)

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

Esegui la migrazione di un servizio Kubernetes

I servizi Cloud Run espongono automaticamente un endpoint univoco che instrada il traffico al container con un containerPort. Dopo aver eseguito la migrazione del deployment Kubernetes a un servizio Cloud Run, non devi eseguire la migrazione dei servizi Kubernetes che instradavano il traffico a questo deployment.

Esegui la migrazione di un HorizontalPodAutoscaler Kubernetes

I servizi Cloud Run hanno un autoscaler 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 definiti.

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 del numero minimo di istanze e del numero massimo di istanze.

Esegui la migrazione di un deployment Kubernetes senza un servizio

Se il deployment Kubernetes esegue attività in background o pianificate e non è esposto da un servizio, puoi eseguire la migrazione a un pool di worker Cloud Run.

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

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:

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

Esegui la migrazione di un job Kubernetes

Poiché un job Kubernetes è simile all'esecuzione di un 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 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).