განლაგების სტრატეგიები Kubernetes-ში: მოძრავი, ხელახლა შექმნა, ლურჯი/მწვანე, კანარის, მუქი (A/B ტესტირება)

შენიშვნა თარგმანი: Weaveworks-ის ეს მიმოხილვა წარმოგიდგენთ აპლიკაციების გავრცელების ყველაზე პოპულარულ სტრატეგიებს და აჩვენებს, თუ როგორ შეიძლება განხორციელდეს ყველაზე მოწინავეები Kubernetes Flagger ოპერატორის გამოყენებით. ის მარტივი ენით არის დაწერილი და შეიცავს ვიზუალურ დიაგრამებს, რომლებიც დამწყებ ინჟინრებსაც კი საშუალებას აძლევს გაიგონ ეს საკითხი.

დიაგრამა აღებულია საიდან კიდევ ერთი მიმოხილვა განლაგების სტრატეგიები დამზადებულია Container Solutions-ში

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

ხანმოკლე და უფრო ხშირი განლაგება აქვს შემდეგი უპირატესობები:

• ბაზარზე გასვლის დრო შემცირებულია.
• ახალი ფუნქციები უფრო სწრაფად აღწევს მომხმარებლებს.
• მომხმარებლის გამოხმაურება უფრო სწრაფად აღწევს განვითარების გუნდს. ეს ნიშნავს, რომ გუნდს შეუძლია დაამატოს ფუნქციები და მოაგვაროს პრობლემები უფრო სწრაფად.
• დეველოპერის მორალი იზრდება: უფრო სახალისოა მუშაობა განვითარების პროცესში.

მაგრამ რაც იზრდება გამოშვებების სიხშირე, ასევე იზრდება აპლიკაციის სანდოობაზე ან მომხმარებლის გამოცდილებაზე უარყოფითი ზემოქმედების შანსები. სწორედ ამიტომ მნიშვნელოვანია ოპერაციებისა და DevOps გუნდებისთვის შექმნან პროცესები და მართონ განლაგების სტრატეგიები ისე, რომ მინიმუმამდე დაიყვანონ რისკი პროდუქტისა და მომხმარებლებისთვის. (შეგიძლიათ გაიგოთ მეტი CI/CD მილსადენის ავტომატიზაციის შესახებ აქ.)

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

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

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

მოძრავი (ეტაპობრივი, „მოძრავი“ განლაგება)

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

Kubernetes ელოდება, სანამ ახალი რგოლები მზად იქნება სამუშაოდ (შეამოწმებს მათ გამოყენებით მზადყოფნის ტესტები), სანამ ძველებს დაიწყებთ. თუ პრობლემა წარმოიქმნება, ეს მოძრავი განახლება შეიძლება შეწყდეს მთელი კლასტერის შეჩერების გარეშე. YAML ფაილში, რომელიც აღწერს განლაგების ტიპს, ახალი სურათი ცვლის ძველ სურათს:

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

rollover განახლების პარამეტრები შეიძლება მითითებული იყოს manifest ფაილში:

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

ხელახლა შექმნა

ამ უმარტივესი ტიპის განლაგებისას, ძველი ღეროები ერთდროულად იღუპება და იცვლება ახლით:

შესაბამისი მანიფესტი ასე გამოიყურება:

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

ლურჯი/მწვანე (ლურჯი-მწვანე განლაგება)

ლურჯ-მწვანე განლაგების სტრატეგია (ზოგჯერ მას წითელ/შავსაც უწოდებენ) მოიცავს აპლიკაციის ძველი (მწვანე) და ახალი (ლურჯი) ვერსიების ერთდროულ განლაგებას. ორივე ვერსიის გამოქვეყნების შემდეგ, რეგულარულ მომხმარებლებს აქვთ წვდომა მწვანეზე, ხოლო ლურჯი ხელმისაწვდომია QA გუნდისთვის ტესტების ავტომატიზაციისთვის ცალკე სერვისის ან პირდაპირი პორტის გაგზავნის საშუალებით:

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 Rollouts მსგავსია ლურჯ-მომწვანო რულონების, მაგრამ აქვს უკეთესი კონტროლი და გამოყენება პროგრესული ნაბიჯ-ნაბიჯ მიდგომა. ეს ტიპი მოიცავს რამდენიმე განსხვავებულ სტრატეგიას, მათ შორის „სტელსის“ გაშვებას და A/B ტესტირებას.

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

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

მაგალითად, შეიძლება გქონდეთ ორი განსხვავებული მანიფესტი Git-ში: ჩვეულებრივი მანიფესტი ტეგით 0.1.0 და კანარის მანიფესტი ტეგით 0.2.0. Istio ვირტუალური კარიბჭის მანიფესტში წონების შეცვლით, შეგიძლიათ აკონტროლოთ ტრაფიკის განაწილება ამ ორ განლაგებას შორის:

