Cloud Run e Kubernetes utilizzano entrambi immagini container standard come artefatti di deployment ed entrambi usano 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 carichi di lavoro Cloud Run in un cluster Kubernetes come GKE.
Guida rapida
Questa guida rapida è un esempio di migrazione semplice.
Confronto tra risorse semplici
Confronta il seguente servizio Cloud Run semplice denominato my-app
con il deployment Kubernetes equivalente.
Tieni presente che i file YAML sono quasi identici.
Tuttavia, le parti in blue
sono diverse e devono essere modificate.
È necessario aggiungere le parti in green
.
Servizio Cloud Run | Deployment 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 |
Migrazione di un semplice servizio Cloud Run a GKE
Scarica il file YAML del servizio nella directory corrente:
gcloud run services describe my-app --format export > my-app.yaml
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 esempiodefault
. - Aggiungi una nuova etichetta a
metadata
espec.template.metadata
. - Imposta un numero fisso di istanze ("repliche") utilizzando
spec.template.spec.replicas
e imposta un selettore di etichette inspec.template.spec.selector
.
- Per l'attributo "
Installa e utilizza lo strumento a riga di comando
kubectl
per eseguire il deployment del filemy-app.yaml
nel cluster GKE:kubectl apply -f ./my-app.yaml
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:
Cloud Run è una piattaforma completamente gestita, mentre GKE richiede un'ulteriore gestione della piattaforma. Se non hai ancora creato un cluster GKE, utilizza GKE Autopilot.
La scalabilità dei carichi di lavoro GKE è limitata dalle dimensioni del cluster. Se non utilizzi un cluster Autopilot, valuta la possibilità di utilizzare il provisioning automatico dei nodi e un gestore della scalabilità automatica dei cluster per ridimensionare il cluster.
Cloud Run dispone di una ridondanza integrata a livello di zona, perciò esegui la migrazione a un cluster a livello di regione ed esegui il provisioning di un numero di repliche sufficiente per garantire che il tuo servizio sia resiliente a un'interruzione a livello di zona nella regione Google Cloud selezionata.
Prezzi
Cloud Run addebita le risorse utilizzate, mentre GKE addebita le risorse di cui è stato eseguito il provisioning.
Sicurezza:
Al contrario di Cloud Run, la chiamata di un servizio GKE non è soggetta a un'autorizzazione callback IAM.
Poiché GKE non fornisce 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 VPC. I carichi di lavoro GKE si trovano direttamente in un VPC e non hanno bisogno di 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 revisioni
- Suddivisione del traffico per implementazioni e rollback graduali delle revisioni
- CPU allocata solo durante l'elaborazione delle richieste
- Boost della CPU
- Affinità sessione
- Le etichette sui carichi di lavoro GKE non sono etichette Google Cloud
- Tag sui carichi di lavoro
Migrazione delle risorse Cloud Run
Le seguenti sezioni descrivono la migrazione delle risorse utilizzate in Cloud Run, ad esempio servizi, job e secret di Cloud Run.
Migrazione dei servizi Cloud Run
Puoi eseguire la migrazione di un servizio Cloud Run alle seguenti risorse su GKE:
- Deployment di Kubernetes per creare istanze (chiamate "pod" in Kubernetes).
- Servizi Kubernetes per esporre il deployment in un endpoint specifico.
- Horizontal Pod Autoscaler di Kubernetes: per scalare automaticamente il deployment.
Gli attributi di un deployment Kubernetes sono un soprainsieme degli attributi di un servizio Cloud Run.
Come mostrato nella quickstart, 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 in cui eseguire il deployment, ad esempiodefault
. serviceAccountName
deve fare riferimento a un account di servizio Kubernetes, che facoltativamente può fungere da account di servizio IAM con Workload Identity.- Aggiungi un elemento LABEL in
metadata.labels
espec.template.metadata.labels
che verrà utilizzato 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
selezionato sull'etichetta LABEL.
- Aggiungi un attributo
- Se il servizio Cloud Run monta i secret, consulta Eseguire 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 servizio.
- LABEL: con l'etichetta definita nel deployment. Ad esempio
app: NAME
. - PORT: con
containerPort
del container che riceve richieste nel servizio Cloud Run, che per impostazione predefinita è8080
.
Facoltativamente, puoi creare 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 del minimo di istanze
(autoscaling.knative.dev/minScale
)
e del numero massimo di istanze
(autoscaling.knative.dev/maxScale
)
del servizio Cloud Run come valori per gli attributi minReplicas
e
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 creazione. Se vuoi eseguirlo di nuovo, 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 di Kubernetes.
Se scegli di mantenere i secret in Secret Manager, devi aggiornare le modalità di utilizzo su GKE.
Se scegli di eseguire la migrazione da Secret Manager ai secret di Kubernetes, prendi in considerazione 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}
- Secret Kubernetes:
- Controllo delle versioni: per i secret di Secret Manager viene eseguito il 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 valoremap<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 ti consente di eseguire la migrazione graduale del traffico tra Cloud Run e Google Kubernetes Engine (GKE).