Utilizza una strategia di deployment canary

Questo documento descrive come configurare e utilizzare una strategia di implementazione canary.

Che cos'è un deployment canary?

Un deployment canary è un'implementazione progressiva di un'applicazione che suddivide il traffico tra una versione già implementata e una nuova versione, implementandola in un sottoinsieme di utenti prima dell'implementazione completa.

Tipi di target supportati

Il deployment canary in Cloud Deploy supporta tutti i tipi di target, tra cui:

Canary funziona anche con più target.

Perché utilizzare una strategia di deployment canary?

Un deployment canary ti offre la possibilità di rilasciare parzialmente la tua applicazione. In questo modo, puoi assicurarti che la nuova versione della tua applicazione sia affidabile prima di distribuirla a tutti gli utenti.

Se esegui il deployment in GKE o GKE Enterprise, ad esempio, esegui il deployment della nuova versione dell'applicazione in un numero limitato di pod. La versione precedente continuerà a essere eseguita, ma con un maggiore volume di traffico inviato ai nuovi pod.

Se esegui il deployment in Cloud Run, Cloud Run stesso suddivide il traffico tra le revisioni precedenti e quelle nuove, in base alle percentuali che configuri.

Tipi di canarini

Cloud Deploy ti consente di configurare i seguenti tipi di deployment canary:

  • Automatico

    Con un deployment canary automatico, configurerai Cloud Deploy con una serie di percentuali che esprimono un deployment progressivo. Cloud Deploy esegue operazioni aggiuntive per tuo conto per suddividere le percentuali di traffico tra la versione precedente e quella nuova.

  • Personalizzata e automatica

    Per un canary automatizzato personalizzato, puoi fornire quanto segue:

    • Il nome della fase
    • L'obiettivo percentuale
    • Il profilo Skaffold da utilizzare per la fase
    • Se includere o meno un job di verifica
    • Se includere o meno un job di predeployment o postdeployment o entrambi

    Tuttavia, non è necessario fornire informazioni sul bilanciamento del traffico. Cloud Deploy crea le risorse necessarie.

  • Personalizzato

    Con un canary personalizzato, puoi configurare separatamente ogni fase del canary, tra cui:

    • Il nome della fase
    • L'obiettivo percentuale
    • Il profilo Skaffold da utilizzare per la fase
    • Se includere o meno un job di verifica
    • Se includere o meno un job di predeployment o postdeployment o entrambi

    Inoltre, per un canary completamente personalizzato, fornisci tutta la configurazione del bilanciamento del traffico, come descritto qui.

Fasi di un deployment canary

Quando crei una release per un deployment canary, l'implementazione viene creata con una fase per ogni incremento canary, oltre a una fase stable finale per il 100%.

Ad esempio, se configuri un canary per incrementi del 25%, 50% e 75%, il rollout avrà le seguenti fasi:

  • canary-25
  • canary-50
  • canary-75
  • stable

Puoi scoprire di più sulle fasi di implementazione, sui job e sulle esecuzioni dei job in Gestire le implementazioni.

Che cosa succede durante un canary automatico o personalizzato

Per supportare il deployment canary, Cloud Deploy include passaggi di elaborazione speciali durante il rendering del manifest Kubernetes o della configurazione del servizio Cloud Run:

GKE/Enterprise

Ecco come Cloud Deploy esegue un deployment canary in GKE e GKE Enterprise basati su rete:

  1. Fornisci il nome della risorsa Deployment e della risorsa Service.

  2. Cloud Deploy crea un'altra risorsa Deployment con il nome del deployment corrente più -canary.

  3. Cloud Deploy modifica il servizio per regolare il selettore in modo da selezionare i pod nel deployment corrente e i pod canary.

    Cloud Deploy calcola il numero di pod da utilizzare per il canary in base al calcolo descritto qui. Questo calcolo varia a seconda che attivi o disattivi il provisioning eccessivo dei pod.

    Se passiamo alla fase stable, Cloud Deploy aggiunge le etichette da utilizzare per abbinare i pod, in modo che siano disponibili per le esecuzioni canary successive.

    Cloud Deploy crea un deployment che include la percentuale di pod specifica per fase, aggiornandola per ogni fase. Per farlo, viene calcolato il numero di pod come percentuale del numero di pod originale. Ciò può comportare una suddivisione del traffico non esatta. Se hai bisogno di una suddivisione esatta del traffico, puoi utilizzare l'API Gateway.

    Inoltre, i secret e i ConfigMap vengono copiati e rinominati con -canary.

  4. Durante la fase stable, il deployment -canary viene ridotto a zero e il deployment originale viene sostituito con il nuovo deployment.

    Cloud Deploy non modifica il deployment originale fino alla fasestable.

