დატვირთვის დაბალანსება და სკალირება ხანგრძლივი კავშირების Kubernetes-ში

ეს სტატია დაგეხმარებათ გაიგოთ, თუ როგორ მუშაობს დატვირთვის დაბალანსება Kubernetes-ში, რა ხდება გრძელვადიანი კავშირების სკალირებისას და რატომ უნდა გაითვალისწინოთ კლიენტის მხრიდან დაბალანსება, თუ იყენებთ HTTP/2, gRPC, RSockets, AMQP ან სხვა ხანგრძლივ პროტოკოლებს. . 

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

Kubernetes გთავაზობთ ორ მოსახერხებელ აბსტრაქციას აპლიკაციების განსათავსებლად: სერვისები და განლაგება.

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

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

ვნახოთ, როგორ გამოიყურება.

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

   

2. დატვირთვის ბალანსერს ეწოდება სერვისი და მას ენიჭება IP მისამართი. ნებისმიერი შემომავალი მოთხოვნა გადამისამართებულია ერთ-ერთ პოდზე:

   

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

   

4. თითოეულ პოდს ენიჭება საკუთარი IP მისამართი:

   

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

ეს ასე გამოიყურება.

1. Curl 10.96.45.152 მოთხოვნა მიიღება სერვისზე:

   

2. სერვისი ირჩევს სამიდან ერთ-ერთ პოდ მისამართს დანიშნულებად:

   

3. ტრაფიკი გადამისამართებულია კონკრეტულ პოდზე:

   

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

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

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

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

ასე გამოიყურება.

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

   

2. სერვისი ირჩევს ერთ-ერთ backend pod-ს დანიშნულების მისამართად:

   

3. ტრაფიკი მიდის Pod 1-დან Pod 5-მდე, რომელიც არჩეულია სერვისის მიერ:

   

4. Under 1-მა ზუსტად არ იცის, 5-ზე ნაკლების მსგავსი ჯიშის რამდენი იმალება სერვისის უკან:

   

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

ბალანსი Kubernetes სერვისებში

Kubernetes სერვისები არ არსებობს. არ არსებობს პროცესი სერვისისთვის, რომელსაც ენიჭება IP მისამართი და პორტი.

ამის გადამოწმება შეგიძლიათ კლასტერის ნებისმიერ კვანძში შესვლით და netstat -ntlp ბრძანების გაშვებით.

თქვენ ვერც კი იპოვით სერვისისთვის გამოყოფილ IP მისამართს.

სერვისის IP მისამართი მდებარეობს საკონტროლო ფენაში, კონტროლერში და ჩაწერილია მონაცემთა ბაზაში - etcd. იმავე მისამართს იყენებს სხვა კომპონენტი - kube-proxy.
Kube-proxy იღებს IP მისამართების სიას ყველა სერვისისთვის და ქმნის iptables წესების კომპლექტს კლასტერის თითოეულ კვანძზე.

ეს წესები ამბობს: „თუ ჩვენ ვხედავთ სერვისის IP მისამართს, ჩვენ უნდა შევცვალოთ მოთხოვნის დანიშნულების მისამართი და გავაგზავნოთ იგი ერთ-ერთ პოდში“.

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

მოდით შევხედოთ ამას. 

1. განვიხილოთ სამი კვანძის კლასტერი. თითოეულ კვანძს აქვს კვანძები:

   

2. შეკრული წიპწები, შეღებილი კრემისფრად, სერვისის ნაწილია. იმის გამო, რომ სერვისი არ არსებობს, როგორც პროცესი, ის ნაჩვენებია ნაცრისფერში:

   

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

   

4. მაგრამ სერვისი არ არსებობს, პროცესი არ არსებობს. Როგორ მუშაობს?

   

5. სანამ მოთხოვნა დატოვებს კვანძს, ის გადის iptables წესებს:

   

6. iptables-ის წესებმა იციან, რომ სერვისი არ არსებობს და ჩაანაცვლებს მის IP მისამართს ამ სერვისთან დაკავშირებული პოდების ერთ-ერთი IP მისამართით:

   

7. მოთხოვნა იღებს მოქმედ IP მისამართს, როგორც დანიშნულების მისამართი და მუშავდება ჩვეულებრივ:

   

