Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui la migrazione da Kubernetes a Cloud Run

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

Introduzione

La versione 1 dell'API Cloud Run Admin è progettata per massimizzare la portabilità con Kubernetes. Ad esempio, le risorse dell'API Cloud Run Admin condividono le stesse convenzioni di struttura e i nomi degli attributi delle risorse Kubernetes. Consulta le 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 tuo ambiente Kubernetes per eseguire la migrazione di alcuni carichi di lavoro Kubernetes in 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 ridimensionamento automatico dei pod integrato e un endpoint univoco. Un "pod" in Kubernetes corrisponde a un'"istanza" in Cloud Run. Ti consigliamo di trasformare i tuoi deployment Kubernetes in servizi Cloud Run, un servizio alla volta. Potrai anche unire alcune configurazioni di Horizontal Pod Autoscaler e dei servizi Kubernetes nel servizio Cloud Run.

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

Cloud Run dispone di una redundanza zonale integrata, il che significa che non è necessario eseguire il provisioning della replica per garantire che il servizio sia resiliente a un'interruzione zonale 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 chiamato 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 gestore della scalabilità automatica integrato.

Deployment di Kubernetes	Servizio 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: 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

Deployment di Kubernetes

Servizio 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:
      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

Scarica il file YAML del deployment nella directory corrente con:
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
Modificare 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 "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 il numero del tuo progetto Google Cloud.
- Elimina spec.replicas e spec.selector
Esegui il deployment del file my-app.yaml in Cloud Run utilizzando il seguente comando, sostituendo REGION con la regione Google Cloud che preferisci, ad esempio us-central1:
```
gcloud run services replace my-app.yaml --region REGION
```

L'invocazione di un servizio Cloud Run è protetta da un'autorizzazione IAM. Se vuoi esporre pubblicamente il nuovo servizio Cloud Run su internet e consentire invocazioni non autenticate, 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

Solo carichi di lavoro idonei per Cloud Run è possibile eseguire la migrazione.

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 minimo e numero massimo di istanze
Mappe di configurazione (soluzione alternativa disponibile)
Strategie di Horizontal Pod Autoscaler personalizzate
Service Discovery

Quando esegui la migrazione di un file YAML da un deployment Kubernetes a un servizio Cloud Run, il comando gcloud run services replace restituirà un messaggio di errore chiaro per qualsiasi attributo non supportato da Cloud Run. Elimina o aggiorna questi attributi, quindi ripeti il comando fino a quando non riesce.

Puoi fare riferimento al 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 ambiente o volumi, ma i secret devono essere archiviati Secret Manager.

Esistono diverse differenze importanti tra Secret Manager e i secret di Kubernetes:

Caratteri consentiti nei nomi:
- Secret di 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>.

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

Esegui la migrazione dei ConfigMap di Kubernetes

Cloud Run non ha un equivalente di Kubernetes ConfigMaps, ma poiché i ConfigMap possono essere visti come Secret non criptati, puoi trasformare i tuoi oggetti ConfigMap in secret in Secret Manager. Consulta le istruzioni in Eseguire la migrazione dei secret Kubernetes.

Esegui la migrazione di un deployment Kubernetes

Il deployment Kubernetes è la risorsa più simile al servizio Cloud Run. Ti consigliamo di partire dal file YAML del tuo 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 Google Cloud valide.
I container devono essere archiviati in un Container Registry supportato.
CPU e memoria potrebbe essere necessario modificare questi limiti.
Quando si fa riferimento a un secret, il campo "key" viene utilizzato per acquisire version in Secret Manager, con "latest" facendo riferimento alle ultime novità una nuova versione del secret.
serviceAccountName deve fare riferimento a un account di servizio in l'attuale progetto Google Cloud
I riferimenti ai ConfigMap (configMapKeyRef) devono essere sostituiti con riferimenti ai secret (secretKeyRef)

Se il deployment di Kubernetes accede ad altre risorse nel cluster Kubernetes o a risorse su una VPC, devi collegare il servizio Cloud Run alla VPC appropriata.

Esegui la migrazione di un servizio Kubernetes

I servizi Cloud Run espongono automaticamente un endpoint univoco che instrada al container con un valore 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.

Esegui la migrazione di un HorizontalPodAutoscaler di Kubernetes

I servizi Cloud Run dispongono di un ridimensionamento orizzontale integrato: Cloud Run scala automaticamente i pod (chiamati "istanze") utilizzando una combinazione di fattori entro i confini del numero minimo e massimo di istanze definito.

Esegui la migrazione degli attributi minReplicas e maxReplicas di HorizontalPodAutoscaler ai autoscaling.knative.dev/minScale e al autoscaling.knative.dev/maxScale del servizio Cloud Run. Consulta la documentazione sulla configurazione numero minimo di istanze e numero massimo di istanze.

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 e eseguirlo.

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

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

Job Kubernetes

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, 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).