🥇Canary տեղակայում Kubernetes #1-ում. Gitlab CI

Մենք կօգտագործենք Gitlab CI-ն և մեխանիկական GitOps-ը, որպեսզի իրականացնենք և օգտագործենք Canary տեղակայումը Kubernetes-ում:

Հոդվածներ այս շարքից.

(Այս հոդվածը)
Canary տեղակայում ArgoCI-ի միջոցով
Canary տեղակայում, օգտագործելով Istio
Canary տեղակայում Jenkins-X Istio Flagger-ի միջոցով

Մենք կկատարենք Canary-ի տեղակայումը ձեռքով GitOps-ի միջոցով և ստեղծելով/փոփոխելով հիմնական Kubernetes ռեսուրսները: Այս հոդվածը նախատեսված է հիմնականում ներածության համար ինչպես է աշխատում տեղակայումը Kubernetes Canary-ում, քանի որ կան ավտոմատացման ավելի արդյունավետ մեթոդներ, որոնք մենք կքննարկենք հաջորդ հոդվածներում:

https://www.norberteder.com/canary-deployment/

Canary տեղակայում

Կանարյան ռազմավարությամբ թարմացումներն առաջին հերթին կիրառվում են օգտատերերի միայն ենթաբազմության համար: Մոնիտորինգի, գրանցամատյանների տվյալների, ձեռքով փորձարկման կամ հետադարձ կապի այլ ուղիների միջոցով թողարկումը փորձարկվում է նախքան այն թողարկվել բոլոր օգտատերերին:

Kubernetes տեղակայում (շարժվող թարմացում)

Kubernetes Deployment-ի լռելյայն ռազմավարությունը շարժական թարմացումն է, որտեղ որոշակի թվով պատյաններ գործարկվում են պատկերների նոր տարբերակներով: Եթե դրանք ստեղծվել են առանց խնդիրների, ապա պատկերների հին տարբերակներով պատյանները դադարեցվում են, և զուգահեռաբար ստեղծվում են նոր պատյաններ:

GitOps

Այս օրինակում մենք օգտագործում ենք GitOps, քանի որ մենք՝

օգտագործելով Git-ը որպես ճշմարտության մեկ աղբյուր
մենք օգտագործում ենք Git Operations կառուցման և տեղակայման համար (բացի git tag/միաձուլման այլ հրամաններ անհրաժեշտ չեն)

Օրինակ

Եկեք ընդունենք լավ պրակտիկա՝ ունենալ մեկ պահեստ՝ կիրառական կոդի համար և մեկը՝ ենթակառուցվածքի համար:

Դիմումների պահոց

Սա շատ պարզ Python+Flask API է, որը պատասխան է տալիս որպես JSON: Մենք փաթեթը կկառուցենք GitlabCI-ի միջոցով և արդյունքը կհանձնենք Gitlab ռեգիստր: Ռեեստրում մենք ունենք երկու տարբեր թողարկման տարբերակներ.

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Նրանց միջև միակ տարբերությունը վերադարձված JSON ֆայլի փոփոխությունն է: Մենք օգտագործում ենք այս հավելվածը՝ հնարավորինս հեշտ պատկերացնելու համար, թե որ տարբերակի հետ ենք շփվում:

Ենթակառուցվածքի շտեմարան

Այս շաղգամում մենք GitlabCI-ի միջոցով կտեղակայենք Kubernetes, .gitlab-ci.yml կարծես սա:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s

   only:
     - master

Ինքներդ գործարկելու համար ձեզ անհրաժեշտ կլինի կլաստեր, կարող եք օգտագործել Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b

gcloud compute firewall-rules create incoming-80 --allow tcp:80

Պետք է պատառաքաղել https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure և ստեղծել փոփոխական KUBECONFIG GitlabCI-ում, որը կպարունակի մուտքի կոնֆիգուրացիա kubectl ձեր կլաստերին:

Դուք կարող եք կարդալ այն մասին, թե ինչպես ստանալ հավատարմագրեր կլաստերի համար (Gcloud) այստեղ.

Ենթակառուցվածք Յամլ

Ենթակառուցվածքի պահեստում մենք ունենք ծառայություն.