8. ქსელის ტოპოლოგიიდან გამომდინარე, მოთხოვნა საბოლოოდ აღწევს პოდს:

   

შეუძლია iptables-ს დატვირთვის ბალანსი?

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

თუმცა, შესაძლებელია ისეთი წესების დაწერა, რომელიც მუშაობს ფსევდობალანსერი.

და ეს არის ზუსტად ის, რაც ხორციელდება Kubernetes-ში.

თუ თქვენ გაქვთ სამი პოდი, kube-proxy დაწერს შემდეგ წესებს:

1. აირჩიეთ პირველი ქვე 33% ალბათობით, წინააღმდეგ შემთხვევაში გადადით შემდეგ წესზე.
2. აირჩიეთ მეორე 50%-იანი ალბათობით, წინააღმდეგ შემთხვევაში გადადით შემდეგ წესზე.
3. აირჩიეთ მესამე ქვეშ.

ამ სისტემის შედეგად, თითოეული პოდი აირჩევა 33%-ის ალბათობით.

და არ არსებობს გარანტია, რომ Pod 2 აირჩევა შემდეგი Pod 1-ის შემდეგ.

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

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

Kubernetes-ში ხანგრძლივი კავშირები ნაგულისხმევად არ მასშტაბირდება

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

თუ frontend აგზავნის 100 მოთხოვნას წამში backend-ზე, მაშინ 100 სხვადასხვა TCP კავშირი იხსნება და იხურება.

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

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

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

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

აქ მოცემულია მაგალითების ბმული სხვადასხვა ენაზე:

• Keep-live in Node.js
• შეინახეთ ცოცხალი საგაზაფხულო ჩექმაში
• შეინახეთ ცოცხალი პითონში
• შეინახეთ ცოცხალი .NET-ში

რა მოხდება, თუ გამოვიყენებთ შენარჩუნება-ცოცხალს Kubernetes სერვისში?
დავუშვათ, რომ ორივე წინა და უკანა ნაწილი მხარს უჭერს შენარჩუნებას.

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

ჩვეულებრივი სიტუაციისგან განსხვავებით, როდესაც TCP კავშირი დახურულია პასუხის მიღების შემდეგ, ის ახლა ღიაა შემდგომი HTTP მოთხოვნებისთვის.

რა მოხდება, თუ ფრონტენტი უგზავნის მეტ მოთხოვნას ბექენდს?

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

iptables-მა არ უნდა გადაანაწილოს ტრაფიკი?

ამ შემთხვევაში არა.

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

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

ვნახოთ, როგორ გამოიყურება.

1. პირველი პოდი უგზავნის მოთხოვნას სერვისს:

   

2. თქვენ უკვე იცით, რა მოხდება შემდეგ. სერვისი არ არსებობს, მაგრამ არსებობს iptables წესები, რომლებიც დაამუშავებს მოთხოვნას:

   

3. დანიშნულების მისამართად შეირჩევა ერთ-ერთი სარეზერვო განყოფილება:

   

4. მოთხოვნა აღწევს პოდში. ამ ეტაპზე დამყარდება მუდმივი TCP კავშირი ორ პოდს შორის:

   

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

   

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

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

შეიძლება ამის გამოსწორება?

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

სერვისები არის IP მისამართებისა და პორტების კრებული, რომელსაც ბოლო წერტილები ეწოდება.

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

ან მიმართეთ მეტი რთული დაბალანსების ალგორითმები.

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

1. მიიღეთ სერვისის საბოლოო წერტილების სია.
2. გახსენით მუდმივი კავშირი თითოეული ბოლო წერტილისთვის.
3. როდესაც მოთხოვნა უნდა გაკეთდეს, გამოიყენეთ ერთ-ერთი ღია კავშირი.
4. რეგულარულად განაახლეთ ბოლო წერტილების სია, შექმენით ახალი ან დახურეთ ძველი მუდმივი კავშირები, თუ სია შეიცვლება.

ასე გამოიყურება.

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

   

2. თქვენ უნდა დაწეროთ კოდი, რომელიც კითხულობს, თუ რომელი პოდი არის სერვისის ნაწილი:

   

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

   

4. თქვენ ხართ პასუხისმგებელი დატვირთვის დაბალანსების ალგორითმზე:

   

