ხუთი გამოტოვება Kubernetes-ზე პირველი აპლიკაციის განლაგებისას

მარცხი Aris-Dreamer-ის მიერ

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

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

ნაბიჯი პირველი: პოდ მოთხოვნებისა და ლიმიტების დაყენება

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

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

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

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

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

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

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

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

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

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

1. დატვირთვის ტესტირების ხელსაწყოს გამოყენებით, ჩვენ ვატარებთ ტრაფიკის საბაზისო დონის სიმულაციას და ვაკვირდებით პოდ რესურსების (მეხსიერების და პროცესორის) გამოყენებას.
2. ჩვენ ვაყენებთ pod-ის მოთხოვნას თვითნებურად დაბალ მნიშვნელობაზე (რესურსების ლიმიტით დაახლოებით 5-ჯერ აღემატება მოთხოვნას) და ვაკვირდებით. როდესაც მოთხოვნები ძალიან დაბალია, პროცესი ვერ დაიწყება, რაც ხშირად იწვევს Go გაშვების იდუმალ შეცდომებს.

გაითვალისწინეთ, რომ რესურსების უფრო მაღალი ლიმიტები ართულებს დაგეგმვას, რადგან პოდს სჭირდება სამიზნე კვანძი საკმარისი რესურსით.

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

ნაბიჯი მეორე: Liveness და Readiness ტესტების დაყენება

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

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

Liveness ზონდები უნდა იყოს იაფი, რაც იმას ნიშნავს, რომ ისინი არ უნდა მოიხმარონ ბევრი რესურსი, რადგან ისინი ხშირად მუშაობენ და უნდა აცნობონ Kubernetes-ს, რომ აპლიკაცია მუშაობს.

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

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

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

ნიმუში მზადყოფნა მიუთითებს მზად არის თუ არა კონტეინერი მოთხოვნებისთვის. თუ მზადყოფნის ზონდი ვერ მოხერხდა, ბოლო წერტილის კონტროლერი ამოიღებს პოდის IP მისამართს ყველა სერვისის ბოლო წერტილებიდან, რომლებიც შეესაბამება პოდს. ეს ასევე ნათქვამია Kubernetes-ის დოკუმენტაციაში.

მზადყოფნის გამოკვლევები მოიხმარენ უფრო მეტ რესურსს, რადგან ისინი უნდა გაიგზავნოს backend-ზე ისე, რომ მიუთითებდეს, რომ აპლიკაცია მზად არის მიიღოს მოთხოვნები.

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

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

SELECT small_item FROM table LIMIT 1

აქ არის მაგალითი იმისა, თუ როგორ ვაკონფიგურირებთ ამ ორ მნიშვნელობას Kubernetes-ში:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

შეგიძლიათ დაამატოთ რამდენიმე დამატებითი კონფიგურაციის ვარიანტი:

• initialDelaySeconds - რამდენი წამი გაივლის კონტეინერის გაშვებასა და ნიმუშების დაწყებას შორის.
• periodSeconds - ლოდინის ინტერვალი ნიმუშის გაშვებებს შორის.
• timeoutSeconds — წამების რაოდენობა, რის შემდეგაც დანაყოფი განიხილება საგანგებო მდგომარეობად. რეგულარული ტაიმაუტი.
• failureThreshold - ტესტის წარუმატებლობის რაოდენობა, სანამ გადატვირთვის სიგნალი გაიგზავნება პოდში.
• successThreshold - წარმატებული ზონდების რაოდენობა, სანამ ღვეზელი მზა მდგომარეობაში გადავა (მარცხის შემდეგ, როდესაც ღობე იწყება ან აღდგება).

ნაბიჯი მესამე: ნაგულისხმევი ქსელის პოლიტიკის დაყენება პოდისთვის

Kubernetes-ს აქვს „ბრტყელი“ ქსელის ტოპოგრაფია; ნაგულისხმევად, ყველა პოდი პირდაპირ დაუკავშირდება ერთმანეთს. ზოგიერთ შემთხვევაში ეს არ არის სასურველი.

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

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

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

ამ კონფიგურაციის ვიზუალიზაცია:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
დაწვრილებით აქ.

ნაბიჯი მეოთხე: მორგებული ქცევა კაკვებისა და საწყის კონტეინერების გამოყენებით

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

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

ონლაინ ვრცელი გამოკვლევის შემდეგ, ირკვევა, რომ Kubernetes არ ელოდება Nginx კავშირების ამოწურვას, სანამ არ შეწყვეტს pod. წინასწარ გაჩერების კაკლის გამოყენებით, ჩვენ განვახორციელეთ შემდეგი ფუნქციონირება და მთლიანად მოვიშორეთ შეფერხების დრო:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

მაგრამ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

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

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

ნაბიჯი მეხუთე: ბირთვის კონფიგურაცია

და ბოლოს, მოდით ვისაუბროთ უფრო მოწინავე ტექნიკაზე.

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

დასასრულს

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

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

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

ყოველთვის დაუსვით საკუთარ თავს ეს კითხვები:

1. რამდენ რესურსს მოიხმარს აპლიკაციები და როგორ შეიცვლება ეს მოცულობა?
2. რა არის რეალური სკალირების მოთხოვნები? საშუალოდ რამდენ ტრაფიკს გაუმკლავდება აპლიკაცია? რაც შეეხება პიკის მოძრაობას?
3. რამდენად ხშირად დასჭირდება სერვისს ჰორიზონტალურად მასშტაბირება? რამდენად სწრაფად არის საჭირო ახალი ბლოკების ონლაინ შემოტანა ტრაფიკის მისაღებად?
4. რამდენად სწორად ითიშება ღეროები? ეს საერთოდ აუცილებელია? შესაძლებელია თუ არა განლაგების მიღწევა შეფერხების გარეშე?
5. როგორ შეგიძლიათ მინიმუმამდე დაიყვანოთ უსაფრთხოების რისკები და შეზღუდოთ ზიანი ნებისმიერი კომპრომეტირებული პოდებისგან? აქვს თუ არა რომელიმე სერვისს ნებართვა ან წვდომა, რომელსაც არ საჭიროებს?

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

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

კიდევ რა წაიკითხოთ:

1. საუკეთესო პრაქტიკა და საუკეთესო პრაქტიკა კონტეინერებისა და Kubernetes-ის საწარმოო გარემოში გაშვებისთვის.
2. 90+ სასარგებლო ინსტრუმენტი Kubernetes-ისთვის: განლაგება, მართვა, მონიტორინგი, უსაფრთხოება და სხვა.
3. ჩვენი არხი Kubernetes-ის გარშემო Telegram-ში.

წყარო: www.habr.com