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

Nota traduzione: Questa panoramica di Weaveworks introduce le strategie di rollout delle applicazioni più popolari e mostra come quelle più avanzate possono essere implementate utilizzando l'operatore Kubernetes Flagger. È scritto in un linguaggio semplice e contiene diagrammi visivi che consentono anche agli ingegneri alle prime armi di comprendere il problema.

Il diagramma è tratto da un'altra recensione strategie di lancio realizzate in Container Solutions

Una delle maggiori sfide nello sviluppo di applicazioni cloud native oggi è l’accelerazione della distribuzione. Nell’approccio basato sui microservizi, gli sviluppatori già lavorano e progettano applicazioni completamente modulari, consentendo a diversi team di scrivere simultaneamente codice e apportare modifiche all’applicazione.

Le distribuzioni più brevi e più frequenti presentano i seguenti vantaggi:

Il tempo di commercializzazione è ridotto.
Le nuove funzionalità raggiungono gli utenti più velocemente.
Il feedback degli utenti raggiunge il team di sviluppo più velocemente. Ciò significa che il team può aggiungere funzionalità e risolvere i problemi più rapidamente.
Il morale degli sviluppatori aumenta: più funzionalità in fase di sviluppo sono più divertenti con cui lavorare.

Ma con l'aumento della frequenza dei rilasci, aumentano anche le possibilità di avere un impatto negativo sull'affidabilità dell'applicazione o sull'esperienza dell'utente. Ecco perché è importante che i team operativi e DevOps creino processi e gestiscano le strategie di distribuzione in modo da ridurre al minimo i rischi per il prodotto e gli utenti. (Puoi saperne di più sull'automazione della pipeline CI/CD qui.)

In questo post discuteremo varie strategie di distribuzione in Kubernetes, incluse distribuzioni in sequenza e metodi più avanzati come i rollout Canary e le loro varianti.

Strategie di distribuzione

Esistono diversi tipi di strategie di distribuzione che puoi utilizzare a seconda del tuo obiettivo. Ad esempio, potresti dover apportare modifiche a un determinato ambiente per ulteriori test o a un sottoinsieme di utenti/clienti, oppure potresti dover eseguire test utente limitati prima di creare una funzionalità disponibile al pubblico.

Rolling (distribuzione graduale, "a rotazione")

Questa è la strategia di distribuzione standard in Kubernetes. Sostituisce gradualmente, uno per uno, i pod della vecchia versione dell'applicazione con i pod della nuova versione, senza tempi di inattività del cluster.

Kubernetes attende finché i nuovi pod non sono pronti per funzionare (controllandoli utilizzando test di prontezza), prima di iniziare ad arrotolare quelli vecchi. Se si verifica un problema, questo aggiornamento in sequenza può essere interrotto senza arrestare l'intero cluster. Nel file YAML che descrive il tipo di distribuzione, 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 di aggiornamento del rollover possono essere specificati nel file manifest:

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

Ricreare

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

Il manifest corrispondente è simile al seguente:

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

Blu/Verde (distribuzioni blu-verde)

La strategia di distribuzione blu-verde (a volte chiamata anche rosso/nero) prevede la distribuzione simultanea della vecchia versione (verde) e della nuova (blu) dell'applicazione. Dopo aver pubblicato entrambe le versioni, gli utenti regolari hanno accesso a quella verde, mentre quella blu è disponibile per il team di QA per automatizzare i test attraverso un servizio separato o il port forwarding diretto:

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 passa ad essa e la versione verde (vecchia) viene disattivata:

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

Canary (distribuzioni Canary)

I rollout canarini sono simili ai rollout blu-verdi, ma hanno un controllo e un utilizzo migliori progressivo approccio graduale. Questo tipo include diverse strategie, inclusi lanci “stealth” e test A/B.

