Canary-ի տեղակայումը շատ արդյունավետ միջոց է օգտատերերի ենթաբազմության վրա նոր կոդը փորձարկելու համար: Այն զգալիորեն նվազեցնում է երթևեկության ծանրաբեռնվածությունը, որը կարող է խնդրահարույց լինել տեղակայման գործընթացում, քանի որ այն տեղի է ունենում միայն որոշակի ենթախմբում: Այս նշումը նվիրված է, թե ինչպես կազմակերպել նման տեղակայում Kubernetes-ի և տեղակայման ավտոմատացման միջոցով: Մենք ենթադրում ենք, որ դուք ինչ-որ բան գիտեք Helm-ի և Kubernetes-ի ռեսուրսների մասին.
Պարզ դեղձանիկների տեղակայումը Kubernetes-ում ներառում է երկու հիմնական ռեսուրս՝ ինքը ծառայությունը և տեղակայման գործիքը: Canary-ի տեղակայումն աշխատում է մեկ ծառայության միջոցով, որը փոխազդում է երկու տարբեր ռեսուրսների հետ, որոնք սպասարկում են թարմացման երթևեկությունը: Այս ռեսուրսներից մեկը կաշխատի «դեղձանիկ» տարբերակով, իսկ երկրորդը՝ կայուն տարբերակով։ Այս իրավիճակում մենք կարող ենք կարգավորել դեղձանիկի տարբերակների քանակը, որպեսզի կրճատենք սպասարկման համար պահանջվող երթևեկության քանակը: Եթե, օրինակ, նախընտրում եք օգտագործել Yaml-ը, ապա Kubernetes-ում այն այսպիսի տեսք կունենա.
kind: Deployment
metadata:
name: app-canary
labels:
app: app
spec:
replicas: 1
...
image: myapp:canary
---
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 5
...
image: myapp:stable
---
kind: Service
selector:
app: app # Selector will route traffic to both deployments.
Նույնիսկ ավելի հեշտ է պատկերացնել այս տարբերակը՝ օգտագործելով kubectl և in
Կանարների տեղակայման ավտոմատացում
Առաջին հերթին մեզ անհրաժեշտ է Helm աղյուսակի քարտեզ, որն արդեն ներառում է այն ռեսուրսները, որոնք մենք քննարկեցինք վերևում: Այն պետք է նման լինի հետևյալին.
~/charts/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
Helm հայեցակարգի հիմքը բազմատեսակ թողարկումների կառավարումն է: Կայուն տարբերակը նախագծի կոդի մեր հիմնական կայուն ճյուղն է: Բայց Հելմի հետ մենք կարող ենք տեղադրել դեղձանիկի թողարկում մեր փորձարարական կոդով: Հիմնական բանը կայուն տարբերակի և դեղձանիկի թողարկման միջև երթևեկության փոխանակումն է: Այս ամենը մենք կկառավարենք հատուկ ընտրիչի միջոցով.
selector:
app.kubernetes.io/name: myapp
Մեր «դեղձանիկ» և կայուն տեղակայման ռեսուրսները կնշեն այս պիտակը մոդուլների վրա: Եթե ամեն ինչ ճիշտ կազմաձևված է, ապա մեր Helm աղյուսակի կանարյան տարբերակի տեղակայման ժամանակ մենք կտեսնենք, որ երթևեկությունը կուղղվի դեպի նոր տեղակայված մոդուլներ: Այս հրամանի կայուն տարբերակը կունենա հետևյալ տեսքը.
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v1 # Goes into app.kubernetes.io/version
--set image.tag=stable
--set replicaCount=5
Հիմա եկեք ստուգենք մեր դեղձանիկի թողարկումը: Կանարյան տարբերակը գործարկելու համար մենք պետք է հիշենք երկու բան. Թողարկման անունը պետք է տարբեր լինի, որպեսզի մենք չտարածենք ընթացիկ կայուն տարբերակի թարմացում: Տարբերակը և պիտակը նույնպես պետք է տարբեր լինեն, որպեսզի մենք կարողանանք տեղակայել այլ կոդ և բացահայտել տարբերությունները ըստ ռեսուրսների պիտակների:
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v2 # Goes into app.kubernetes.io/version
--set image.tag=canary
--set replicaCount=1
Այսքանը: Եթե ծառայությունը ping-ով անցկացնեք, կարող եք տեսնել, որ դեղձանիկի թարմացումը երթուղիներ է իրականացնում միայն ժամանակի մի մասում:
Եթե դուք փնտրում եք տեղակայման ավտոմատացման գործիքներ, որոնք ներառում են նկարագրված տրամաբանությունը, ապա ուշադրություն դարձրեք
Source: www.habr.com