როგორ მივიდეთ Kubernetes Pod რესურსებზე

ჯილდო ტოჰადის მიერ

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

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

გუნდი Kubernetes aaS Mail.ru-დან თარგმნა სტატია კონტეინერის რესურსების (CPU & MEM), მოთხოვნებისა და რესურსების შეზღუდვის შესახებ. თქვენ შეიტყობთ ამ პარამეტრების სარგებელს და რა მოხდება, თუ მათ არ დააყენებთ.

გამოთვლითი რესურსები

ჩვენ გვაქვს ორი ტიპის რესურსი შემდეგი ერთეულებით:

• ცენტრალური დამუშავების ერთეული (CPU) - ბირთვები;
• მეხსიერება (MEM) - ბაიტი.

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

• მოთხოვნილი Pod რესურსები = ყველა კონტეინერის მოთხოვნილი რესურსების ჯამი;
• პოდ რესურსის ლიმიტი = პოდ რესურსების ლიმიტების ჯამი.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

მოთხოვნილი და შეზღუდული რესურსების მაგალითი

საველე resources.requested სპეციფიკაციებიდან Pod არის ერთ-ერთი ელემენტი, რომელიც გამოიყენება სასურველი კვანძის მოსაძებნად. თქვენ უკვე შეგიძლიათ დაგეგმოთ ამისთვის Pod-ის განლაგება. როგორ მოვძებნოთ შესაფერისი კვანძი?

Kubernetes შედგება რამდენიმე კომპონენტისგან, მათ შორის მთავარი კვანძი ან ძირითადი კვანძი (Kubernetes Control Plane). მთავარ კვანძს აქვს რამდენიმე პროცესი: kube-apiserver, kube-controller-manager და kube-scheduler.

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

სად განთავსდება მეწამული პოდი?

სურათზე ხედავთ, რომ kube-scheduler-მა უნდა დანიშნოს ახალი მეწამული Pod. Kubernetes კლასტერი შეიცავს ორ კვანძს: A და B. როგორც ხედავთ, kube-scheduler-ს არ შეუძლია დანიშნოს Pod A კვანძზე - ხელმისაწვდომი (მოუთხოველი) რესურსები არ ემთხვევა მეწამული Pod-ის მოთხოვნებს. ასე რომ, მეწამული Pod-ის მიერ მოთხოვნილი 1 GB მეხსიერება არ მოერგება A კვანძს, რადგან ხელმისაწვდომი მეხსიერება არის 0,5 GB. მაგრამ B კვანძს აქვს საკმარისი რესურსი. შედეგად, kube-scheduler გადაწყვეტს, რომ მეწამული Pod-ის დანიშნულება არის კვანძი B.

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

რესურსის ლიმიტი არის ზღვარი, რომელსაც CPU/MEM ვერ გადალახავს. თუმცა, CPU რესურსი მოქნილია, ამიტომ კონტეინერები, რომლებიც მიაღწევენ CPU-ს ზღვრებს, არ გამოიწვევს Pod-ის შეწყვეტას. ამის ნაცვლად, CPU throttling დაიწყება. თუ MEM-ის გამოყენების ლიმიტი მიღწეულია, კონტეინერი შეჩერდება OOM-Killer-ის გამო და განახლდება, თუ დაშვებულია RestartPolicy პარამეტრით.

მოთხოვნილი და მაქსიმალური რესურსები დეტალურად

რესურსების კომუნიკაცია Docker-სა და Kubernetes-ს შორის

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

მეხსიერება: მოთხოვნა და შეზღუდვა

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

როგორც ზემოთ აღინიშნა, მეხსიერება იზომება ბაიტებში. Დაფუძნებული Kubernetes დოკუმენტაცია, ჩვენ შეგვიძლია მივუთითოთ მეხსიერება როგორც რიცხვი. ჩვეულებრივ, ეს არის მთელი რიცხვი, მაგალითად 2678 - ანუ 2678 ბაიტი. ასევე შეგიძლიათ გამოიყენოთ სუფიქსები G и Gi, მთავარია გვახსოვდეს, რომ ისინი არ არიან ეკვივალენტები. პირველი არის ათობითი და მეორე ორობითი. k8s დოკუმენტაციაში ნახსენები მაგალითის მსგავსად: 128974848, 129e6, 129M, 123Mi - ისინი პრაქტიკულად ექვივალენტები არიან.