apiVersion: v1
kind: Service
metadata:
 labels:
   id: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

Եվ տեղակայում deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Եվ ևս մեկ տեղակայում deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Նկատի ունեցեք, որ app-deploy-ը դեռևս չունի որևէ կրկնօրինակ:

Նախնական տեղակայման կատարում

Նախնական տեղակայումը սկսելու համար դուք կարող եք ձեռքով սկսել GitlabCI խողովակաշարը գլխավոր ճյուղում: Դրանից հետո kubectl պետք է թողարկվի հետևյալը.

Մենք տեսնում ենք app տեղակայում 10 կրկնօրինակներով և հավելված-canary 0-ով: Կա նաև LoadBalancer, որտեղից մենք կարող ենք մուտք գործել curl Արտաքին IP-ի միջոցով.

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Մենք տեսնում ենք, որ մեր թեստային հավելվածը վերադարձնում է միայն «v1»:

Կատարում է Canary տեղակայումը

Քայլ 1. թողարկեք նոր տարբերակ որոշ օգտվողների համար

Մենք deploy-canary.yaml ֆայլում կրկնօրինակների թիվը սահմանեցինք 1-ի և նոր տարբերակի պատկերում՝

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Ֆայլում deploy.yaml մենք փոխեցինք կրկնօրինակների թիվը 9-ի:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Մենք այս փոփոխությունները մղում ենք պահոց, որտեղից կսկսվի տեղակայումը (GitlabCI-ի միջոցով) և արդյունքում տեսնում ենք.

Մեր ծառայությունը ցույց կտա երկու տեղակայումները, քանի որ երկուսն էլ ունեն հավելվածի ընտրիչ: Կուբերնետեսի լռելյայն պատահականության պատճառով մենք պետք է տարբեր պատասխաններ տեսնենք հարցումների 10%-ի համար.

Մեր հավելվածի ներկայիս վիճակը (GitOps, վերցված Git-ից որպես ճշմարտության մեկ աղբյուր) երկու տեղակայման առկայությունն է ակտիվ կրկնօրինակներով՝ մեկը յուրաքանչյուր տարբերակի համար:

Օգտատերերի ~10%-ը ծանոթանում է նոր տարբերակին և ակամա փորձարկում այն։ Հիմա ժամանակն է ստուգել տեղեկամատյաններում և մոնիտորինգի տվյալների սխալները՝ խնդիրներ գտնելու համար:

Քայլ 2. թողարկեք նոր տարբերակը բոլոր օգտագործողների համար

Մենք որոշեցինք, որ ամեն ինչ լավ է անցել, և այժմ մենք պետք է նոր տարբերակը ներկայացնենք բոլոր օգտատերերին: Դա անելու համար մենք պարզապես թարմացնում ենք deploy.yaml պատկերի նոր տարբերակի տեղադրում և կրկնօրինակների թիվը հավասար է 10-ի: Մեջ deploy-canary.yaml մենք կրկնօրինակների թիվը դարձրինք 0-ի: Տեղակայումից հետո արդյունքը կլինի հետևյալը.

Ամփոփելով

Ինձ համար այս ձևով տեղակայումը ձեռքով գործարկելն օգնում է հասկանալ, թե որքան հեշտությամբ այն կարող է կազմաձևվել k8s-ի միջոցով: Քանի որ Kubernetes-ը թույլ է տալիս թարմացնել ամեն ինչ API-ի միջոցով, այս քայլերը կարող են ավտոմատացվել սկրիպտների միջոցով:

Մեկ այլ բան, որը պետք է իրականացվի, փորձարկողի մուտքի կետն է (LoadBalancer կամ Ingress-ի միջոցով), որի միջոցով կարելի է մուտք գործել միայն նոր տարբերակը: Այն կարող է օգտագործվել ձեռքով զննարկման համար:

Հետագա հոդվածներում մենք կստուգենք այլ ավտոմատացված լուծումներ, որոնք իրականացնում են մեր արածի մեծ մասը:

Կարդացեք նաև մեր բլոգի այլ հոդվածներ.

Source: www.habr.com

Canary-ի տեղակայումը Kubernetes #1-ում. Gitlab CI