კანარის განლაგება Kubernetes #2: Argo Rollouts

ჩვენ გამოვიყენებთ k8s-ის მშობლიურ Argo Rollouts-ის განლაგების კონტროლერს და GitlabCI-ს Canary-ის განლაგების გასაშვებად Kubernetes-ში

https://unsplash.com/photos/V41PulGL1z0

სტატიები ამ სერიის

• კანარის განლაგება Kubernetes #1-ში: Gitlab CI
• (Ეს არტიკლი)
• კანარის განლაგება ისტიოს გამოყენებით
• კანარის განლაგება Jenkins-X Istio Flagger-ის გამოყენებით

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

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

Argo Rollouts

Argo Rollouts არის Kubernetes-ის მშობლიური განლაგების კონტროლერი. ის უზრუნველყოფს CRD (Custom Resource Definition) Kubernetes-ისთვის. მისი წყალობით, ჩვენ შეგვიძლია გამოვიყენოთ ახალი ერთეული: Rollout, რომელიც მართავს ლურჯ-მწვანე და კანარის განლაგებას სხვადასხვა კონფიგურაციის ვარიანტებით.

Argo Rollouts კონტროლერი, რომელიც გამოიყენება მორგებული რესურსით Rollout, იძლევა დამატებით განლაგების სტრატეგიებს, როგორიცაა ლურჯი-მწვანე და კანარის კუბერნეტისთვის. რესურსი Rollout უზრუნველყოფს ფუნქციის ექვივალენტს Deploymentმხოლოდ დამატებითი განლაგების სტრატეგიებით.
რესურსი Deployments აქვს განლაგების ორი სტრატეგია: RollingUpdate и Recreate. მიუხედავად იმისა, რომ ეს სტრატეგიები შესაფერისია უმეტეს შემთხვევაში, სერვერებზე ძალიან დიდი მასშტაბის განლაგებისთვის, გამოიყენება დამატებითი სტრატეგიები, როგორიცაა ლურჯი-მწვანე ან კანარის, რომლებიც მიუწვდომელია Deployment კონტროლერში. Kubernetes-ში ამ სტრატეგიების გამოსაყენებლად, მომხმარებლებს უნდა დაეწერათ სკრიპტები თავიანთი Deployments-ის თავზე. Argo Rollouts Controller ავლენს ამ სტრატეგიებს, როგორც მარტივ, დეკლარაციულ, კონფიგურირებად პარამეტრებს.
https://argoproj.github.io/argo-rollouts

ასევე არის Argo CI, რომელიც უზრუნველყოფს მოსახერხებელ ვებ ინტერფეისს Rollouts-თან გამოსაყენებლად, ამას შემდეგ სტატიაში განვიხილავთ.

Argo Rollouts-ის ინსტალაცია

სერვერის მხარე

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

ჩვენს ინფრასტრუქტურულ ტურნიკში (იხილეთ ქვემოთ) ჩვენ უკვე დავამატეთ install.yaml როგორც i/k8s/argo-rollouts/install.yaml. ამ გზით GitlabCI დააინსტალირებს მას კლასტერში.

კლიენტის მხარე (kubectl მოდული)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

განაცხადის მაგალითი

კარგი პრაქტიკაა აპლიკაციის კოდისა და ინფრასტრუქტურის ცალკე საცავი.

საცავი განაცხადისთვის

Kim Wuestkamp/k8s-deployment-example-app

ეს არის ძალიან მარტივი 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-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy 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: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

და rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout მუშაობს ისევე, როგორც Deployment. თუ არ დავაყენებთ განახლების სტრატეგიას (როგორც აქ კანარის) ის იქცევა როგორც ნაგულისხმევი მოძრავი განახლების განლაგება.

ჩვენ განვსაზღვრავთ ორ საფეხურს იამლში კანარის განლაგებისთვის:

1. ტრაფიკის 10% კანარამდე (დაელოდეთ ხელით OK)
2. 50% ტრაფიკი კანარამდე (მოითმინეთ 2 წუთი და შემდეგ გააგრძელეთ 100%)

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

პირველადი განლაგების შემდეგ, ჩვენი რესურსები ასე გამოიყურება:

ჩვენ ვიღებთ პასუხს მხოლოდ აპლიკაციის პირველი ვერსიიდან:

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

ნაბიჯი 1: 10% ტრაფიკი

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

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

ჩვენ ვაყენებთ ცვლილებებს, ასე რომ, Gitlab CI ავრცელებს და ჩვენ ვხედავთ ცვლილებებს:

ახლა, თუ ჩვენ მივიღებთ სერვისს:

დიდი! ჩვენ ჩვენი კანარის განლაგების შუაში ვართ. ჩვენ ვხედავთ პროგრესს გაშვებით:

kubectl argo rollouts get rollout rollout-canary

ნაბიჯი 2: 50% ტრაფიკი:

ახლა გადავიდეთ შემდეგ ეტაპზე: ტრაფიკის 50%-ის გადამისამართება. ჩვენ დავაყენეთ ეს ნაბიჯი ხელით გასაშვებად:

kubectl argo rollouts promote rollout-canary # continue to step 2

და ჩვენმა აპლიკაციამ დააბრუნა პასუხების 50% ახალი ვერსიებიდან:

და გამოქვეყნების მიმოხილვა:

პრესა.

ნაბიჯი 3: 100% ტრაფიკი:

ჩვენ დავაყენეთ ისე, რომ 2 წუთის შემდეგ 50%-იანი ნაბიჯი ავტომატურად დასრულდეს და 100%-იანი ნაბიჯი დაიწყოს:

და განაცხადის გამომავალი:

და გამოქვეყნების მიმოხილვა:

კანარის განლაგება დასრულებულია.

მეტი მაგალითები Argo Rollouts-ით

აქ უფრო მეტი მაგალითია, მაგალითად, როგორ დავაყენოთ გარემოს გადახედვა და შედარება კანარის საფუძველზე:

https://github.com/argoproj/argo-rollouts/tree/master/examples

ვიდეო Argo Rollouts-ისა და Argo CI-ის შესახებ

მე ნამდვილად გირჩევთ ამ ვიდეოს, ის აჩვენებს, თუ როგორ მუშაობენ Argo Rollouts და Argo CI ერთად:

სულ

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

თუმცა, როგორც ჩანს, Argo CI-ისა და Flux CI-ის დიდი შერწყმაა, ასე რომ, შეიძლება დაველოდო სანამ ახალი გამოშვება გამოვა: არგო ფლუქსი.

გქონიათ რაიმე გამოცდილება Argo Rollouts-თან ან Argo CI-სთან?

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

• გაზაფხულის აპლიკაციების ცისფერი-მწვანე განლაგება Nginx ვებ სერვერით
• Kubernetes: რატომ არის ასე მნიშვნელოვანი სისტემის რესურსების მართვის კონფიგურაცია?
• Hashicorp-ის კონსულის Kubernetes ავტორიზაციის შესავალი
• Tekton Pipeline - Kubernetes-ის მშობლიური მილსადენები
• დინამიური მოდულების აგება Nginx-ისთვის
• Telegram-ის ბოტი Redmine-ისთვის. როგორ გავამარტივოთ ცხოვრება საკუთარი თავისთვის და სხვებისთვის

წყარო: www.habr.com