Cloud Deploy esegue il provisioning dei pod per raggiungere il più possibile la percentuale di canary richiesta. Si basa sul numero di pod, non sul traffico verso i pod. Se vuoi che il canary si basi sul traffico, devi utilizzare l'API Gateway.

Per il canary basato sulla rete GKE, puoi abilitare o disattivare il provisioning eccessivo dei pod. Le sezioni seguenti descrivono come Cloud Deploy calcola il numero di pod da eseguire il provisioning per il deployment canary per ogni fase canary.

Provisioning dei pod con l'overprovisioning abilitato

L'attivazione del provisioning eccessivo (disablePodOverprovisioning: false) consente a Cloud Deploy di creare pod aggiuntivi sufficienti per eseguire la percentuale di canary che preferisci, in base al numero di pod che eseguono il deployment esistente. La formula seguente mostra come Cloud Deploy calcola il numero di pod da eseguire il provisioning per il deployment canary per ogni fase canary, quando è attivato il provisioning eccessivo dei pod:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Con questa formula, il numero di repliche corrente (il numero di pod che hai già, prima di questo canary) viene moltiplicato per la percentuale del canary per la fase e il risultato viene diviso per (100 meno la percentuale).

Ad esempio, se hai già 4 pod e la fase canary è del 50%, il numero di pod canary è 4. Il risultato di 100-percentage viene utilizzato come percentuale: 100-50=50, considerato come .50.

L'overprovisioning dei pod è il comportamento predefinito.

Provisioning dei pod con l'overprovisioning disattivato

Puoi disattivare il provisioning eccessivo (disablePodOverprovisioning: true) per assicurarti che Cloud Deploy non aumenti il numero di repliche.

La formula seguente mostra come Cloud Deploy calcola il provisioning dei pod per il deployment canary per ogni fase canary, quando il provisioning eccessivo dei pod è disattivato:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

In questa formula, ReplicaCountOfCanaryDeploymentOnCluster esiste solo se esisteva già una fase canary. Se si tratta della prima fase canary, non c'è ReplicaCountOfCanaryDeploymentOnCluster.

Se inizi con 4 pod, questo numero viene moltiplicato per la percentuale del canary (ad esempio il 50% o .5) per ottenere 2. Di conseguenza, il deployment originale viene ora ridotto a 2 e vengono creati 2 nuovi pod per il deployment canary. Se poi hai una fase canary del 75%, hai 2 (deployment originale) +2 (prima fase canary), *.75, per ottenere 3 pod canary e 1 pod che eseguono il deployment originale.

Gateway GKE/Enterprise

Ecco come Cloud Deploy esegue un deployment canary in GKE e GKE Enterprise utilizzando l'API Gateway:

  1. Oltre ai riferimenti a Deployment e Servizio, fornisci una risorsa HTTPRoute con una regola backendRefs che fa riferimento al Servizio.

  2. 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.

    Inoltre, vengono copiati anche i secret, i ConfigMap e gli Horizontal Pod Autoscaler e rinominati con -canary.

  3. Per ogni fase canary, Cloud Deploy modifica HTTPRoute per aggiornare il peso tra i pod del deployment originale e i pod del deployment canary in base alla percentuale per quella fase.

    Poiché può verificarsi un ritardo nella propagazione delle modifiche alle risorse HTTPRoute, puoi includere la proprietà routeUpdateWaitTime nella configurazione in modo che il sistema attenda un determinato periodo di tempo per questa propagazione.

  4. Durante la fase stable, il deployment -canary viene ridotto a zero e il deployment originale viene aggiornato in modo da utilizzare il deployment della nuova release.

    Inoltre, HTTPRoute è ora impostato sul valore originale che hai fornito.

    Cloud Deploy non modifica il deployment o il servizio originale fino alla fase stable.

Cloud Run

