ცხრა Kubernetes შესრულების რჩევა

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

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

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

1. თვალყური ადევნეთ გუნდის და აპლიკაციის რესურსებს

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

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

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

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

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

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

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

როგორც აღწერიდან ხედავთ resourcequotas, თუ ops ბრძანებას სურს განათავსოს პოდები, რომლებიც მოიხმარენ კიდევ 10 პროცესორს, მაშინ დაგეგმავი არ დაუშვებს ამის გაკეთებას და გამოსცემს შეცდომას:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

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

2. აირჩიეთ საუკეთესო ფაილის შესანახი

აქ მსურს შევეხო მუდმივი მოცულობების თემას და Kubernetes-ის მუშა კვანძების დისკის ქვესისტემას. იმედი მაქვს, რომ არავინ იყენებს "კუბს" HDD-ზე წარმოებაში, მაგრამ ზოგჯერ ჩვეულებრივი SSD-იც კი უკვე არ არის საკმარისი. ჩვენ ისეთი პრობლემის წინაშე აღმოვჩნდით, რომ ჟურნალები კლავდნენ დისკს I/O ოპერაციებით და აქ არც ისე ბევრი გამოსავალია:

• გამოიყენეთ მაღალი ხარისხის SSD ან გადადით NVMe-ზე (თუ თქვენ მართავთ საკუთარ აპარატურას).

• ჭრის დონის შემცირება.

• გააკეთეთ "ჭკვიანური" დაბალანსება ღობეების, რომლებიც აუპატიურებენ დისკს (podAntiAffinity).

ზემოთ მოცემული სკრინშოტი გვიჩვენებს, თუ რა ხდება nginx-ingress-controller-ში დისკთან, როდესაც ჩართულია access_logs logging (~12k logs/წმ). ასეთმა მდგომარეობამ, რა თქმა უნდა, შეიძლება გამოიწვიოს ამ კვანძზე ყველა აპლიკაციის დეგრადაცია.

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

3. შექმენით ოპტიმიზებული სურათები

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

ოპტიმიზაცია ნიშნავს, რომ სურათები:

• შეიცავდეს მხოლოდ ერთ აპლიკაციას ან ასრულებს მხოლოდ ერთ ფუნქციას;

• მცირე ზომის, რადგან დიდი სურათები უარესად გადადის ქსელში;

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

• გამოიყენეთ კონტეინერისთვის მოსახერხებელი ოპერაციული სისტემები (როგორიცაა Alpine ან CoreOS), რომლებიც უფრო მდგრადია კონფიგურაციის შეცდომებზე;

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

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

1. შემცირდა ქსელის დატვირთვა მთელ კლასტერზე.

2. შემცირდა კონტეინერის გაშვების დრო.

3. თქვენი მთელი Docker რეესტრის უფრო მცირე ზომა.

4. გამოიყენეთ DNS ქეში

თუ ვსაუბრობთ მაღალ დატვირთვაზე, მაშინ კლასტერის DNS სისტემის დარეგულირების გარეშე, ცხოვრება საკმაოდ ცუდია. ერთხელ, Kubernetes-ის დეველოპერებმა მხარი დაუჭირეს მათ kube-dns გადაწყვეტას. ის ასევე განხორციელდა ჩვენს ქვეყანაში, მაგრამ ეს პროგრამა განსაკუთრებით არ იყო მორგებული და არ აძლევდა საჭირო შესრულებას, თუმცა, როგორც ჩანს, ამოცანა მარტივია. შემდეგ გამოჩნდა coredns, რომლებზეც ჩვენ გადავედით და არ ვიცოდით მწუხარება, მოგვიანებით ის გახდა ნაგულისხმევი DNS სერვისი K8-ში. რაღაც მომენტში ჩვენ გავიზარდეთ 40 ათასი rps-მდე DNS სისტემაში და ეს გამოსავალი ასევე არ იყო საკმარისი. მაგრამ, იღბლიანი შანსით, Nodelocaldns გამოვიდა, aka node ადგილობრივი ქეში, აკა NodeLocal DNSCache.

რატომ ვიყენებთ მას? Linux-ის ბირთვში არის შეცდომა, რომელიც, როდესაც მრავალჯერადი წვდომა ხდება NAT-ის მეშვეობით UDP-ზე, იწვევს კონტრაქტის ცხრილებში ჩაწერის რბოლის მდგომარეობას და NAT-ის მეშვეობით ტრაფიკის ნაწილი იკარგება (სერვისის ყოველი მოგზაურობა არის NAT). Nodelocaldns აგვარებს ამ პრობლემას NAT-ის მოშორებით და TCP კავშირის განახლებით ზემოთ DNS-ზე, ასევე ზედა ნაკადის DNS მოთხოვნების ლოკალურად ქეშირებით (მათ შორის მოკლე 5 წამიანი უარყოფითი ქეში).

5. ჰორიზონტალურად და ვერტიკალურად სკალირება ავტომატურად

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

VPA საშუალებას გაძლევთ ავტომატურად გაზარდოთ თქვენი კონტეინერების მოთხოვნები/ლიმიტები პოდში, რეალური გამოყენების საფუძველზე. როგორ შეიძლება იყოს სასარგებლო? თუ თქვენ გაქვთ Pods, რომლებიც რაიმე მიზეზის გამო ვერ ხერხდება ჰორიზონტალურად (რაც არ არის მთლად სანდო), მაშინ შეგიძლიათ სცადოთ ენდოთ VPA-ს მისი რესურსების შეცვლაში. მისი ფუნქციაა სარეკომენდაციო სისტემა, რომელიც დაფუძნებულია მეტრულ სერვერის ისტორიულ და მიმდინარე მონაცემებზე, ასე რომ, თუ არ გსურთ ავტომატურად შეცვალოთ მოთხოვნები/ლიმიტები, შეგიძლიათ უბრალოდ აკონტროლოთ თქვენი კონტეინერების რეკომენდებული რესურსები და ოპტიმიზაცია მოახდინოთ CPU და მეხსიერების შესანახად. კლასტერში.