ახლა ჩნდება კითხვა: ეხება თუ არა ეს პრობლემა მხოლოდ HTTP-ის შენარჩუნებას?

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

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

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

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

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

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

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

ქვემოთ მოცემულია MySQL მონაცემთა ბაზის კლასტერზე წვდომის მაგალითი Node.js-დან:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

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

• WebSockets და დაცული WebSockets
• HTTP / 2
• gRPC
• RSockets
• AMQP

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

მაგრამ თუ ეს პროტოკოლები ასე პოპულარულია, რატომ არ არსებობს სტანდარტიზებული დაბალანსების გადაწყვეტა? რატომ უნდა შეიცვალოს კლიენტის ლოგიკა? არის თუ არა მშობლიური Kubernetes გამოსავალი?

Kube-proxy და iptables შექმნილია იმისთვის, რომ დაფაროს ყველაზე გავრცელებული გამოყენების შემთხვევები Kubernetes-ში განლაგებისას. ეს არის მოხერხებულობისთვის.

თუ იყენებთ ვებ სერვისს, რომელიც ავლენს REST API-ს, გაგიმართლათ - ამ შემთხვევაში, მუდმივი TCP კავშირები არ გამოიყენება, შეგიძლიათ გამოიყენოთ Kubernetes-ის ნებისმიერი სერვისი.

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

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

ხანგრძლივი კავშირების დაბალანსება Kubernetes-ში

Kubernetes-ში არსებობს ოთხი სახის სერვისი:

1. ClusterIP
2. NodePort
3. LoadBalancer
4. უფროსობა

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

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

ყველა სერვისი ეფუძნება უთავო სერვისს.

ClusterIP სერვისი არის უთავო სერვისი რამდენიმე დამატებით: 

1. მართვის ფენა ანიჭებს მას IP მისამართს.
2. Kube-proxy ქმნის iptables აუცილებელ წესებს.

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

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

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

სერვისი Mesh დაგეხმარებათ

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

როდესაც აპლიკაცია იწყება, ის:

1. სერვისიდან იღებს IP მისამართების სიას.
2. ხსნის და ინარჩუნებს კავშირის აუზს.
3. პერიოდულად ანახლებს აუზს ბოლო წერტილების დამატებით ან წაშლით.

როგორც კი აპლიკაციას მოთხოვნის გაკეთება სურს, ის:

1. ირჩევს ხელმისაწვდომ კავშირს გარკვეული ლოგიკის გამოყენებით (მაგ., რაუნდი).
2. ასრულებს მოთხოვნას.

ეს ნაბიჯები მუშაობს როგორც WebSockets, gRPC და AMQP კავშირებისთვის.

თქვენ შეგიძლიათ გამოყოთ ეს ლოგიკა ცალკე ბიბლიოთეკაში და გამოიყენოთ იგი თქვენს აპლიკაციებში.

თუმცა, ამის ნაცვლად შეგიძლიათ გამოიყენოთ სერვისული ბადეები, როგორიცაა Istio ან Linkerd.

Service Mesh აძლიერებს თქვენს აპლიკაციას პროცესით, რომელიც:

1. ავტომატურად ეძებს სერვისის IP მისამართებს.
2. ამოწმებს კავშირებს, როგორიცაა WebSockets და gRPC.
3. აბალანსებს მოთხოვნებს სწორი პროტოკოლის გამოყენებით.

Service Mesh ეხმარება ტრაფიკის მართვას კლასტერში, მაგრამ ის საკმაოდ რესურსზე ინტენსიურია. სხვა ვარიანტები იყენებს მესამე მხარის ბიბლიოთეკებს, როგორიცაა Netflix Ribbon ან პროგრამირებადი მარიონეტები, როგორიცაა Envoy.

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

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

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

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

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

რაც უფრო პრობლემურია, საპირისპირო სცენარია.

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

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

დარჩენილი სერვერები უმოქმედო იქნება:

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

დასკვნა

Kubernetes სერვისები შექმნილია იმისთვის, რომ იმუშაოს უმეტეს ვებ აპლიკაციის სცენარებში.

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

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

გუნდის მიერ მომზადებული თარგმანი Kubernetes aaS Mail.ru-დან.

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

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

წყარო: www.habr.com