Ecco come Cloud Deploy esegue un deployment canary per Cloud Run:

  • Per un deployment canary su Cloud Run, non fornire una traffic stanza nel file YAML del servizio.

  • Quando crei un nuovo deployment canary, Cloud Deploy suddivide il traffico tra la revisione precedente di cui è stato eseguito il deployment da Cloud Deploy e una nuova revisione.

Se vuoi vedere le differenze tra le fasi di un deployment canary, puoi visualizzare le modifiche nel manifest visualizzato per fase disponibile nell'inspector di release. Puoi farlo anche prima dell'inizio del rollout. Inoltre, se utilizzi il deployment parallelo, puoi anche ispezionare il manifest visualizzato di ogni account secondario.

Configurare un deployment canary

Questa sezione descrive come configurare la pipeline di importazione e i target per un deployment canary.

Le istruzioni riportate qui includono solo le informazioni specifiche per la configurazione canary. Nel documento Esegui il deployment dell'applicazione sono riportate le istruzioni generali per configurare ed eseguire la pipeline di deployment.

Assicurati di disporre delle autorizzazioni necessarie

Oltre alle altre autorizzazioni di 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 la sezione Ruoli e autorizzazioni IAM.

Prepara skaffold.yaml

Come per un deployment standard, il canary richiede un file skaffold.yaml, che definisce la modalità di rendering e deployment dei manifest e delle definizioni dei servizi.

Il skaffold.yaml che crei per un deployment canary non ha requisiti speciali oltre a quelli necessari per il deployment standard.

Prepara il manifest o la definizione del servizio

Come per un deployment standard, il canary richiede un manifest Kubernetes o una definizione del servizio Cloud Run.

GKE e GKE Enterprise

Per la versione canary, il manifest deve avere quanto segue:

  • Un deployment e un servizio.

  • Il servizio deve definire un selettore, che deve selezionare i pod del deployment specificato. Il valore predefinito è app.

  • Se utilizzi un canary basato sull'API Gateway, il file manifest deve contenere anche un HTTPRoute.

Cloud Run

Per il canary su Cloud Run, è sufficiente il normale file di definizione del servizio Cloud Run, ma senza una stanza traffic. Cloud Deploy gestisce la suddivisione del traffico tra l'ultima revisione riuscita e la nuova revisione.

Configurare un canary automatico

Le istruzioni riportate di seguito sono per Cloud Run e gli scopi di reti basate su servizi GKE e GKE Enterprise. Se utilizzi l'API Kubernetes Gateway con GKE o GKE Enterprise, consulta questa documentazione.

Configura il canary automatico nella definizione della pipeline di distribuzione:

GKE e GKE Enterprise

Nella fase della pipeline, includi una proprietà strategy, come segue:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

In questa configurazione…

  • SERVICE_NAME è il nome del servizio Kubernetes, definito nel manifest.

  • DEPLOYMENT_NAME è il nome del deployment Kubernetes, definito nel manifest.

  • LABEL è un'etichetta del selettore di pod. Deve corrispondere al selettore di etichette nel servizio Kubernetes definito nel manifest. Questa opzione è facoltativa. Il valore predefinito è app.

  • PERCENTAGES è un elenco di valori percentuale separati da virgola che rappresentano gli incrementi canary, ad esempio [5, 25, 50].

    Inoltre, non è incluso 100, perché il deployment al 100% è presunto nel canary e viene gestito dalla fase stable.

  • Puoi attivare la verifica del deployment (verify: true). In questo caso, in ogni fase viene attivato un job verify.

  • PREDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire dopo il deployment.

Cloud Run

Nella fase della pipeline, includi una proprietà strategy, come segue:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

In questa configurazione…

  • PERCENTAGES è un elenco di valori percentuale separati da virgola che rappresentano gli incrementi canary, ad esempio [25, 50, 75]. Tieni presente che non è inclusa la fase 100, perché il deployment al 100% è presunto nel canary e viene gestito dalla fase stable.

  • Puoi attivare la verifica del deployment (verify: true). In questo caso, a ogni fase canary viene aggiunto un job verify.

  • PREDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire dopo il deployment.

Configurare un canary personalizzato

