🥇Kubernetes-ում տեղադրելու ռազմավարությունները՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Այն։ Այս խմբագրական նյութը Weaveworks-ից ներկայացնում է կիրառությունների թողարկման ամենատարածված ռազմավարությունները եւ բացատրում է դրանց որեւէ մի քանիսը իրականացնելու հնարավորությունները Kubernetes-օպերատորի Flagger-ի միջոցով։ Նյութը գրել է պարզ լեզվով եւ պարունակում է տեսական սխեմաներ, որոնք թույլ են տալիս նույնիսկ սկսնակ ինժեներներին հասկանալ թեման։

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)
Սխեման վերցված է այլ ակնարկից թողարկման ռազմավարությունների, որը կազմվել է Container Solutions-ում

Ավելի արագ տեղադրումը ներկայումս խոշորագույն խնդիրներից մեկն է cloud native դիմումների մշակման ոլորտում։ Միքրոհ servici հանդիսատեսին ծրագրողները արդեն աշխատում են ամբողջությամբ մոդուլացված ծրագրերով եւ նախագծում են դրանք, թույլատրելով տարբեր թիմերի միաժամանակ գրել կոդ եւ կատարել փոփոխություններ ծրագրում։

Ավելի կարճ եւ հաճախակի թողարկումները ունեն հետեւյալ առավելությունները՝

Մասնակցության ժամանակը կրճատվում է շուկա դուրս գալու համար։
Նոր գործառույթները ավելի արագ հասնում են օգտագործողներին։
Օգտագործողների արձագանքները ավելի արագ հասնում են ծրագրավորողների թիմին։ Սա նշանակում է, որ թիմը կարող է ավելի արագ լրացնել գործառույթները եւ ուղղել խնդիրները։
Բարձրանում է ծրագրավորողների բարոյականությունը։ Շատ գործառույթների մշակումը ավելի հետաքրքիր է աշխատել։

Բայց թողարկումների频率的增加也提高了对应用程序或用户体验的负面影响的机会。因此，操作团队和DevOps团队必须以一种降低产品和用户的风险的方式来建立过程和管理部署策略。（了解有关CI/CD管道自动化的更多信息，请访问我们的页面。） այստեղ.)

Այս հրապարակմամբ մենք կքննարկենք տարբեր ակտիվացման ռազմավարությունները Kubernetes-ում, այդ թվում՝ rolling-թողարկումները եւ ավելի առաջադեմ մեթոդներ, ինչպիսիք են Canary թողարկումները եւ դրանց տարբերակները։

Տեղադրման ռազմավարություններ

Post-միանվոր-ծրագրեր պայքարում են շահագործման կարողությունների վրա, որոնք կարող են օգտակար լինել մանիպուլյացիաներում։ Դուք կարող եք որոշում կայացնել փոխել ինչ-որ միջավայր՝ հետագա թեստավորման համար, կամ օգտագործողների / հաճախորդների ենթաբաժիններում, կամ միաժամանակ որոշման կայացնելությունը ցույց տալ՝ արևելյանում որոշ ֆունկցիաներ հասանելի դարձնելուց առաջ։ հանրային.

Բամբիշ (օլտրայի, «թերթի» թողարկում)

