Utilizza una strategia di deployment canary

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

Che cos'è un deployment canary?

Un deployment canary è un'implementazione progressiva di un'applicazione che divide il traffico tra una versione già implementata e una nuova, 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, inclusi i seguenti:

Canary funziona anche con i multi-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 su GKE o GKE Enterprise, ad esempio, esegui il deployment della nuova versione dell'applicazione su un numero limitato di pod. La versione precedente continuerà a essere eseguita, ma con una maggiore quantità di traffico inviato ai nuovi pod.

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

Tipi di canary

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

  • Automatico

    Con un deployment canary automatizzato (per service networking, API Gateway o Cloud Run), configuri Cloud Deploy con una serie di percentuali che esprimono un deployment progressivo. Cloud Deploy esegue operazioni aggiuntive per tuo conto per ripartire le percentuali di traffico tra le versioni precedente e nuova.

  • Personalizzato e automatizzato

    Per un canary personalizzato automatizzato (per service networking, gateway api o Cloud Run), puoi fornire quanto segue:

    • Il nome della fase
    • L'obiettivo in percentuale
    • Il profilo Skaffold da utilizzare per la fase
    • Se includere o meno un job di verifica
    • Se includere o meno un job pre-deploy o post-deploy o entrambi

    Tuttavia, non è necessario fornire informazioni sul bilanciamento del traffico. Cloud Deploy crea le risorse necessarie (per il service networking, l'API Gateway o Cloud Run).

  • Personalizzato

    Con un canary personalizzato (per service networking, gateway api o Cloud Run), configuri ogni fase canary separatamente, inclusi i seguenti elementi:

    • Il nome della fase
    • L'obiettivo in percentuale
    • Il profilo Skaffold da utilizzare per la fase
    • Se includere o meno un job di verifica
    • Se includere o meno un job pre-deploy o post-deploy o entrambi

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

Fasi di un deployment canary

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

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

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

Puoi scoprire di più su fasi di implementazione, job ed esecuzioni di job in Gestire le implementazioni.

Utilizza il deployment parallelo con una strategia di deployment canary

Puoi eseguire un deployment canary utilizzando il deployment parallelo. Ciò significa che il target a cui esegui il deployment progressivo può comprendere due o più target secondari. Ad esempio, puoi eseguire il deployment in modo progressivo nei cluster in regioni separate contemporaneamente.

In che modo un canary parallelo è diverso dai canary a un solo target

  • Come per il deployment canary a un solo target, se esegui il deployment sui target GKE, nel manifest sono necessarie una configurazione di deployment Kubernetes e una configurazione del servizio Kubernetes.

  • Come per il deployment canary a un solo target, la configurazione della pipeline di distribuzione deve includere una sezione 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 create un'implementazione del controller e le implementazioni figlio.

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

  • Non puoi avanzare un'implementazione figlio.

    Puoi avanzare solo le implementazioni del 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 figlio.

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

Cosa fare se un rollout parallelo non va a buon fine in canary

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

  • 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 sono presenti altre fasi dopo quella attuale.

    Se questa è la 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 è nello 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.

Passaggi successivi