Puoi configurare il canary manualmente anziché fare affidamento sull'automazione fornita da Cloud Deploy. Con la configurazione canary personalizzata, nella definizione della pipeline di distribuzione specifichi quanto segue:

  • Nomi delle fasi di implementazione

    In un canary completamente automatizzato, Cloud Deploy nomina le fasi per te (ad esempio canary-25, canary-75, stable). Con un canary personalizzato, tuttavia, puoi assegnare a ogni fase un nome qualsiasi, purché sia univoco tra tutte le fasi di questo canary e rispetti le limitazioni relative ai nomi delle risorse. Tuttavia, il nome della fase finale (100%) deve essere stable.

  • Obiettivi percentuali per ogni fase

    Specifica le percentuali separatamente, per fase.

  • Profili Skaffold da utilizzare per la fase

    Puoi utilizzare un profilo Skaffold separato per ogni fase, lo stesso profilo o qualsiasi combinazione. Inoltre, ogni profilo può utilizzare un manifest Kubernetes o una definizione di servizio Cloud Run diversi. Puoi anche utilizzare più di un profilo per una determinata fase. Cloud Deploy li combina.

  • Indica se esiste un job di verifica per la fase

    Ricorda che se attivi la verifica, devi anche configurare il tuo skaffold.yaml per la verifica.

  • Indica se sono presenti job di predeployment o postdeployment per la fase

    Se attivi job di predeployment o postdeployment, devi configurare skaffold.yaml per questi job.

Tutti i tipi di target sono supportati per il canary personalizzato.

Elementi di configurazione canary personalizzati

Il seguente codice YAML mostra la configurazione per le fasi del deployment canary completamente personalizzato:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

In questo file YAML

  • PHASE1_NAME

    È il nome della fase. Ogni nome di fase deve essere univoco.

  • [ "PROFILE_NAME" ]

    È il nome del profilo da utilizzare per la fase. Puoi utilizzare lo stesso profilo per ogni fase, uno diverso per ogni fase o qualsiasi combinazione. Inoltre, puoi specificare più di un profilo. Cloud Deploy utilizza tutti i profili specificati, oltre al profilo o al manifest utilizzato dalla fase complessiva.

  • stable

    La fase finale deve essere denominata stable.

  • PERCENTAGE1

    È la percentuale da eseguire per la prima fase. Ogni fase deve avere un valore percentuale univoco, che deve essere una percentuale intera (non 10.5, ad esempio) e le fasi devono essere in ordine crescente.

  • verify: true|false

    Indica a Cloud Deploy se includere un job di verifica per la fase. Tieni presente che per ogni fase in cui viene utilizzata la verifica, Skaffold utilizza lo stesso profilo per la verifica specificato per il rendering e il deployment per quella fase.

  • PREDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata che vuoi eseguire dopo il deployment.

La percentuale per l'ultima fase deve essere 100. Le fasi vengono eseguite in base all'ordine in cui le configuri in questa stanza ​customCanaryDeployment, ma se i valori percentuali non sono in ordine crescente, il comando per registrare la pipeline di importazione non va a buon fine e viene visualizzato un errore.

Tieni presente che la configurazione di un canary personalizzato non include una stanzaruntimeConfig. Se includi runtimeConfig, viene considerato un canary automatizzato personalizzato.

Configurare un canary automatico personalizzato

Un canary automatizzato personalizzato è simile a un canary personalizzato perché specifichi le fasi del canary separate, con nomi di fasi personalizzate, valori percentuali, profili Skaffold, job di verifica e job di predeployment e postdeployment. Tuttavia, con un canary personalizzato non fornisci le configurations che definiscono la ripartizione del traffico. Lo fa Cloud Deploy per te, ma fornisci comunque i profili Skaffold da utilizzare per ogni fase.

Per configurare un canary automatico personalizzato, includi una stanza runtimeConfig, come mostrato qui, e la stanza customCanaryDeployment, come mostrato qui.

Configurare un deployment canary utilizzando la rete mesh di servizi dell'API Kubernetes Gateway

Sebbene sia possibile utilizzare un deployment canary di Cloud Deploy per eseguire il deployment dell'applicazione nella rete basata su servizi Kubernetes, un'alternativa è utilizzare il service mesh API Gateway di Kubernetes. Questa sezione descrive come eseguire questa operazione.

