🥇Kubernetes deployment strategies: rolling, recreate, blue/green, canary, dark (A/B testing)

Nota. hubad: Kini nga walkthrough gikan sa Weaveworks nagpaila sa pinakasikat nga mga estratehiya sa rollout sa aplikasyon ug kung unsaon nimo pag-implementar ang pinaka-advanced nga mga gamit sa Flagger Kubernetes operator. Gisulat kini sa yano nga pinulongan ug adunay mga visual diagram nga nagtugot bisan sa mga bag-ong inhenyero nga masabtan ang isyu.

Diagram gikuha gikan sa laing pagsusi rollout nga mga estratehiya nga gihimo sa Container Solutions

Usa sa pinakadako nga mga hagit sa pagpalambo sa cloud native nga mga aplikasyon karon mao ang deployment speed. Uban sa usa ka microservice nga pamaagi, ang mga developers nagtrabaho na ug nagdesinyo sa hingpit nga modular nga mga aplikasyon, nga nagtugot sa lain-laing mga team sa pagsulat sa code ug paghimo sa mga kausaban sa aplikasyon sa samang higayon.

Ang mas mubo ug mas kanunay nga pagdeploy adunay mga mosunod nga mga benepisyo:

Gipamubu ang oras sa merkado.
Ang mga bag-ong feature dali nga makuha sa mga tiggamit.
Ang feedback sa user makaabot sa development team nga mas paspas. Kini nagpasabot nga ang team makadugang sa mga feature ug makaayo sa mga isyu nga mas dali.
Nagtaas ang moral sa developer: mas daghang bahin sa pag-uswag ang mas makalingaw sa pagtrabaho.

Apan samtang ang kasubsob sa pag-release motaas, ang kahigayonan sa negatibong epekto sa pagkakasaligan sa app o sa kasinatian sa user modako usab. Mao nga hinungdanon alang sa mga operasyon ug mga koponan sa DevOps nga magtukod mga proseso ug pagdumala sa mga estratehiya sa pag-deploy sa paagi nga makapamenos sa peligro sa produkto ug mga tiggamit. (Aron makakat-on og dugang mahitungod sa pag-automate sa CI/CD pipeline, tan-awa dinhi.)

Sa kini nga post, atong hisgutan ang lainlaing mga estratehiya sa pag-deploy sa Kubernetes, lakip ang mga rolling deployment ug mas abante nga mga pamaagi sama sa canary rollouts ug ang ilang mga variation.

Mga estratehiya sa pagdeploy

Adunay ubay-ubay nga lainlaing mga lahi sa mga estratehiya sa pag-deploy nga mahimong magamit depende sa katuyoan. Pananglitan, tingali kinahanglan nimo nga maghimo mga pagbag-o sa pipila ka palibot alang sa dugang nga pagsulay, o sa usa ka subset sa mga tiggamit/kliyente, o mahimo nimo kinahanglan nga maghimo limitado nga pagsulay sa mga tiggamit sa dili pa maghimo usa ka bahin. publiko.

Rolling (hinayhinay, rolling deployment)

Kini ang sumbanan nga estratehiya sa pagdeploy para sa Kubernetes. Sa hinay-hinay, usa-usa, gipulihan ang mga pod sa daan nga bersyon sa aplikasyon nga adunay mga pod nga adunay bag-ong bersyon - nga wala’y downtime sa cluster.

Ang mga Kubernetes naghulat alang sa bag-ong mga pod nga andam na nga moadto (pagsusi niini sa mga pagsulay sa pagkaandam) sa dili pa ipadayon ang paglukot sa mga daan. Kung adunay mahitabo nga problema, ang ingon nga usa ka rolling update mahimong ma-abort nga dili mohunong sa tibuok cluster. Sa deployment type nga YAML file, ang bag-ong imahe nagpuli sa daan nga imahe:

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

Ang mga parameter sa rolling update mahimong matino sa manifest file:

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

Paghimo pag-usab (re-creation)

Niining pinakasimple nga matang sa deployment, ang mga daan nga pod gipamatay dayon ug gipulihan og bag-o:

Ang katugbang nga manifest ingon niini:

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

Asul/Berde (asul-berde nga pagdeploy)

Ang blue-green nga estratehiya sa pagdeploy (usahay gitawag usab nga pula / itom, i.e. pula-itom) naglakip sa dungan nga pagdeploy sa daan (berde) ug bag-o (asul) nga bersyon sa aplikasyon. Kung ma-host na ang duha nga mga bersyon, ang berde magamit sa kinatibuk-ang tiggamit, samtang ang asul magamit alang sa QA team aron ma-automate ang mga pagsulay pinaagi sa usa ka lahi nga serbisyo o direkta nga pagpasa sa pantalan:

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

Human masulayan ug maaprobahan ang asul (bag-o) nga bersyon alang sa pagpagawas, ang serbisyo gibalhin ngadto niini, ug ang berde (daan) gipamubu:

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

Canary (mga pag-deploy sa canary)

Ang mga rollout sa canary susama sa asul-berde, apan mas maayo nga kontrolado ug gigamit progresibo lakang sa lakang nga pamaagi. Daghang lainlaing mga estratehiya ang nahulog sa kini nga kategorya, lakip ang mga tago nga paglansad ug pagsulay sa A/B.