Kubernetes ვარიანტი limits.memory ემთხვევა დროშას --memory დოკერისგან. იმ შემთხვევაში, თუ request.memory Docker-ისთვის ისარი არ არის, რადგან Docker არ იყენებს ამ ველს. შეიძლება იკითხოთ, არის თუ არა ეს აუცილებელი? კი საჭიროა. როგორც უკვე ვთქვი, ველი კუბერნეტესისთვის მნიშვნელოვანია. მისგან მიღებული ინფორმაციის საფუძველზე, kube-scheduler წყვეტს რომელ კვანძზე დანიშნოს Pod.

რა მოხდება, თუ დააყენებთ არასაკმარის მეხსიერებას მოთხოვნისთვის?

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

რა მოხდება, თუ მეხსიერების ლიმიტს ძალიან დაბალზე დააყენებთ?

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

რა მოხდება, თუ არ მიუთითებთ მოთხოვნილ მეხსიერებას?

Kubernetes მიიღებს ზღვრულ მნიშვნელობას და დააყენებს მას ნაგულისხმევ მნიშვნელობად.

რა შეიძლება მოხდეს, თუ არ მიუთითებთ მეხსიერების ლიმიტს?

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

რა მოხდება, თუ არ მიუთითებთ მეხსიერების ლიმიტებს?

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

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

როგორც წესი, რეკომენდებულია იგივე მნიშვნელობის დაყენება request.memory и limit.memory. ეს უზრუნველყოფს იმას, რომ Kubernetes არ დანიშნავს Pod-ს კვანძზე, რომელსაც აქვს საკმარისი მეხსიერება Pod-ის გასაშვებად, მაგრამ არასაკმარისი მის გასაშვებად. გაითვალისწინეთ: Kubernetes Pod დაგეგმვა ითვალისწინებს მხოლოდ requests.memoryხოლო limits.memory არ ითვალისწინებს.

CPU: მოთხოვნა და ლიმიტი

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU-სთან ერთად ყველაფერი ცოტა უფრო რთულია. კუბერნეტისა და დოკერის ურთიერთობის სურათს რომ დავუბრუნდეთ, ხედავთ ამას request.cpu შეესაბამება --cpu-shares, ხოლო limit.cpu ემთხვევა დროშას cpus დოკერში.

CPU, რომელსაც Kubernetes ითხოვს, მრავლდება 1024-ზე, CPU ციკლების პროპორციით. თუ გსურთ მოითხოვოთ 1 სრული ბირთვი, უნდა დაამატოთ cpu: 1როგორც ზემოთ არის ნაჩვენები.

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

CPU მოთხოვნა - Single Core სისტემა

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

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

გაანგარიშების საფუძველზე სამი ბავშვი მიიღებს ბირთვის 28%-ს და არა მთელ ბირთვს. მეოთხე ბავშვი მიიღებს სრული ბირთვის 14%-ს და არა ნახევარს. მაგრამ ყველაფერი განსხვავებული იქნება, თუ თქვენ გაქვთ მრავალბირთვიანი სისტემა.

CPU მოთხოვნა - მრავალბირთვიანი (4) სისტემა

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

ზემოთ მოყვანილი გამოთვლები გამარტივებულია იმის გასაგებად, თუ როგორ ნაწილდება CPU კონტეინერებს შორის. რა თქმა უნდა, გარდა თავად კონტეინერებისა, არის სხვა პროცესებიც, რომლებიც ასევე იყენებენ CPU რესურსებს. როდესაც ერთ კონტეინერში პროცესები უმოქმედოა, სხვებს შეუძლიათ გამოიყენონ მისი რესურსი. CPU: "200m" შეესაბამება CPU: 0,2, რაც ნიშნავს ერთი ბირთვის დაახლოებით 20%.

ახლა მოდით ვისაუბროთ limit.cpu. CPU, რომელსაც Kubernetes ზღუდავს, მრავლდება 100-ზე. შედეგი არის დროის რაოდენობა, რომელსაც შეუძლია კონტეინერმა გამოიყენოს ყოველ 100 μs (cpu-period).

limit.cpu შეესაბამება დოკერის დროშას --cpus. ეს არის ძველის ახალი კომბინაცია --cpu-period и --cpu-quota. მისი დაყენებით, ჩვენ მივუთითებთ CPU-ს რამდენი ხელმისაწვდომი რესურსი შეიძლება გამოიყენოს კონტეინერმა მაქსიმუმ, სანამ throttling დაიწყება:

