Nota di traduzione: Questo materiale di riepilogo di Weaveworks introduce le strategie di distribuzione delle applicazioni più popolari e spiega come attuare le più avanzate di esse tramite il Kubernetes operator Flagger. È scritto in un linguaggio semplice e contiene diagrammi chiari che permettono anche ai neofiti di comprendere l'argomento.
Il diagramma è tratto da delle strategie di distribuzione, realizzata in Container Solutions
Una delle maggiori sfide nello sviluppo di applicazioni cloud native oggi è accelerare il deployment. Con un approccio a microservizi, gli sviluppatori lavorano già con applicazioni completamente modulari e le progettano in modo che diversi team possano scrivere codice e apportare modifiche all'applicazione in parallelo.
Distribuzioni più brevi e frequenti offrono i seguenti vantaggi:
- Riduzione del time-to-market.
- Nuove funzionalità arrivano più rapidamente agli utenti.
- I feedback degli utenti raggiungono più velocemente il team di sviluppo. Ciò significa che il team può aggiungere funzionalità e risolvere problemi in modo più tempestivo.
- Aumenta il morale degli sviluppatori: lavorare su un numero maggiore di funzionalità rende il lavoro più interessante.
Tuttavia, con l'aumento della frequenza delle versioni, aumenta anche il rischio di influenzare negativamente l'affidabilità dell'applicazione o l'esperienza dell'utente. È per questo motivo che i team di operations e DevOps devono costruire processi e gestire le strategie di deployment in modo da minimizzare i rischi per il prodotto e per gli utenti. (Scopri di più sull'automazione della CI/CD pipeline .)
In questo articolo discuteremo varie strategie di deployment in Kubernetes, includendo distribuzioni rolling e metodi più avanzati, come i canary deployment e le loro varianti.
Strategie di deploy
Esistono diversi tipi di strategie di distribuzione che possono essere utilizzate a seconda dell'obiettivo. Ad esempio, potresti aver bisogno di apportare modifiche a un ambiente per ulteriori test, o a un sottoinsieme di utenti/clienti, oppure potrebbe essere necessario effettuare un test limitato sugli utenti prima di rendere una funzionalità pubblica.
Rolling (distribuzione progressiva)
Questa è la strategia di distribuzione standard in Kubernetes. Sostituisce gradualmente, uno dopo l'altro, i pod della vecchia versione dell'applicazione con quelli della nuova versione, senza downtime del cluster.
Kubernetes aspetta che i nuovi pod siano pronti per il lavoro (verificandoli tramite ) prima di iniziare a ritirare i vecchi. Se c'è un problema, questo aggiornamento progressivo può essere interrotto senza fermare 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: 8080I parametri per l'aggiornamento progressivo possono essere specificati nel file di manifesto:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (ri-creazione)
In questo tipo di distribuzione più semplice, i pod vecchi vengono terminati tutti insieme e sostituiti con nuovi:
Il manifesto corrispondente appare circa così:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (distribuzioni blue-green)
La strategia blue-green (a volte chiamata anche red/black) prevede il contemporaneo deployment della versione vecchia (green) e di quella nuova (blue) dell'applicazione. Dopo il deployment di entrambe le versioni, gli utenti normali hanno accesso alla versione green, mentre la blue è disponibile per il team QA per test automatizzati tramite un servizio dedicato o un port forwarding diretto:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Dopo che la versione blue (nuova) è stata testata e il suo rilascio è stato approvato, il servizio viene commutato su di essa, mentre la versione green (vecchia) viene ritirata:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (distribuzioni canary)
Le distribuzioni canary sono simili alle blue-green, ma sono meglio gestite e utilizzano progressivo. Questo tipo comprende diverse strategie, tra cui i 'lanci stealth' e il testing A/B.
Questa strategia viene applicata quando è necessario testare una nuova funzionalità, solitamente nel backend dell'applicazione. Il concetto alla base è creare due server praticamente identici: uno gestisce quasi tutti gli utenti, mentre l'altro, con nuove funzionalità, gestisce solo un piccolo sottoinsieme di utenti, dopo di che i risultati vengono confrontati. Se tutto procede senza errori, la nuova versione viene gradualmente distribuita all'intera infrastruttura.
Sebbene questa strategia possa essere attuata esclusivamente con gli strumenti di 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: uno normale con il tag 0.1.0 e uno "canarino" con il tag 0.2.0. Modificando i pesi nel manifesto del gateway virtuale Istio, è possibile gestire la distribuzione del traffico tra questi due deployment:
Una guida passo-passo per implementare i deployment canarini con Istio può essere trovata nel materiale . (Nota del traduttore.: Abbiamo anche tradotto il materiale sui deployment canarini in Istio .)
Canary Deployments with Weaveworks Flagger
consente di gestire facilmente ed efficacemente i deployment canarini.
Flagger automatizza il lavoro con essi. Utilizza Istio o AWS App Mesh per instradare e commutare il traffico, oltre a metriche Prometheus per analizzare i risultati. Inoltre, l'analisi dei deployment canarini può essere arricchita con webhook per eseguire test di accettazione, test di carico e qualsiasi altro tipo di controllo.
Basato su un deployment di Kubernetes e, se necessario, sullo scaling orizzontale dei pod (HPA), Flagger crea set di oggetti (deployment di Kubernetes, servizi ClusterIP e servizi virtuali Istio o App Mesh) per l'analisi e l'implementazione dei deployment canarini:
Implementando un ciclo di controllo (control loop), Flagger instrada gradualmente il traffico verso il server canarino, misurando nel contempo le metriche chiave di performance, come la percentuale di richieste HTTP riuscite, la durata media delle richieste e la salute dei pod. Basandosi sull'analisi delle KPI (Key Performance Indicators), la parte canarino 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 .
Deployment Dark (nascosti) o A/B
Il deployment nascosto è un'altra variazione della strategia canarina (con cui, tra l'altro, Flagger può lavorare). La differenza tra un deployment nascosto e uno canarino è che i deployment nascosti riguardano il frontend, non il backend, come i canarini.
Un altro nome per questi deployment è A/B testing. Invece di rendere disponibile una nuova funzionalità a tutti gli utenti, viene proposta solo a una parte limitata di essi. Di solito questi utenti non sanno di essere i tester pionieri (da qui il termine 'deployment nascosto').
Con i toggles delle funzionalità (feature toggles) e altri strumenti è possibile monitorare come gli utenti interagiscono con la nuova funzionalità, se li coinvolge o se trovano la nuova interfaccia utente confusa, e altre tipologie di metriche.
Flagger e A/B Deployments
Oltre all'instradamento basato sui pesi, Flagger può anche indirizzare il traffico verso il server canarino in base alle impostazioni HTTP. Nello A/B testing possono essere utilizzati gli header HTTP o i cookie per reindirizzare un segmento specifico di utenti. Questo è particolarmente efficace per le applicazioni frontend che richiedono l'affinità della sessione con il server (session affinity). Maggiori informazioni possono essere trovate nella documentazione di Flagger.
L'autore esprime gratitudine , ingegnere di Weaveworks (e creatore di Flagger), per tutte queste fantastiche diagrammi di deployment.
P.S. dal traduttore
Leggete anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
