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

Nota. traduzzione: Questa panoramica di Weaveworks presenta e strategie di implementazione di l'applicazioni più populari è mostra cumu i più avanzati ponu esse implementati cù l'operatore Kubernetes Flagger. Hè scrittu in lingua simplice è cuntene diagrammi visuali chì permettenu ancu à l'ingegneri principianti di capiscenu u prublema.

U schema hè pigliatu da un'altra rivista strategie di implementazione fatta in Container Solutions

Unu di i più grandi sfidi in u sviluppu di l'applicazioni native in nuvola oghje hè di accelerà l'implementazione. In un approcciu di microservizi, i sviluppatori digià travaglianu è cuncepiscenu applicazioni cumpletamente modulari, chì permettenu diverse squadre à scrive simultaneamente codice è fà cambiamenti à l'applicazione.

E implementazioni più brevi è più frequenti anu i seguenti benefici:

U tempu à u mercatu hè ridutta.
Nove funzioni ghjunghjenu à l'utilizatori più rapidamente.
I feedback di l'utilizatori ghjunghjenu à a squadra di sviluppu più veloce. Questu significa chì a squadra pò aghjunghje funzioni è risolve i prublemi più rapidamente.
A morale di u sviluppatore aumenta: più funzioni in u sviluppu sò più divertenti di travaglià.

Ma cum'è a frequenza di e versioni aumenta, e probabilità di influenza negativamente l'affidabilità di l'applicazione o l'esperienza di l'utilizatori aumentanu ancu. Hè per quessa chì hè impurtante per l'operazioni è e squadre DevOps di custruisce prucessi è gestisce strategie di implementazione in modu chì minimizza u risicu per u pruduttu è l'utilizatori. (Pudete amparà di più nantu à l'automatizazione di pipeline CI/CD ccà.)

In questu post, discuteremu diverse strategie di implementazione in Kubernetes, cumprese implementazioni rolling è metudi più avanzati cum'è rollouts canari è e so variazioni.

Strategie di implementazione

Ci hè parechje diverse tippi di strategie di implementazione chì pudete aduprà secondu u vostru scopu. Per esempiu, pudete avè bisognu di fà cambiamenti à un certu ambiente per più teste, o à un sottogruppu di utilizatori / clienti, o pudete avè bisognu di fà una prova limitata di l'utilizatori prima di fà una funzione. publicu.

Rolling (graduale, implementazione "rolling")

Questa hè a strategia di implementazione standard in Kubernetes. Gradualmente, unu per unu, rimpiazza i pods cù l'antica versione di l'applicazione cù pods cù a nova versione - senza cluster downtime.