Questa strategia viene utilizzata quando è necessario provare alcune nuove funzionalità, solitamente nel backend dell'applicazione. L'essenza dell'approccio è creare due server quasi identici: uno serve quasi tutti gli utenti e l'altro, con nuove funzioni, serve solo un piccolo sottogruppo di utenti, dopo di che vengono confrontati i risultati del loro lavoro. Se tutto procede senza errori, la nuova versione verrà gradualmente estesa all'intera infrastruttura.

Sebbene questa strategia possa essere implementata esclusivamente utilizzando Kubernetes, sostituendo i vecchi pod con quelli nuovi, è molto più comodo e semplice utilizzare un service mesh come Istio.

Ad esempio, potresti avere due diversi manifest in Git: un manifest regolare con il tag 0.1.0 e un manifest canary con il tag 0.2.0. Modificando i pesi nel manifest del gateway virtuale Istio, puoi controllare la distribuzione del traffico tra queste due distribuzioni:

Per una guida passo passo sull'implementazione delle distribuzioni Canary utilizzando Istio, consulta Flussi di lavoro GitOps con Istio. (Nota. trad.: Abbiamo anche tradotto materiale sulle implementazioni di Canary in Istio qui.)

Distribuzioni Canary con Weaveworks Flagger

Segnalatore di Weaveworks ti consente di gestire in modo semplice ed efficace i rollout Canary.

Gli automatismi Flagger lavorano con loro. Utilizza Istio o AWS App Mesh per instradare e commutare il traffico e parametri Prometheus per analizzare i risultati. Inoltre, l'analisi delle distribuzioni Canary può essere integrata con webhook per condurre test di accettazione, test di carico e qualsiasi altro tipo di controllo.

In base alla distribuzione Kubernetes e, se necessario, al ridimensionamento orizzontale dei pod (HPA), Flagger crea set di oggetti (distribuzioni Kubernetes, servizi ClusterIP e servizi virtuali Istio o App Mesh) per analizzare e implementare distribuzioni canary:

Implementazione del ciclo di controllo (ciclo di controllo),Flagger trasferisce gradualmente il traffico al server Canary, misurando contemporaneamente i parametri chiave delle prestazioni come la percentuale di richieste HTTP riuscite, la durata media delle richieste e l'integrità del pod. Sulla base dell'analisi KPI (Key Performance Indicators), il canarino cresce o crolla e i risultati dell'analisi vengono pubblicati su Slack. Una descrizione e dimostrazione di questo processo può essere trovata nel materiale Distribuzione progressiva per App Mesh.

Distribuzioni oscure (nascoste) o A/B

Lo schieramento invisibile è un'altra variante della strategia canary (con cui, tra l'altro, anche Flagger può funzionare). La differenza tra le distribuzioni stealth e canary è che le distribuzioni stealth si occupano del frontend piuttosto che del backend come le distribuzioni canary.

Un altro nome per queste implementazioni è test A/B. Invece di rendere la nuova funzionalità disponibile a tutti gli utenti, viene offerta solo ad una parte limitata di essi. In genere, questi utenti non sono consapevoli di essere pionieri dei tester (da qui il termine "distribuzione invisibile").

Utilizzo degli interruttori di funzionalità (attivazione/disattivazione funzionalità) e altri strumenti, puoi monitorare il modo in cui gli utenti interagiscono con la nuova funzionalità, se ne sono coinvolti o se trovano confusa la nuova interfaccia utente e altri tipi di metriche.

Flagger e implementazioni A/B

Oltre al routing basato sul peso, Flagger può anche instradare il traffico al server Canary in base ai parametri HTTP. Nei test A/B, puoi utilizzare intestazioni HTTP o cookie per indirizzare un segmento specifico di utenti. Ciò è particolarmente efficace nel caso di applicazioni frontend che richiedono l'associazione della sessione al server (affinità di sessione). Maggiori informazioni possono essere trovate nella documentazione di Flagger.

L'autore è grato Stefano Prodan, ingegnere di Weaveworks (e creatore di Flagger), per tutti questi fantastici modelli di distribuzione.

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