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 utilizzare Knative nel tuo cluster Kubernetes esistente per eseguire la migrazione di alcuni dei tuoi carichi di lavoro Kubernetes in Cloud Run.
La risorsa principale di Cloud Run è il servizio. Un servizio Cloud Run può essere considerato un'astrazione di alto livello che assomiglia a un deployment Kubernetes con un gestore della scalabilità automatica 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 dei tuoi servizi di scalabilità automatica pod orizzontale e servizi Kubernetes nel servizio Cloud Run.
Per Cloud Run non esiste il concetto di spazio dei nomi, ma 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. In YAML di un servizio Cloud Run, il valore dello spazio dei nomi è il numero del progetto Google Cloud.
Cloud Run prevede una ridondanza a livello di zona integrata, il che significa che non è necessario eseguire il provisioning della replica per garantire che il servizio sia resistente a un'interruzione di zona nella regione Google Cloud selezionata.
Guida rapida
Questa guida rapida è un esempio di migrazione semplice.
Confronto tra risorse semplici
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
dovrebbero essere eliminate perché Cloud Run ha un gestore della scalabilità automatica integrato.
Deployment 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 tuo deployment nella directory attuale con:
kubectl get deployment my-app -o yaml > my-app.yaml
Modifica il codice 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 numero del tuo progetto Google Cloud. - Elimina
spec.replicas
espec.selector
- Per l'attributo "
Esegui il deployment del file
my-app.yaml
in Cloud Run utilizzando il seguente comando, sostituendo REGION con la regione di Google Cloud desiderata, ad esempious-central1
: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 su internet e consentire 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
È possibile eseguire la migrazione solo dei 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 minimo e massimo - Mappe di configurazione (soluzione alternativa disponibile)
- Strategie personalizzate di Horizontal Pod Autoscaler
- Service Discovery
Quando si esegue la migrazione di un file YAML da un deployment Kubernetes a un servizio Cloud Run, il comando gcloud run services replace
restituirà un chiaro messaggio di errore per qualsiasi attributo non supportato da Cloud Run.
Elimina o aggiorna questi attributi, quindi ripeti il comando finché l'operazione non va a buon fine.
Puoi consultare la documentazione di riferimento YAML per un elenco esaustivo del supporto degli attributi da parte di Cloud Run.
Esegui la migrazione delle risorse Kubernetes
Esegui la migrazione dei secret di 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 di Kubernetes:
[a-z0-9-.]{1,253}
- Secret di Secret Manager:
[a-zA-Z0-9_-]{1,255}
- Secret di Kubernetes:
- Controllo delle versioni: viene eseguito il controllo delle versioni per i secret di Secret Manager, 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>
.
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.
Migrazione degli oggetti 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 ConfigMap in secret in Secret Manager. Consulta le istruzioni in Eseguire la migrazione dei secret di Kubernetes.
Esegui la migrazione di un deployment Kubernetes
Il deployment di Kubernetes è la risorsa di mappa più vicina al servizio Cloud Run. Ti consigliamo di iniziare dal file YAML del deployment Kubernetes e modificarlo per trasformarlo in un servizio Cloud Run.
Le principali modifiche obbligatorie sono:
- Il valore
namespace
deve essere sostituito con il numero di progetto Google Cloud. - Le etichette (
metadata.labels
espec.template.metadata.labels
) devono essere etichette Google Cloud valide. - I container devono essere archiviati in un container registry supportato.
- Potrebbe essere necessario modificare i limiti di CPU e memoria.
- 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 account di servizio nel progetto Google Cloud attuale- I riferimenti ai ConfigMap (
configMapKeyRef
) devono essere sostituiti con i riferimenti ai secret (secretKeyRef
)
Se il tuo deployment Kubernetes accede ad altre risorse nel tuo cluster Kubernetes o alle 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 è necessario eseguire la migrazione dei servizi Kubernetes che instradavano il traffico a questo deployment.
Esegui la migrazione di un HorizontalPodAutoscaler di Kubernetes
I servizi Cloud Run dispongono di un gestore della 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 del numero minimo di istanze e del numero massimo di istanze.
Esegui la migrazione di un job Kubernetes
Perché un job Kubernetes è simile all'esecuzione di un job Cloud Run. Puoi eseguire la migrazione a un job Cloud Run ed 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 |
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 la migrazione graduale del traffico tra Cloud Run e Google Kubernetes Engine (GKE).