🥇Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Nota del traduttore: Questo materiale informativo di Weaveworks presenta le strategie di rilascio delle applicazioni più popolari e discute dell'implementazione delle più avanzate di esse attraverso l'operatore Kubernetes Flagger. È scritto in un linguaggio semplice e contiene diagrammi illustrativi che permettono anche ai neofiti di comprendere l'argomento.

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)
Il diagramma è tratto da un'altra recensione delle strategie di rilascio, realizzata da Container Solutions

Una delle sfide maggiori nello sviluppo delle applicazioni cloud-native di oggi è l'accelerazione del deployment. Con un approccio a microservizi, gli sviluppatori lavorano già con applicazioni completamente modulari, progettandole in modo che diversi team possano scrivere codice e apportare modifiche all'applicazione simultaneamente.

Deployment più brevi e frequenti offrono i seguenti vantaggi:

Si riduce il time-to-market.
Nuove funzionalità arrivano più rapidamente agli utenti.
Il feedback degli utenti arriva più velocemente al team di sviluppo. Questo significa che il team può aggiungere funzionalità e risolvere problemi in modo più tempestivo.
Aumenta il morale degli sviluppatori: con un numero maggiore di funzionalità in sviluppo, è più stimolante lavorare.

Ma con l'aumento della frequenza dei rilasci, aumenta anche il rischio di impattare negativamente sull'affidabilità dell'applicazione o sull'esperienza dell'utente. Per questo motivo, è fondamentale per i team operativi e DevOps costruire processi e gestire le strategie di rilascio in modo da minimizzare i rischi per il prodotto e per gli utenti. (Scopri di più sull'automazione del pipeline CI/CD) qui.)

In questa pubblicazione discuteremo delle diverse strategie di deployment in Kubernetes, incluse le rolling deployment e metodi più avanzati come i canary release e le loro varianti.

Strategie di deployment

Esistono diversi tipi di strategie di rilascio che possono essere utilizzate a seconda dell'obiettivo. Ad esempio, potresti aver bisogno di apportare modifiche a un certo ambiente per ulteriori test, o a un sottoinsieme di utenti/clienti, o potrebbe sorgere la necessità di eseguire test limitati sugli utenti prima di rendere una certa funzionalità pubblica.

Rolling (deployment graduale)

Questa è una strategia standard di distribuzione in Kubernetes. Sostituisce gradualmente, uno dopo l'altro, i pod con la vecchia versione dell'applicazione con pod con la nuova versione, senza downtime del cluster.

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Kubernetes attende che i nuovi pod siano pronti a lavorare (verificandoli tramite test di readiness), prima di procedere alla disattivazione dei vecchi. Se si verifica un problema, un aggiornamento in rolling può essere interrotto senza arrestare l'intero cluster. Nel file YAML che descrive il tipo di deployment, la nuova immagine sostituisce la vecchia immagine:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

I parametri dell'aggiornamento in rolling possono essere specificati nel file di manifesto:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

Recreate (ricreazione)

In questo tipo di distribuzione più semplice, i vecchi pod vengono eliminati tutti in una volta e sostituiti da nuovi:

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Il manifesto corrispondente appare così:

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

Blue/Green (distribuzioni blu/verdi)

La strategia di distribuzione blu-verde (a volte chiamata anche rossa/nera) prevede la distribuzione simultanea della versione vecchia (verde) e di quella nuova (blu) dell'applicazione. Dopo il deployment di entrambe le versioni, gli utenti normali accedono alla versione verde, mentre la versione blu è disponibile per il team QA per automatizzare i test tramite un servizio separato o un port forwarding diretto:

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

Dopo che la versione blu (nuova) è stata testata e il suo rilascio è stato approvato, il servizio viene switchato su di essa, mentre la versione verde (vecchia) viene disattivata:

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary (distribuzioni canarie)

Le distribuzioni canarie sono simili a quelle blu-verdi, ma meglio gestibili e utilizzano un approccio progressivo . Questo tipo comprende diverse strategie, tra cui il lancio "soft" e il test A/B.