Puoi utilizzare l'API Gateway con Istio o qualsiasi implementazione supportata.

  1. Configura le risorse dell'API Gateway:

    Si tratta solo di esempi.

  2. Nel manifest Kubernetes fornito a Cloud Deploy quando hai creato la release, includi quanto segue:

    • Un HTTPRoute che fa riferimento alla risorsa Gateway

    • Un deployment

    • Un servizio

  3. Configura la pipeline di importazione e la destinazione a cui eseguirai il deployment Canary:

    • La configurazione per il target è la stessa di qualsiasi altro target.

    • La configurazione della pipeline di importazione, nella sequenza di progressione per il target specifico, include una stanza gatewayServiceMesh per fare riferimento alla configurazione dell'API Kubernetes Gateway HTTPRoute, 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 preferisci.

      • SERVICE è la configurazione del servizio, obbligatoria per i deployment canary in GKE e GKE Enterprise.

      • DEPLOYMENT è la configurazione del deployment, obbligatoria per Cloud Deploy per i deployment canary in GKE e GKE Enterprise.

      • WAIT_TIME è il tempo necessario a Cloud Deploy per attendere il completamento della propagazione delle modifiche alla risorsa HTTPRoute, in modo da evitare la perdita di richieste. Ad esempio: routeUpdateWaitTime: 60s.

        Se esegui il canary utilizzando l'API Gateway senza Istio e l'API Gateway è collegata a un bilanciatore del carico Google Cloud, una piccola quantità di traffico potrebbe andare persa quando l'istanza canary viene ridotta. Puoi configurare questa impostazione se noti questo comportamento.

      • LABEL è un'etichetta del selettore di pod. Deve corrispondere al selettore di etichette nel servizio e nel deployment Kubernetes definiti nel manifest. Questa opzione è facoltativa. Il valore predefinito è app.

Utilizzare il deployment parallelo con una strategia di deployment canary

Puoi eseguire un deployment canary utilizzando il deployment parallelo. Ciò significa che la destinazione in cui esegui il deployment progressivamente può includere due o più obiettivi secondari. Ad esempio, puoi eseguire il deployment progressivamente in cluster in regioni diverse contemporaneamente.

Qual è la differenza tra un canary parallelo e i canary a singolo target

  • Come per il deployment canary con un solo target, se esegui il deployment in destinazione GKE, devi disporre di una configurazione di deployment Kubernetes e di una configurazione di servizio Kubernetes nel manifest.

  • Come per il deployment canary con un solo target, la configurazione della pipeline di distribuzione deve includere una stanza strategy.canary all'interno della definizione della fase per la fase applicabile.

  • Inoltre, devi configurare un target multiplo e configurare i target secondari a cui fa riferimento il target multiplo.

  • Quando crei una release, vengono creati un implementazione del controller e le implementazioni secondarie.

    Entrambi i tipi di implementazione, principale e secondario, hanno fasi separate per tutte le percentuali di canary configurate e una fase stable per il canary al 100%.

  • Non puoi avanzare un'implementazione secondaria.

    Puoi avanzare solo le implementazioni dei controller. Quando avanzi l'implementazione del controller alla fase successiva, anche le implementazioni secondarie vengono avanzate da Cloud Deploy.

  • Non puoi riprovare i job non riusciti nell'implementazione del controller.

    Puoi riprovare un job solo nelle implementazioni secondarie.

  • Non puoi ignorare i job non riusciti nell'implementazione del controller.

    Puoi ignorare i job non riusciti solo nelle implementazioni secondarie.

  • Puoi annullare l'implementazione di un controller, ma non puoi annullare le implementazioni secondarie.

  • Puoi terminare le esecuzioni dei job solo in un'implementazione secondaria, non in un'implementazione del controller.

Cosa fare se un'implementazione parallela non va a buon fine in canary

Quando un'implementazione secondaria non va a buon fine, l'implementazione del controller può passare a stati diversi, a seconda di cosa succede con le implementazioni secondarie:

  • Se una o più implementazioni secondarie non riescono, ma almeno una è ancora IN_PROGRESS, l'implementazione del controller rimane IN_PROGRESS.

  • Se una o più implementazioni secondarie non riescono, ma almeno una riesce, l'implementazione del controller è HALTED se ci sono altre fasi dopo quella corrente.

    Se si tratta della fase stable, l'implementazione del controller è FAILED.

    HALTED ti offre la possibilità di ignorare, riprovare i job non riusciti nell'implementazione secondaria non riuscita oppure annullare l'implementazione del controller e impedire ulteriori azioni sulle implementazioni secondarie.

  • Se l'implementazione del controller è in stato HALTED a causa di un'implementazione secondaria non riuscita e ignori il job non riuscito nell'implementazione secondaria, l'implementazione del controller torna allo stato IN_PROGRESS.

