კანარის განლაგება Kubernetes #1-ში: Gitlab CI

ჩვენ გამოვიყენებთ Gitlab CI-ს და სახელმძღვანელოს GitOps-ს, რათა განვახორციელოთ და გამოვიყენოთ Canary-ის განლაგება Kubernetes-ში

სტატიები ამ სერიიდან:

• (Ეს არტიკლი)
• კანარის განლაგება ArgoCI-ის გამოყენებით
• კანარის განლაგება ისტიოს გამოყენებით
• კანარის განლაგება Jenkins-X Istio Flagger-ის გამოყენებით

ჩვენ შევასრულებთ Canary განლაგებას ხელით GitOps-ის მეშვეობით და შევქმნით/შეცვლით Kubernetes-ის ძირითად რესურსებს. ეს სტატია ძირითადად გაცნობისთვისაა განკუთვნილი თუ როგორ მუშაობს განლაგება Kubernetes Canary-ში, რადგან არსებობს ავტომატიზაციის უფრო ეფექტური მეთოდები, რომლებსაც განვიხილავთ შემდეგ სტატიებში.

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

კანარის განლაგება

კანარის სტრატეგიით, განახლებები პირველად გამოიყენება მხოლოდ მომხმარებელთა ქვეჯგუფზე. მონიტორინგის, ჟურნალის მონაცემების, მექანიკური ტესტირების ან სხვა გამოხმაურების არხების მეშვეობით, გამოშვება ტესტირებამდე ხდება ყველა მომხმარებლისთვის გამოქვეყნებამდე.

Kubernetes Deployment (მოძრავი განახლება)

Kubernetes Deployment-ის ნაგულისხმევი სტრატეგია არის მოძრავი-განახლება, სადაც გამოსახულებების ახალი ვერსიებით იხსნება პოდების გარკვეული რაოდენობა. თუ ისინი შეიქმნა უპრობლემოდ, სურათების ძველი ვერსიების მქონე პოდნები წყდება და პარალელურად იქმნება ახალი რგოლები.

GitOps

ჩვენ ვიყენებთ GitOps ამ მაგალითში, რადგან ჩვენ:

• Git-ის გამოყენება, როგორც ჭეშმარიტების ერთი წყარო
• ჩვენ ვიყენებთ Git ოპერაციებს აგებისა და განლაგებისთვის (არ არის საჭირო სხვა ბრძანებები, გარდა 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

გაითვალისწინეთ, რომ აპლიკაციის განლაგებას ჯერ არ აქვს რაიმე რეპლიკა განსაზღვრული.

პირველადი განლაგების შესრულება

საწყისი განლაგების დასაწყებად, შეგიძლიათ GitlabCI მილსადენის ხელით გაშვება მთავარ ფილიალზე. Ამის შემდეგ kubectl უნდა გამოვიდეს შემდეგი:

Ჩვენ ვხედავთ app განლაგება 10 რეპლიკით და app-canary 0-ით. ასევე არის LoadBalancer, საიდანაც შეგვიძლია წვდომა. curl გარე IP-ის საშუალებით:

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

ჩვენ ვხედავთ, რომ ჩვენი სატესტო აპლიკაცია აბრუნებს მხოლოდ "v1".

კანარის განლაგების შესრულება

ნაბიჯი 1: გამოუშვით ახალი ვერსია ზოგიერთი მომხმარებლისთვის

ჩვენ დავაყენეთ ასლების რაოდენობა 1-ზე deploy-canary.yaml ფაილში და ახალი ვერსიის სურათში:

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-ის მეშვეობით) და ვნახავთ შედეგს:

ჩვენი სერვისი მიუთითებს ორივე განლაგებაზე, რადგან ორივეს აქვს აპლიკაციის ამომრჩეველი. Kubernetes-ის ნაგულისხმევი რანდომიზაციის გამო, ჩვენ უნდა ვნახოთ განსხვავებული პასუხები მოთხოვნის ~10%-ზე:

ჩვენი აპლიკაციის ამჟამინდელი მდგომარეობა (GitOps, აღებული Git-დან, როგორც სიმართლის ერთი წყარო) არის ორი განლაგების არსებობა აქტიური რეპლიკებით, ერთი თითოეული ვერსიისთვის.

მომხმარებელთა ~10% ეცნობა ახალ ვერსიას და უნებლიედ ამოწმებს მას. ახლა დროა შეამოწმოთ შეცდომები ჟურნალებში და მონიტორინგის მონაცემებში, რათა იპოვოთ პრობლემები.

ნაბიჯი 2: გამოუშვით ახალი ვერსია ყველა მომხმარებლისთვის

ჩვენ გადავწყვიტეთ, რომ ყველაფერმა კარგად ჩაიარა და ახლა ახალი ვერსია ყველა მომხმარებლისთვის უნდა გავავრცელოთ. ამისათვის ჩვენ უბრალოდ ვაახლებთ deploy.yaml სურათის ახალი ვერსიის დაყენება და რეპლიკების რაოდენობა უდრის 10. In deploy-canary.yaml ჩვენ დავაბრუნეთ ასლების რაოდენობა 0-ზე. განლაგების შემდეგ შედეგი იქნება შემდეგი:

შეჯამება

ჩემთვის, ამ გზით განლაგების ხელით გაშვება მეხმარება იმის გაგებაში, თუ რამდენად მარტივად შეიძლება მისი კონფიგურაცია k8s-ის გამოყენებით. ვინაიდან Kubernetes გაძლევთ საშუალებას განაახლოთ ყველაფერი API-ის საშუალებით, ამ ნაბიჯების ავტომატიზაცია შესაძლებელია სკრიპტების საშუალებით.

კიდევ ერთი რამ, რაც უნდა განხორციელდეს, არის ტესტერის შესვლის წერტილი (LoadBalancer ან Via Ingress), რომლის მეშვეობითაც შესაძლებელია მხოლოდ ახალი ვერსიის წვდომა. მისი გამოყენება შესაძლებელია ხელით დათვალიერებისთვის.

მომავალ სტატიებში ჩვენ განვიხილავთ სხვა ავტომატიზირებულ გადაწყვეტილებებს, რომლებიც ახორციელებენ ჩვენი გაკეთებულის უმეტესობას.

ასევე წაიკითხეთ სხვა სტატიები ჩვენს ბლოგზე:

• რას მოჰყვა მიგრაცია ClickHouse-დან ავტორიზაციის გარეშე ClickHouse-ში ავტორიზაციის მქონე?
• დინამიური მოდულების აგება Nginx-ისთვის
• nxs-build-tools-ის განახლება - ასისტენტი deb და rpm პაკეტების მშენებლობაში
• Hashicorp-ის კონსულის Kubernetes ავტორიზაციის შესავალი
• რა უნდა შეგვექმნას Csync2 უტილიტის გამოყენებისას
• Telegram-ის ბოტი Redmine-ისთვის. როგორ გავამარტივოთ ცხოვრება საკუთარი თავისთვის და სხვებისთვის

წყარო: www.habr.com