სურათი აღებულია https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

მაგალითად, აქ არის ტიპიური pod პარამეტრები:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

სარეკომენდაციო ძრავა განსაზღვრავს, რომ თქვენს აპლიკაციას სჭირდება 300 მ CPU და 500 Mi, რომ სწორად იმუშაოს. თქვენ მიიღებთ ამ პარამეტრებს:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

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

• CPU: 200m → 300m: თანაფარდობა 1:1.75;

• მეხსიერება: 250 Mi → 500 Mi: 1:2 თანაფარდობა.

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

სურათი აღებულია https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

6. ნუ დაივიწყებთ კვანძების აფინურობისა და პოდ აფინურობის შესახებ

ყველა კვანძი არ მუშაობს ერთსა და იმავე აპარატურაზე და ყველა კვანძს არ სჭირდება გამოთვლითი ინტენსიური აპლიკაციების გაშვება. Kubernetes გაძლევთ საშუალებას მიუთითოთ კვანძების და კვანძების სპეციალიზაცია გამოყენებით კვანძის აფინურობა и Pod Affinity.

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

ვთქვათ, თქვენ გაქვთ ორი კვანძი: ერთი ერთად CPUType=HIGHFREQ და დიდი რაოდენობით სწრაფი ბირთვები, სხვა MemoryType=HIGHMEMORY მეტი მეხსიერება და უფრო სწრაფი შესრულება. უმარტივესი გზაა კვანძისთვის pod განლაგების მინიჭება HIGHFREQგანყოფილების დამატებით spec ასეთი სელექტორი:

…
nodeSelector:
	CPUType: HIGHFREQ

ამის გაკეთების უფრო ძვირი და კონკრეტული გზა არის გამოყენება nodeAffinity სფეროში affinity განდელა spec. არსებობს ორი ვარიანტი:

• requiredDuringSchedulingIgnoredDuringExecution: რთული პარამეტრი (დაგეგმავი განათავსებს პოდებს მხოლოდ კონკრეტულ კვანძებზე (და სხვაგან არსად));

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

თქვენ შეგიძლიათ მიუთითოთ კონკრეტული სინტაქსი კვანძების ეტიკეტების მართვისთვის, მაგალითად, In, NotIn, Exists, DoesNotExist, Gt ან Lt. თუმცა, გახსოვდეთ, რომ ეტიკეტების გრძელ სიებში კომპლექსური მეთოდები შეანელებს გადაწყვეტილების მიღებას კრიტიკულ სიტუაციებში. სხვა სიტყვებით რომ ვთქვათ, ზედმეტად ნუ გაართულებთ.

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

В podAffinity ზღვარი affinity განდელა spec იგივე ველები ხელმისაწვდომია, როგორც შემთხვევაში nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. განსხვავება მხოლოდ ისაა matchExpressions დააკავშირებს პოდებს კვანძთან, რომელიც უკვე აწარმოებს პოდს ამ ლეიბლით.

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

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

7. ლაქები და ტოლერანტობა

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

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

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

ასევე აღსანიშნავია, რომ დაბინძურების მექანიზმი მხარს უჭერს სამ ძირითად ეფექტს: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule ნიშნავს, რომ სანამ არ იქნება შესაბამისი ჩანაწერი pod სპეციფიკაციაში tolerations, ის არ შეიძლება განლაგდეს კვანძში (ამ მაგალითში node10).

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

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

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

აი, როგორი იქნება პოდის სპეციფიკაცია:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

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

8. დააყენეთ პოდის განლაგების პრიორიტეტი

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

Kubernetes გთავაზობთ სხვადასხვა გზებს Pod Priority და Preemption დასაყენებლად. პარამეტრი შედგება რამდენიმე ნაწილისაგან: ობიექტი PriorityClass და ველის აღწერა priorityClassName პოდის სპეციფიკაციაში. განვიხილოთ მაგალითი:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

ჩვენ ვქმნით PriorityClass, მიეცით მას სახელი, აღწერა და მნიშვნელობა. რაც უფრო მაღალია value, რაც უფრო მაღალია პრიორიტეტი. მნიშვნელობა შეიძლება იყოს ნებისმიერი 32-ბიტიანი მთელი რიცხვი 1-ზე ნაკლები ან ტოლი. უფრო მაღალი მნიშვნელობები დაცულია მისიისთვის კრიტიკული სისტემის პოდებისთვის, რომლებიც, როგორც წესი, არ შეიძლება იყოს წინასწარი შეზღუდვა. გამოძევება მოხდება მხოლოდ იმ შემთხვევაში, თუ მაღალი პრიორიტეტის პოდს არსად აქვს შემობრუნება, მაშინ კონკრეტული კვანძიდან ზოგიერთი ჯიშის ევაკუაცია მოხდება. თუ ეს მექანიზმი ძალიან ხისტია თქვენთვის, მაშინ შეგიძლიათ დაამატოთ ეს ვარიანტი preemptionPolicy: Never, და შემდეგ არ იქნება პრემია, პოდი პირველი იქნება რიგში და დაელოდება განრიგის მოძიებას მისთვის უფასო რესურსებს.

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

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

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

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

9. თქვენი ETCD კლასტერის ოპტიმიზაცია

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

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

თუ ვსაუბრობთ სერვისის დაყენებაზე, მაშინ რამდენიმე რეკომენდაციაა:

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

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

დასკვნა

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

წყარო: www.habr.com