Kubernetes aspetta finu à chì i novi pods sò pronti à travaglià (verificate cù l'usu teste di prontezza), prima di principià a rotolare i vechji. Se si verifica un prublema, questa aghjurnazione rolling pò esse abortita senza piantà tuttu u cluster. In u schedariu YAML chì descrive u tipu di implementazione, a nova maghjina rimpiazza a vechja maghjina:

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 paràmetri di l'aghjurnamentu di rollover ponu esse specificati in u schedariu manifestu:

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

Ricreate

In questu tipu più simplice di implementazione, i vechji pods sò uccisi in una volta è rimpiazzati cù novi:

U manifestu currispundente s'assumiglia à questu:

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

Blu/Verde (implementazioni blu-verde)

A strategia di implementazione blu-verde (a volte chjamata ancu rossu / neru) implica a implementazione simultanea di e versioni vechje (verde) è novi (blu) di l'applicazione. Dopu avè publicatu e duie versioni, l'utilizatori regulari anu accessu à u verde, mentre chì u blu hè dispunibule per a squadra QA per automatizà e teste per mezu di un serviziu separatu o di u portu direttu:

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

Dopu chì a versione blu (nova) hè stata pruvata è a so liberazione hè stata appruvata, u serviziu cambia à questu, è a versione verde (vecchia) hè plegata:

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

Canary (spiegazioni canarini)

I rollouts canarini sò simili à i rollouts blu-verde, ma anu megliu cuntrollu è usu prugressiva avvicinamentu passu à passu. Stu tipu include parechje strategie diverse, cumprese i lanciamenti "stealth" è a prova A / B.

Questa strategia hè aduprata quandu ci hè bisognu di pruvà una nova funziunalità, di solitu in u backend di l'applicazione. L'essenza di l'approcciu hè di creà dui servitori quasi idèntici: unu serve quasi tutti l'utilizatori, è l'altru, cù novi funzioni, serve solu un picculu subgruppu di utilizatori, dopu chì i risultati di u so travagliu sò paragunati. Se tuttu passa senza errori, a nova versione hè gradualmente implementata in tutta l'infrastruttura.

Ancu s'è sta strategia pò esse implementata solu cù Kubernetes, rimpiazzà i vechji pods cù novi, hè assai più còmuda è simplice di utilizà una rete di serviziu cum'è Istio.

Per esempiu, pudete avè dui manifesti diffirenti in Git: un manifestu regulare cù l'etichetta 0.1.0 è un manifestu canarinu cù l'etichetta 0.2.0. Cambiendu i pesi in u manifestu di a porta virtuale Istio, pudete cuntrullà a distribuzione di u trafficu trà sti dui implementazioni:

Per una guida passo-passo per implementare implementazioni canarie usando Istio, vede Flussi di travagliu GitOps cù Istio. (Nota. transl.: Avemu ancu traduttu materiale nantu à i rollouts canari in Istio ccà.)

Implementazioni Canarie cù Weaveworks Flagger

Bandiera di Weaveworks permette à voi à facirmenti è effittivamenti gestisce rollouts canari.

Flagger automatizza u travagliu cun elli. Utiliza Istio o AWS App Mesh per indirizzà è cambià u trafficu, è e metriche Prometheus per analizà i risultati. Inoltre, l'analisi di i dispiegamenti canarini pò esse cumplementati cù webhooks per fà teste di accettazione, teste di carica, è qualsiasi altri tipi di cuntrolli.

Basatu annantu à l'implementazione di Kubernetes è, se ne necessariu, a scala horizontale di pods (HPA), Flagger crea insemi d'uggetti (implementazioni Kubernetes, servizii ClusterIP è servizii virtuali Istio o App Mesh) per analizà è implementà implementazioni canari:

Implementazione di u ciclu di cuntrollu (circula di cuntrollu),Flagger cambia gradualmente u trafficu à u servitore canarinu, mentre misurà simultaneamente e metriche di rendiment chjave cum'è u percentualità di richieste HTTP successu, a durata media di a dumanda è a salute di pod. Basatu nantu à l'analisi di KPI (Indicatori di Rendimentu Chjave), u canarinu cresce o sfondate è i risultati di l'analisi sò publicati in Slack. A descrizzione è a dimostrazione di stu prucessu pò esse truvata in u materiale Consegna Progressiva per App Mesh.

Impiegazioni scure (oculate) o A/B

A implementazione di stealth hè una altra variazione di a strategia canaria (chì, per via, Flagger pò ancu travaglià). A diffarenza trà implementazioni stealth è canarini hè chì e implementazioni stealth trattanu cù u frontend piuttostu chè u backend cum'è implementazioni canari.

Un altru nome per queste implementazioni hè a prova A / B. Invece di rende a nova funzione dispunibule per tutti l'utilizatori, hè offerta à solu una parte limitata di elli. Di genere, questi utilizatori ùn sanu micca chì sò testatori pionieri (da quì u terminu "implementazione furtiva").

Utilizà i switches di funziunalità (funzione basculante) è altri arnesi, pudete monitorà cumu l'utilizatori interagiscenu cù a nova funzione, s'ellu sò ingaghjati da questu, o s'ellu trovanu a nova interfaccia d'utilizatore confusa, è altri tipi di metrica.

Implementazioni di Flagger è A/B

In più di u routing basatu in pesu, Flagger pò ancu indirizzà u trafficu à u servitore canarinu basatu nantu à i paràmetri HTTP. In a prova A/B, pudete aduprà l'intestazione HTTP o i cookies per destinà un segmentu specificu di l'utilizatori. Questu hè soprattuttu efficace in u casu di l'applicazioni di frontend chì necessitanu a cunnessione di sessione à u servitore (affinità di sessione). Più infurmazione pò esse truvata in a documentazione di Flagger.

L'auteur exprime sa gratitude Stefan Prodan, Ingegnere di Weaveworks (è creatore di Flagger), per tutti questi mudelli di implementazione maravigghiusu.

PS da u traduttore

Leghjite puru nant'à u nostru blog:

Source: www.habr.com

Strategie di implementazione di Kubernetes: rolling, recreate, blue/green, canary, dark (test A/B)