• Cpus - კომბინაცია cpu-period и cpu-quota. cpus = 1.5 პარამეტრის ტოლფასი cpu-period = 100000 и cpu-quota = 150000;
• CPU- პერიოდი - პერიოდი CPU CFS გრაფიკი, ნაგულისხმევი 100 მიკროწამი;
• CPU-კვოტა - მიკროწამების რაოდენობა შიგნით cpu-period, რომელიც შემოსაზღვრულია კონტეინერით.

რა მოხდება, თუ დააინსტალირეთ არასაკმარისი მოთხოვნილი CPU?

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

რა მოხდება, თუ CPU-ის ლიმიტს ძალიან დაბალზე დააყენებთ?

ვინაიდან პროცესორის რესურსი რეგულირდება, throttling ჩაირთვება.

რა მოხდება, თუ არ მიუთითებთ CPU მოთხოვნას?

როგორც მეხსიერების შემთხვევაში, მოთხოვნის მნიშვნელობა ლიმიტის ტოლია.

რა მოხდება, თუ არ მიუთითებთ CPU-ს ლიმიტს?

კონტეინერი გამოიყენებს იმდენ CPU-ს, რამდენიც სჭირდება. თუ ნაგულისხმევი CPU პოლიტიკა (LimitRange) არის განსაზღვრული სახელთა სივრცეში, მაშინ ეს ლიმიტი ასევე გამოიყენება კონტეინერისთვის.

რა მოხდება, თუ არ მიუთითებთ მოთხოვნას ან CPU-ს ლიმიტს?

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

გახსოვდეთ: თუ თქვენ მოითხოვთ იმაზე მეტ CPU-ს, ვიდრე კვანძებს შეუძლიათ უზრუნველყონ, Pod არ დაიგეგმება. Requests.cpu - არა მინიმალური მნიშვნელობა, არამედ საკმარისი მნიშვნელობა Pod-ის დასაწყებად და წარუმატებლობით მუშაობისთვის. თუ აპლიკაცია არ ასრულებს კომპლექსურ გამოთვლებს, საუკეთესო ვარიანტია ინსტალაცია request.cpu <= 1 და გაუშვით იმდენი რეპლიკა, რამდენიც საჭიროა.

მოთხოვნილი რესურსების იდეალური რაოდენობა ან რესურსის ლიმიტი

გავიგეთ გამოთვლითი რესურსების შეზღუდვის შესახებ. ახლა დროა ვუპასუხოთ კითხვას: „რამდენ რესურსს მოითხოვს ჩემი Pod აპლიკაციის უპრობლემოდ გასაშვებად? რა არის იდეალური რაოდენობა?

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

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

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

დასკვნა

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

მოკლედ, გასათვალისწინებელია რამდენიმე რამ:

1. მოთხოვნილი რესურსები არის კონფიგურაცია, რომელიც გათვალისწინებულია გაშვების დროს (როდესაც Kubernetes გეგმავს აპლიკაციის მასპინძლობას). ამის საპირისპიროდ, რესურსების შეზღუდვა მნიშვნელოვანია გაშვების დროს - როდესაც აპლიკაცია უკვე მუშაობს კვანძზე.
2. მეხსიერებასთან შედარებით, CPU არის რეგულირებადი რესურსი. თუ არ არის საკმარისი CPU, თქვენი Pod არ გაითიშება და ჩართვის მექანიზმი ჩაირთვება.
3. მოთხოვნილი რესურსები და რესურსების ლიმიტი არ არის მინიმალური და მაქსიმალური მნიშვნელობები! მოთხოვნილი რესურსების განსაზღვრით, თქვენ დარწმუნდებით, რომ აპლიკაცია უპრობლემოდ იმუშავებს.
4. კარგი პრაქტიკაა მეხსიერების მოთხოვნის დაყენება მეხსიერების ლიმიტის ტოლი.
5. Ok მოთხოვნილია ინსტალაცია CPU <=1თუ აპლიკაცია არ ასრულებს რთულ გამოთვლებს.
6. თუ მოითხოვთ იმაზე მეტ რესურსს, ვიდრე ხელმისაწვდომია კვანძზე, Pod არასოდეს დაიგეგმება ამ კვანძში.
7. მოთხოვნილი რესურსების/რესურსების ლიმიტების სწორი ოდენობის დასადგენად გამოიყენეთ დატვირთვის ტესტირება და მონიტორინგი.

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

გისურვებთ წარმატებებს!

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

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

წყარო: www.habr.com