Esegui il deployment di un'entità HTTPRoute in un altro cluster

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, nella configurazione della strategia canary utilizzi una stanza routeDestinations 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. Inoltre, crei una stanza associatedEntities nella configurazione del target per identificare i cluster.

  1. Configura associatedEntities sul tuo target.

    Ogni entità è un cluster in cui Cloud Deploy eseguirà il deployment di HTTPRoute e, facoltativamente, del servizio Kubernetes. Nella definizione del target, includi una stanza associatedEntities:

    associatedEntities:
  [KEY]:
    gkeClusters:
    - cluster: [PATH]
      internalIp: [true|false]
      proxyUrl:

    Dove:

    • KEY è un nome arbitrario per questo gruppo di entità associate. Lo utilizzerai per fare riferimento alle entità di routeDestinations nella configurazione del canary.

    • PATH è il percorso della risorsa che identifica il cluster GKE dove verrà eseguito il deployment di HTTPRoute (e facoltativamente del servizio).

    • internalIp indica se vuoi utilizzare o meno l'IP interno (IP privato) se nel cluster sono configurati sia un IP interno sia un IP pubblico. Il valore predefinito è false.

    Puoi includere un numero qualsiasi di cluster, con o senza internalIp.

  2. Configura routeDestinations nella configurazione canary.

    Ogni destinazione della route fa riferimento a una stanza associatedEntities e indica se eseguire o meno il deployment del servizio anche nel cluster alternativo. Aggiungi quanto segue all'interno della stanza gatewayServiceMesh nella configurazione canary:

    routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]

    Dove:

    • KEY è il nome configurato nel target, in associatedEntities. Utilizza questo nome per fare riferimento alle entità di routeDestinations nella configurazione del canary.

      Puoi anche fornire il valore @self per eseguire il deployment di HTTPRoute nel cluster di destinazione, oltre che nella 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 configurato

Per eseguire il deployment canary:

  1. Registra la pipeline di distribuzione e i target configurati.

    gcloud deploy apply --file=PIPELINE

    La pipeline di distribuzione include la configurazione canary automatica o personalizzata per il runtime scelto.

    Questo comando presuppone che i target siano definiti nello stesso file o che altrimenti siano già stati registrati. In caso contrario, assicurati di registrare anche i tuoi target.

  2. Crea una release:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    La pipeline di distribuzione identificata da PIPELINE_NAME contiene la configurazione canary automatica o personalizzata descritta in questo documento.

  3. Esegui l'avanzamento del 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 in corso per la quale stai passando alla fase successiva.

    RELEASE_NAME è il nome della release di cui fa parte questo rollout.

    PIPELINE_NAME è il nome della pipeline di importazione che utilizzi per gestire il deployment di questa release.

    REGION è il nome della regione in cui è stata creata la release, ad esempio us-central1. Campo obbligatorio.

    Per ulteriori informazioni sul comando gcloud deploy rollouts advance, consulta la documentazione di riferimento di Google Cloud SDK.

    Console Google Cloud

    1. Apri la pagina Pipeline di distribuzione.

    2. Fai clic sulla pipeline indicata nell'elenco delle pipeline di importazione.

      La pagina Dettagli pipeline di distribuzione mostra una rappresentazione grafica dell'avanzamento della pipeline di distribuzione.

    3. Nella scheda Implementazioni, fai clic sul nome dell'implementazione in Dettagli della pipeline di importazione.

      Viene visualizzata la pagina dei dettagli dell'implementazione.

      Dettagli sull'implementazione nella console Google Cloud

      Tieni presente che in questo esempio l'implementazione prevede una fase canary-50 e una fase stable. L'implementazione potrebbe prevedere più fasi o fasi diverse.

    4. Fai clic su Prosegui con implementazione.

      L'implementazione passa alla fase successiva.

Fasi ignorate

Se esegui il deployment di una versione canary e la tua applicazione non è ancora stata dispiata 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