Istio-ს გამოყენებით კანარის განლაგების განხორციელების ნაბიჯ-ნაბიჯ სახელმძღვანელო იხ GitOps სამუშაო ნაკადები Istio-სთან ერთად. (Შენიშვნა. თარგმნა: ჩვენ ასევე ვთარგმნეთ მასალა კანარის გამოშვების შესახებ Istio-ზე აქ.)

კანარის განლაგება Weaveworks Flagger-ით

Weaveworks Flagger საშუალებას გაძლევთ მარტივად და ეფექტურად მართოთ კანარის გამოყვანა.

Flagger ავტომატიზირებს მათთან მუშაობას. ის იყენებს Istio-ს ან AWS App Mesh-ს ტრაფიკის მარშრუტისთვის და გადართვისთვის, ხოლო Prometheus-ის მეტრიკას შედეგების გასაანალიზებლად. გარდა ამისა, კანარის განლაგების ანალიზს შეიძლება დაემატოს webhooks მიღების ტესტების, დატვირთვის ტესტების და ნებისმიერი სხვა ტიპის შემოწმების ჩასატარებლად.

Kubernetes-ის დანერგვისა და აუცილებლობის შემთხვევაში, pods-ების ჰორიზონტალურ მასშტაბირებაზე (HPA) საფუძველზე, Flagger ქმნის ობიექტების კომპლექტს (Kubernetes-ის განლაგება, ClusterIP სერვისები და Istio ან App Mesh ვირტუალური სერვისები) კანარის განლაგების გასაანალიზებლად და განსახორციელებლად:

საკონტროლო მარყუჟის განხორციელება (საკონტროლო ციკლი),Flagger თანდათან ცვლის ტრაფიკს კანარის სერვერზე და პარალელურად გაზომავს შესრულების ძირითად ინდიკატორებს, როგორიცაა წარმატებული HTTP მოთხოვნების თანაფარდობა, მოთხოვნის საშუალო ხანგრძლივობა და პოდების ჯანმრთელობა. KPI (Key Performance Indicators) ანალიზის საფუძველზე, კანარი ან იზრდება ან იშლება და ანალიზის შედეგები გამოქვეყნებულია Slack-ში. ამ პროცესის აღწერა და დემონსტრირება შეგიძლიათ იხილოთ მასალაში პროგრესული მიწოდება App Mesh-ისთვის.

მუქი (დამალული) ან A/B განლაგება

Stealth-ის განლაგება არის კანარის სტრატეგიის კიდევ ერთი ვარიაცია (რომელთანაც, სხვათა შორის, Flagger-საც შეუძლია იმუშაოს). სტელსისა და კანარის განლაგებას შორის განსხვავება ისაა, რომ სტელსის განლაგება ეხება წინა მხარეს და არა უკანა მხარეს, როგორც კანარის განლაგება.

ამ განლაგების კიდევ ერთი სახელია A/B ტესტირება. იმის ნაცვლად, რომ ახალი ფუნქცია ხელმისაწვდომი გახდეს ყველა მომხმარებლისთვის, ის შესთავაზებს მათ მხოლოდ შეზღუდულ ნაწილს. როგორც წესი, ამ მომხმარებლებმა არ იციან, რომ ისინი არიან პიონერები ტესტერები (აქედან გამომდინარე, ტერმინი "დაფარვის განლაგება").

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

Flagger და A/B განლაგება

წონაზე დაფუძნებული მარშრუტიზაციის გარდა, Flagger-ს ასევე შეუძლია ტრაფიკის გადაყვანა კანარის სერვერზე HTTP პარამეტრების საფუძველზე. A/B ტესტირებისას, შეგიძლიათ გამოიყენოთ HTTP სათაურები ან ქუქიები მომხმარებლების კონკრეტული სეგმენტის სამიზნედ. ეს განსაკუთრებით ეფექტურია წინა აპლიკაციების შემთხვევაში, რომლებიც საჭიროებენ სესიის დაკავშირებას სერვერთან (სესიის კავშირი). დამატებითი ინფორმაცია შეგიძლიათ იხილოთ Flagger-ის დოკუმენტაციაში.

ავტორი მადლიერებას გამოხატავს სტეფან პროდანი, Weaveworks ინჟინერი (და Flagger-ის შემქმნელი), განლაგების ყველა ამ საოცარი ნიმუშისთვის.

PS მთარგმნელისგან

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

• «Ingress კონტროლერების მიმოხილვა და შედარება Kubernetes-ისთვის";
• «werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)";
• «შექმენით და განათავსეთ იმავე ტიპის მიკროსერვისები werf-ით და GitLab CI-ით";
• «რა არის GitOps?".

წყარო: www.habr.com