Questo documento descrive come configurare e utilizzare i deployment canary per eseguire il deployment delle applicazioni in GKE o GKE Enterprise utilizzando Cloud Deploy con il service mesh dell'API Gateway di Kubernetes.
Un deployment canary è un'implementazione progressiva di una nuova versione dell'applicazione, in cui aumenti gradualmente la percentuale di traffico inviato alla nuova versione, monitorando al contempo le prestazioni dell'applicazione. In questo modo, puoi rilevare potenziali problemi in anticipo e ridurre al minimo l'impatto sugli utenti.
Come funzionano i deployment canary per GKE e GKE Enterprise utilizzando l'API Gateway
Oltre ai riferimenti a Deployment e Servizio, fornisci una risorsa HTTPRoute con una regola
backendRefs
che fa riferimento al servizio.Cloud Deploy crea un nuovo deployment, con il nome del deployment originale più
-canary
, e un nuovo servizio con il nome del servizio originale più-canary
.Anche i secret, i ConfigMap e gli Horizontal Pod Autoscaler vengono copiati e rinominati con
-canary
.Per ogni fase canary, Cloud Deploy modifica HTTPRoute per aggiornare la ponderazione tra i pod del deployment originale e i pod del deployment canary, in base alla percentuale per quella fase.
Poiché la propagazione delle modifiche alle risorse
HTTPRoute
può subire ritardi, puoi includere la proprietàrouteUpdateWaitTime
nella configurazione, in modo che il sistema attenda un periodo di tempo specificato per questa propagazione.Durante la fase
stable
, il deployment-canary
viene ridotto a zero e il deployment originale viene aggiornato per utilizzare il deployment della nuova release.Inoltre, HTTPRoute è stato ripristinato alla versione originale che hai fornito.
Cloud Deploy non modifica il deployment o il servizio originale fino alla fase
stable
.
Utilizzando Cloud Deploy, puoi configurare i deployment canary in GKE e GKE Enterprise in una singola fase o in più fasi.
Le istruzioni riportate di seguito includono solo ciò che è specifico della configurazione canary. Il documento Eseguire il deployment in un cluster Google Kubernetes Engine contiene le istruzioni generali per configurare ed eseguire la pipeline di deployment.
Assicurati di disporre delle autorizzazioni necessarie
Oltre alle altre autorizzazioni Identity and Access Management necessarie per utilizzare Cloud Deploy, devi disporre delle seguenti autorizzazioni per eseguire azioni aggiuntive che potrebbero essere necessarie per un deployment canary:
clouddeploy.rollouts.advance
clouddeploy.rollouts.ignoreJob
clouddeploy.rollouts.cancel
clouddeploy.rollouts.retryJob
clouddeploy.jobRuns.get
clouddeploy.jobRuns.list
clouddeploy.jobRuns.terminate
Per ulteriori informazioni sui ruoli disponibili che includono queste autorizzazioni, consulta Ruoli e autorizzazioni IAM.
Prepara il tuo skaffold.yaml
Il file skaffold.yaml
definisce il rendering e il deployment dei manifest Kubernetes. Per un deployment canary su GKE/GKE Enterprise, assicurati che punti correttamente ai manifest e definisca gli artefatti di build necessari. All'interno di skaffold.yaml
non è richiesta alcuna configurazione specifica per la versione canary, oltre a quella necessaria per un deployment standard. Potresti utilizzare i profili Skaffold per gestire diverse varianti del manifest per le fasi canary personalizzate.
Preparare i manifest Kubernetes
I manifest Kubernetes devono includere sia una risorsa Deployment
sia una risorsa Service
.
Service
deve definire un selector
che corrisponda alle etichette dei pod gestiti da Deployment
.
L'etichetta predefinita che Cloud Deploy cerca è app
, ma può essere configurata nella pipeline.
Oltre a Deployment
e Service
, i manifest devono includere una risorsa HTTPRoute
configurata per la suddivisione del traffico, che fa riferimento a Service
e al gateway associato.
Configurare un canary automatico
Utilizza l'API Kubernetes Gateway (con Istio o qualsiasi implementazione supportata) per la suddivisione precisa del traffico in base alla percentuale gestita dal mesh/gateway, orchestrata da Cloud Deploy.
Configura le risorse API Gateway: assicurati che il gateway e la mesh di servizi sottostante (ad es. Istio) o il controller Gateway siano configurati correttamente nei tuoi cluster.
Nel manifest Kubernetes, fornito a Cloud Deploy quando hai creato la release, includi quanto segue:
Un
HTTPRoute
che fa riferimento alla risorsa GatewayUn deployment
Un servizio
Configura la pipeline di distribuzione e la destinazione in cui eseguire il deployment canary:
La configurazione del target è la stessa di qualsiasi altro target.
La configurazione della pipeline di distribuzione, nella sequenza di progressione per la destinazione specifica, include una sezione
gatewayServiceMesh
per fare riferimento alla configurazione dell'API Kubernetes GatewayHTTPRoute
, nonché al deployment e al servizio.strategy: canary: runtimeConfig: kubernetes: gatewayServiceMesh: httpRoute: "ROUTE" service: "SERVICE" deployment: "DEPLOYMENT" routeUpdateWaitTime: "WAIT_TIME" podSelectorLabel: "LABEL" canaryDeployment: percentages: - 50
Dove…
ROUTE è la configurazione httpRoute che definisce il comportamento di routing che ti interessa.
SERVICE è la configurazione del servizio, che Cloud Deploy richiede per i deployment canary in GKE e GKE Enterprise.
DEPLOYMENT è la configurazione di deployment, che Cloud Deploy richiede per i deployment canary a GKE e GKE Enterprise.
WAIT_TIME è un periodo di tempo durante il quale Cloud Deploy attende che la propagazione delle modifiche alla risorsa
HTTPRoute
termini, per evitare richieste eliminate. Ad esempio:routeUpdateWaitTime: 60s
.Se esegui canary utilizzando l'API Gateway senza Istio e l'API Gateway è connessa a un bilanciamento del carico, una piccola quantità di traffico potrebbe andare persa quando viene ridimensionata l'istanza canary. Google Cloud Puoi configurare questa impostazione se noti questo comportamento.
LABEL è un'etichetta del selettore pod. Deve corrispondere al selettore di etichette nel servizio e nel deployment Kubernetes definiti nel manifest. Questa opzione è facoltativa. Il valore predefinito è
app
.
Configurare un canary personalizzato automatizzato
Questa funzionalità combina la definizione di fasi personalizzate (nomi, percentuali, profili, verifica, hook) con la gestione automatica del traffico di Cloud Deploy per GKE o GKE Enterprise. Definisci le fasi, ma Cloud Deploy gestisce la manipolazione delle risorse sottostanti in base alle percentuali e al runtimeConfig
scelto.
Per configurare questa opzione, includi sia una sezione runtimeConfig
con serviceNetworking
sia la sezione customCanaryDeployment
(che definisce phaseConfigs) all'interno del blocco strategy.canary. Cloud Deploy utilizzerà i profili Skaffold specificati per il rendering, ma regolerà automaticamente il traffico in base alle percentuali di runtimeConfig
e di fase.
serialPipeline:
stages:
- targetId: gke-prod
profiles: []
strategy:
canary:
# Include runtimeConfig for automatic traffic management
runtimeConfig:
kubernetes:
gatewayServiceMesh:
httpRoute: "my-route"
service: "my-app"
deployment: "my-deployment"
# Include customCanaryDeployment for phase customization
customCanaryDeployment:
phaseConfigs:
- phaseId: "warmup"
percentage: 10
profiles: ["profile-a"] # Profile used for rendering this phase
verify: true
- phaseId: "scaling"
percentage: 50
profiles: ["profile-b"] # Different profile for this phase
verify: true
- phaseId: "stable"
percentage: 100
profiles: ["profile-b"] # Can reuse profiles
verify: true
Esegui il deployment di un HTTPRoute in un cluster diverso
Quando hai configurato un canary utilizzando il mesh di servizi dell'API Gateway, puoi specificare un cluster alternativo non di destinazione su cui eseguire il deployment di HTTPRoute.
Per farlo, utilizza una sezione routeDestinations
nella configurazione della strategia canary per identificare il cluster o i cluster di destinazione per HTTPRoute e un'impostazione booleana per propagare il servizio allo stesso cluster non di destinazione. e crei una sezione associatedEntities
nella configurazione di destinazione per identificare i cluster.
Configura
associatedEntities
sulla tua destinazione.Ogni entità è un cluster in cui Cloud Deploy eseguirà il deployment di HTTPRoute e, facoltativamente, del servizio Kubernetes. Nella definizione del target, includi una sezione
associatedEntities
:associatedEntities: [KEY]: gkeClusters: - cluster: [PATH] dnsEndpoint: [true|false] internalIp: [true|false] proxyUrl:
Dove:
KEY
è un nome arbitrario per questo gruppo di entità associate. Utilizzerai questo nome per fare riferimento alle entità dirouteDestinations
nella configurazione canary.PATH
è il percorso della risorsa che identifica il cluster GKE in cui verrà eseguito il deployment di HTTPRoute (e, facoltativamente, del servizio).dnsEndpoint
indica se utilizzare o meno l'endpoint DNS del cluster se sono configurati più endpoint. Il valore predefinito èfalse
.internalIp
indica se utilizzare o meno l'IP interno del cluster (IP privato) se sono configurati più endpoint. Il valore predefinito èfalse
.
Puoi includere un numero qualsiasi di cluster, con o senza
internalIp
.Configura
routeDestinations
nella configurazione canary.Ogni destinazione della route fa riferimento a una sezione
associatedEntities
e indica se eseguire o meno il deployment del servizio anche nel cluster alternativo. Aggiungi quanto segue all'interno della sezionegatewayServiceMesh
nella configurazione canary:routeDestinations: destinationIds: ["KEY"] propagateService: [true|false]
Dove:
KEY
è il nome che hai configurato nella destinazione, inassociatedEntities
. Utilizza questo nome per fare riferimento alle entità dirouteDestinations
nella configurazione canary.Puoi anche fornire il valore
@self
per eseguire il deployment di HTTPRoute nel cluster di destinazione oltre alla destinazione associata.propagateService
indica se vuoi o meno eseguire il deployment del servizio nel cluster associato, oltre a HTTPRoute. Il valore predefinito èfalse
.
Esegui il canary GKE o GKE Enterprise
Registra pipeline e target: applica i file di configurazione della pipeline di distribuzione e dei target GKE o GKE Enterprise.
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION gcloud deploy apply --file=gke-targets.yaml --region=REGION
La pipeline di distribuzione include la configurazione canary automatica o personalizzata per il runtime scelto.
Crea una release: avvia il deployment fornendo il nome dell'immagine.
gcloud deploy releases create RELEASE_NAME \ --delivery-pipeline=PIPELINE_NAME \ --region=REGION # e.g., --images=my-cloudrun-service=gcr.io/my-project/my-app:v1.1 # Add --skaffold-file or --source if not using default Skaffold config discovery
La pipeline di distribuzione identificata da
PIPELINE_NAME
contiene la configurazione canary automatica o personalizzata descritta in questo documento.Avanza alla fase canary:
Interfaccia a riga di comando gcloud
gcloud deploy rollouts advance ROLLOUT_NAME \ --release=RELEASE_NAME \ --delivery-pipeline=PIPELINE_NAME \ --region=REGION
Dove:
ROLLOUT_NAME
è il nome dell'implementazione attuale che stai facendo avanzare alla fase successiva.RELEASE_NAME
è il nome della release di cui fa parte questo rollout.PIPELINE_NAME
è il nome della pipeline di distribuzione che utilizzi per gestire il deployment di questa release.REGION
è il nome della regione in cui è stata creata la release, ad esempious-central1
. Campo obbligatorio.Per ulteriori informazioni sul comando
gcloud deploy rollouts advance
, consulta il riferimento per Google Cloud SDK.Console Google Cloud
Fai clic sulla pipeline visualizzata nell'elenco delle pipeline di pubblicazione.
La pagina Dettagli pipeline di distribuzione mostra una rappresentazione grafica dell'avanzamento della pipeline di distribuzione.
Nella scheda Implementazioni, in Dettagli della pipeline di pubblicazione, fai clic sul nome dell'implementazione.
Viene visualizzata la pagina dei dettagli dell'implementazione.
Nota che in questo esempio l'implementazione ha una fase
canary-50
e una fasestable
. L'implementazione potrebbe avere più fasi o fasi diverse.Fai clic su Prosegui con implementazione.
L'implementazione passa alla fase successiva.
Fasi saltate
Se esegui il deployment di una versione canary e la tua applicazione non è ancora stata sottoposta a deployment in quel runtime, Cloud Deploy salta la fase canary ed esegue la fase stabile. Consulta la sezione Saltare le fasi la prima volta per scoprire perché ciò accade.
Passaggi successivi
Prova la guida rapida al deployment canary.
Scopri come gestire il ciclo di vita dei rollout canary.
Scopri di più sul deployment parallelo.
Scopri di più sulle strategie di deployment di Cloud Deploy.