Questa strategia viene applicata quando è necessario testare una nuova funzionalità, generalmente nel backend dell'applicazione. L'idea alla base dell'approccio è quella di creare due server praticamente identici: uno gestisce quasi tutti gli utenti, mentre l'altro, con le nuove funzioni, gestisce solo un piccolo sottoinsieme di utenti, dopodiché vengono confrontati i risultati del loro funzionamento. Se tutto procede senza errori, la nuova versione viene gradualmente distribuita su tutta l'infrastruttura.

Sebbene questa strategia possa essere realizzata esclusivamente tramite strumenti Kubernetes, sostituendo i vecchi pod con nuovi, è molto più conveniente e semplice utilizzare un service mesh come Istio.

Ad esempio, puoi avere due manifest diversi in Git: uno normale con l'etichetta 0.1.0 e uno "canary" con l'etichetta 0.2.0. Modificando i pesi nel manifesto del gateway virtuale di Istio, puoi gestire la distribuzione del traffico tra questi due deployment:

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Una guida passo passo per implementare i deployment canary utilizzando Istio può essere trovata nel materiale GitOps Workflows with Istio. (Nota di traduzione.: Abbiamo anche tradotto il materiale sui rilasci canary in Istio qui.)

Deployment canary con Weaveworks Flagger

Weaveworks Flagger consente di gestire in modo semplice ed efficace i rilasci canary.

Flagger automatizza il lavoro con loro. Utilizza Istio o AWS App Mesh per la gestione e l'instradamento del traffico, nonché le metriche Prometheus per l'analisi dei risultati. Inoltre, l'analisi dei deployment canary può essere integrata con webhook per effettuare test di accettazione, test di carico e qualsiasi altro tipo di verifica.

Basandosi su un deployment Kubernetes e, se necessario, sullo scaling orizzontale dei pod (HPA), Flagger crea insiemi di oggetti (deployment Kubernetes, servizi ClusterIP e servizi virtuali di Istio o App Mesh) per condurre analisi e implementare rilasci canary:

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Implementando un ciclo di controllo (control loop), Flagger commuta gradualmente il traffico sul server canary, misurando contemporaneamente le metriche chiave delle prestazioni, come la quota di richieste HTTP riuscite, la durata media delle richieste e lo stato dei pod. Sulla base dell'analisi KPI (indicatori chiave di prestazione), la parte canary cresce o si ritira, e i risultati dell'analisi vengono pubblicati su Slack. Una descrizione e una dimostrazione di questo processo possono essere trovate nel materiale Progressive Delivery for App Mesh.

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Distribuzioni oscure (nascoste) o A/B

La distribuzione nascosta è un'altra variazione della strategia canary (con cui, peraltro, Flagger può lavorare). La differenza tra distribuzioni nascoste e canary è che le distribuzioni nascoste si occupano del frontend, a differenza delle canary che si occupano del backend.

Un altro nome per queste distribuzioni è A/B testing. Invece di aprire l'accesso a una nuova funzionalità a tutti gli utenti, questa viene proposta solo a una parte limitata di essi. Di solito, questi utenti non sanno di essere dei tester pionieristici (da qui il termine "distribuzione nascosta").

Utilizzando i feature toggles (interruttori di funzionalità) e altri strumenti è possibile monitorare come gli utenti interagiscono con la nuova funzionalità, se li cattura oppure se trovano l'interfaccia utente confusa, insieme ad altri tipi di metriche.

Strategie di distribuzione in Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)

Flagger e distribuzioni A/B

Oltre alla routing ponderata, Flagger può anche direzionare il traffico a un server canary in base ai parametri HTTP. Durante l'A/B testing, è possibile utilizzare gli header HTTP o i cookie per reindirizzare un certo segmento di utenti. Questo è particolarmente efficace per le applicazioni frontend che richiedono l'affinità della sessione con il server (affinità della sessione). Maggiori informazioni possono essere trovate nella documentazione di Flagger.

L'autore ringrazia Stefan Prodan, ingegnere di Weaveworks (e creatore di Flagger), per tutti questi fantastici schemi di distribuzione.