Սա Kubernetes-ի ստանդարտ ռազմավարությունն է։ Այն աստիճանաբար, մեկը մեկին փոխարինում է pod-երը, որոնք ունեն հին տարբերակները նոր տարբերակների pod-ով` առանց կլաստերի կանգառի։

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Kubernetes սպասում է նոր pod-երի աշխատանքի նախապատրաստությանը (վերապատրաստելով նրանց) readiness-test-երով) նախքան հին pod-երի փակելը սկսելը։ Եթե խնդիր է առաջանում, նման աստիճանական թարմացումը կարելի է դադարեցնել, առանց ամբողջ կլաստերը կանգնեցնելու։ YAML-ի ֆայլում, որը նկարագրում է deployment-ի տեսակը, նոր պատկերումը փոխարինում է հին պատկերումը՝

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

Ներդրված թարմացման պարամետրերը կարելի է հստակեցնել մանիֆեստի ֆայլում:

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

Recreate (կրկնակի ստեղծում)

Այս ամենադյուրին desplejar प्रकारում հին pod-ները մեկանգամից ոչնչացվում են և փոխվում նորերով:

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Համապատասխան մանիֆեստը looks approximately like this:

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

Blue/Green (կապույտ/կանաչ desplejar)

Կապույտ-կանաչ desplejar ռազմավարությունը (sometimes referred to as red/black) ունի միաժամանակ պրոցեսավորման հին (կանաչ) և նոր (կապույտ) տարբերակները: Արժեքները, մշակման լարվածությունները կարող են ապահովվել որևէ տարբերակի միջոցով:

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

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

Երբ կապույտ (նոր) տարբերակը փորձարկվել է և նրա թողարկումը հաստատվել է, ծառայությունը անցնում է դրան, իսկ կանաչ (հին) խզվում է:

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

Canary (կանարէյ ակտեր)

Կանարեայի desplejarները նման են կապույտ-կանաչ ընթացքին, բայց ավելի լավ են կառավարվում: խաղարկային համարկում, որը կարող է մշակվել մի քանի տարբեր ձևերով՝ ներառյալ "թաքնված" թողարկումները և A/B փորձարկումները:

Այս ռազմավարությունը կիրառվում է, երբ անհրաժեշտ է փորձարկել որևէ նոր ֆունկցիոնալություն, սովորաբար հավելվածի հետևի կողմում: Համակարգումը կայանում է այն բանում, որ ստեղծել երկու գրեթե ինքնակամ սերվեր, որոնք մեկնում են գրեթե բոլոր օգտագործողներին, իսկ մյուսը՝ նոր գործառույթներով, միայն փոքր խմբի համար, ապա նրանց աշխատանքի արդյունքները համեմատվում են: Եթե ամեն ինչ անցնում է առանց խնդիրների, նոր տարբերակը աստիճանաբար քշվում է ամբողջ ենթակառուցվածքում:

Թեև այս ռազմավարությունը կարող է իրականացվել բացառապես Kubernetes-ի միջոցով, անգնահատելի է և ավելի հեշտ օգտագործել ծառայության ցանց, כגון Istio:

Օրինակ, կարող եք ունենալ երկու տարբեր մանիֆեստ Git-ում՝ սովորական 0.1.0 թագով և "կանարէյ" 0.2.0 թագով: Կողմում, փոխելով քաշը Istio-ի վիրտուալ անցքում, կարող եք կառավարել երթևեկության բաշխումը այս երկու desplejarների միջև:

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Կանարեյան desplejarների իրականացման քայլ առ քայլ ուղեցույցը կարող եք գտնել հոդվածում GitOps Workflows with Istio. (Համար. թարգմանություն.: Մենք նաև թարգմանել ենք նյութը կանարեների շուրջ Istio-ում այստեղ.)

Կանարեային desplejarներ Weaveworks Flagger-ի միջոցով

Weaveworks Flagger հեշտացնում և արդյունավետորեն կառավարման կանարեայ խմբակները:

Flagger ավտոմատացնում է նրանց հետ աշխատելը: Այն օգտագործում է Istio կամ AWS App Mesh երթևեքությունը և փոխի երթևեքությունը տնօրինելու համար, ինչպես նաև Prometheus մետրիկաները արդյունքները վերլուծելու համար: Բացի այդ, ուղևորային ձևաչափերի վերլուծությունը կարելի է ավարտել վեբհուքներով ընդունող (acceptance) թեստեր անցկացնելու, ծանրաբեռնման և ցանկացած այլ տեսակի проверки:

Kubernetes-ի տեղադրման հիման վրա և անհրաժեշտության դեպքում pod-ների հորիզոնային մասշտաբավորման (HPA), Flagger ստեղծում է հավաքածուներ Kubernetes-ի օբյեկտներից (տեղադրումներ, ClusterIP ծառայություններ և Istio կամ App Mesh վիրտուալ ծառայություններ) ուղևորային ձևաչափերի վերլուծությունն իրականացնելու համար:

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Հաղորդման վերահսկման շրջանակը իրականացնելու դեպքում (control loop), Flagger աստիճանաբար փոխում է երթևեքությունը կանաչ սերվեր, միաժամանակ չափելով հիմնական ցուցանիշները, ինչպիսին են HTTP հարցումների հաջողության չափանիշը, հարցման միջին տևողությունը և pod-ների առողջությունը: KPI-ների (կողմնակի ցուցանիշների) վերլուծության հիման վրա կանելային հատվածը աճում է կամ նվազեցնում, և վերլուծության արդյունքները հրատարակվում են Slack-ում: Այս գործընթացի նկարագրությունը և ցուցադրությունը կարելի է գտնել նյութում Progressive Delivery for App Mesh.

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Սև (թաքնված) կամ A/B տեղադրումներ

Թաքնված տեղադրում՝ մեկ այլ տարբերակ քանակային ռազմավարության (դրա հետ Flagger նույնպես կարող է աշխատել): Թաքնված և կանարմելային տեղադրման միջեւ տարբերությունը այն է, որ թաքնված տեղադրումները վերաբերեք առջևի մասին, այլ ոչ թե հետին մասին, ինչպես կանարմելայինները:

Այս տեղադրումների մեկ ուրիշ անունը՝ A/B թեստավորում: Փոփոխությունը կայանում է նրանում, որ նոր ֆունկցիայի մատչելիությունը բաշխելու փոխարեն, այն առաջարկվում է միայն նրանց սահմանափակ մասին: Հանդեսված օգտվողները սովորաբար չգիտեն, որ նրանք հատուկ փորձարկողներ են (այստեղից էլ՝ «թաքնված տեղադրում» հասկացությունը):

Ֆունկցիոնալության անջատիչների միջոցով (feature toggles) և այլ գործիքների միջոցով կարելի է հետևել, թե ինչպես են օգտվողները փոխազդում նոր ֆունկցիայի հետ, արդյոք դա նրանց գրավում է, թե նրանք գտնում են նոր օգտվողական ինտերֆեյսը շփոթեցնող, և այլ մեթրիկաների:

Kubernetes-ում գործելու ռազմավարություններ՝ rolling, recreate, blue/green, canary, dark (A/B թեստավորում)

Flagger և A/B տեղադրումները

Երթևեքի քանակի փոխանցման բացարձակման բացի, Flagger կարող է նաև ուղղել երթևեքությունը կանարանային սերվերին HTTP պարամետրերով: A/B թեստավորման ժամանակ կարելի է օգտագործել HTTP տիտղոսներ կամ cookie-ներ՝ որոշակի օգտվողների հատվածն ուղղելու համար: Սա հատկապես արդյունավետ է առջևի ծրագրերի դեպքում, որոնք պահանջում են սեսիայի սերտաճում սերվերին (session affinity). Լրացուցիչ տեղեկություններ կարելի է գտնել Flagger-ի փաստաթղթաբանությունում:

Author expresses gratitude Stefan Prodan, Weaveworks-ի ինժեներ (և Flagger-ի ստեղծող), բոլոր այդ հիանալի տեղադրումների սխեմաների համար:

P.S. թարգմանչից

Նաեւ կարդացեք մեր բլոգում:

Ընտանիք: habr.com