Gigamit kini nga estratehiya kung kinahanglan nga sulayan ang pipila ka bag-ong kagamitan, kasagaran sa backend sa aplikasyon. Ang diwa sa pamaagi mao ang paghimo sa duha ka halos managsama nga mga server: ang usa nagsilbi sa hapit tanan nga mga tiggamit, ug ang lain, nga adunay bag-ong mga bahin, nagsilbi lamang usa ka gamay nga subgroup sa mga tiggamit, pagkahuman gitandi ang mga sangputanan sa ilang trabaho. Kung ang tanan wala’y mga kasaypanan, ang bag-ong bersyon anam-anam nga gilukot sa tibuuk nga imprastraktura.

Bisan kung kini nga estratehiya mahimong ipatuman nga eksklusibo gamit ang Kubernetes, pag-ilis sa mga daan nga pod sa mga bag-o, mas sayon ug mas sayon ang paggamit sa usa ka service mesh sama sa Istio.

Pananglitan, tingali adunay duha ka lain-laing Git manifests: usa ka regular nga adunay 0.1.0 tag ug usa ka canary nga adunay 0.2.0 tag. Pinaagi sa pagbag-o sa mga gibug-aton sa Istio Virtual Gateway manifest, mahimo nimong kontrolon ang pag-apod-apod sa trapiko tali niining duha ka pag-deploy:

Ang usa ka lakang-sa-lakang nga giya sa pagpatuman sa canary deployment uban sa Istio makita sa GitOps Workflows uban sa Istio. (Nota. transl.: Gihubad usab namo ang materyal mahitungod sa canary rolls sa Istio dinhi.)

Canary deployment uban sa Weaveworks Flagger

Weaveworks Flagger nagtugot sa sayon ug episyente nga pagkontrol sa canary rolls.

Ang Flagger nag-automate sa pagtrabaho uban kanila. Gigamit niini ang Istio o AWS App Mesh aron i-ruta ug ibalhin ang trapiko, ug ang Prometheus metrics aron analisahon ang mga resulta. Dugang pa, ang pag-analisa sa mga pag-deploy sa canary mahimong madugangan sa mga webhook alang sa pagpahigayon sa mga pagsulay sa pagdawat, mga pagsulay sa pagkarga, ug bisan unsang uban pang mga klase sa tseke.

Base sa deployment sa Kubernetes ug, kung gikinahanglan, scale-out pods (HPA), ang Flagger nagmugna og mga set sa mga butang (mga pagdeploy sa Kubernetes, mga serbisyo sa ClusterIP ug Istio o App Mesh virtual nga mga serbisyo) aron pag-analisar ug pagpatuman sa mga deployment sa canary:

Pagpatuman sa usa ka control loop (kontrol nga loop)Ang Flagger hinayhinay nga nagbalhin sa trapiko sa canary server samtang gisukod ang hinungdanon nga mga sukatan sa pasundayag sama sa rate sa kalampusan sa hangyo sa HTTP, kasagaran nga gidugayon sa hangyo, ug kahimsog sa pod. Base sa pagtuki sa KPIs (Key Performance Indicators), ang canary nga bahin motubo o mokunhod, ug ang mga resulta sa pagtuki gipatik sa Slack. Ang usa ka paghulagway ug pagpakita niini nga proseso makita sa materyal Progresibo nga Paghatud alang sa App Mesh.

Ngitngit (gitago) o A/B deployment

Ang stealth deployment usa pa ka kalainan sa diskarte sa canary (nga, sa tinuud, ang Flagger mahimo usab nga magamit). Ang kalainan tali sa stealth ug canary deployment mao nga ang stealth deployment naghisgot sa front end ug dili sa backend sama sa canary deployment.

Ang laing ngalan alang niini nga mga deployment mao ang A/B testing. Imbis nga ablihan ang pag-access sa usa ka bag-ong bahin sa tanan nga tiggamit, gitanyag lamang kini sa limitado nga bahin nila. Kasagaran, kini nga mga tiggamit wala mahibalo nga sila mga pioneer tester (busa ang termino nga "silent deployment").

Uban sa function switch (mga toggle sa feature) ug uban pang mga galamiton, mahimo nimong bantayan kung giunsa ang mga tiggamit makig-uban sa usa ka bag-ong bahin, kung sila naadik niini o makit-an ang bag-ong interface sa gumagamit nga makalibog, ug uban pang mga tipo sa sukatan.

Flagger ug A/B Deployment

Dugang sa gibug-aton nga pag-ruta, ang Flagger mahimo usab nga ruta sa trapiko sa canary server base sa mga parameter sa HTTP. Ang pagsulay sa A/B mahimong mogamit sa mga header sa HTTP o cookies aron i-redirect ang usa ka piho nga bahin sa mga tiggamit. Kini labi ka epektibo sa kaso sa mga aplikasyon sa frontend nga nanginahanglan nga ang sesyon igapos sa server. (kauban sa sesyon). Dugang nga impormasyon makita sa Flagger dokumentasyon.

Ang tagsulat mapasalamaton Stefan Prodan, inhenyero sa Weaveworks (ug tiglalang sa Flagger), alang sa tanan niining talagsaon nga mga laraw sa pagdeploy.

PS gikan sa tighubad

Basaha usab sa among blog:

Source: www.habr.com

Mga estratehiya sa pagdeploy sa Kubernetes: rolling, recreate, blue/green, canary, dark (A/B testing)