ჩვენი გამოცდილება CSI დრაივერის შემუშავებაში Kubernetes-ში Yandex.Cloud-ისთვის

მოხარული ვართ განვაცხადოთ, რომ Flant აფართოებს თავის წვლილს Kubernetes-ისთვის ღია წყაროს ინსტრუმენტებში გამოშვებით CSI დრაივერის ალფა ვერსია (Container Storage Interface) Yandex.Cloud-ისთვის.

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

შესავალი

Რატომ არის ეს?

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

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

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

რა არის და ვისთვის?

ასე რომ, ჩვენ უკვე ვისაუბრეთ Kubernetes-ში შენახვის თანამედროვე მიდგომაზე: როგორ მუშაობს CSI? и როგორ მოვიდა საზოგადოება ამ მიდგომისადმი.

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

განვითარების საფუძველი ავიღეთ CSI დრაივერი DigitalOcean ღრუბლისთვის და რამდენიმე იდეა დრაივერები GCP-სთვის, ვინაიდან ამ ღრუბლების API-სთან (Google და Yandex) ურთიერთქმედებას არაერთი მსგავსება აქვს. კერძოდ, API და სწორი კლინიკური პრაქტიკისდა Yandex დააბრუნეთ ობიექტი Operation გრძელვადიანი ოპერაციების სტატუსის თვალყურის დევნება (მაგალითად, ახალი დისკის შექმნა). Yandex.Cloud API-სთან ურთიერთობისთვის გამოიყენეთ Yandex.Cloud Go SDK.

შესრულებული სამუშაოს შედეგი გამოქვეყნებულია GitHub-ზე და შეიძლება სასარგებლო იყოს მათთვის, ვინც რაიმე მიზეზით იყენებს საკუთარ Kubernetes-ის ინსტალაციას Yandex.Cloud ვირტუალურ მანქანებზე (მაგრამ არა მზა მართულ კლასტერზე) და სურს გამოიყენოს (შეკვეთა) დისკები CSI-ის მეშვეობით.

Реализация

ძირითადი მახასიათებლები

ამჟამად დრაივერი მხარს უჭერს შემდეგ ფუნქციებს:

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

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

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

Yandex.Cloud API-ში დისკების რეალურ დროში გაზრდის შესაძლებლობის არარსებობა არის შეზღუდვა, რომელიც ართულებს PV-სთვის ზომის შეცვლის ოპერაციას (მუდმივი მოცულობა): ამ შემთხვევაში აუცილებელია აპლიკაციის პოდი, რომელიც იყენებს დისკს, შეჩერდეს. და ამან შეიძლება გამოიწვიოს აპლიკაციების შეფერხება.

მიხედვით CSI სპეციფიკაციები, თუ CSI კონტროლერი იტყობინება, რომ მას შეუძლია დისკების ზომის შეცვლა მხოლოდ „ხაზგარეშე“ (VolumeExpansion.OFFLINE), მაშინ დისკის გაზრდის პროცესი ასე უნდა წავიდეს:

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

• დანამატს აქვს კონტროლერი PUBLISH_UNPUBLISH_VOLUME უნარი და ControllerUnpublishVolume წარმატებით იქნა გამოძახებული.

ᲐᲜ ᲙᲘᲓᲔᲕ

• დანამატს არ აქვს კონტროლერი PUBLISH_UNPUBLISH_VOLUME შესაძლებლობა, დანამატს აქვს კვანძი STAGE_UNSTAGE_VOLUME უნარი და NodeUnstageVolume წარმატებით დასრულდა

ᲐᲜ ᲙᲘᲓᲔᲕ

• დანამატს არ აქვს კონტროლერი PUBLISH_UNPUBLISH_VOLUME შესაძლებლობა, არც კვანძი STAGE_UNSTAGE_VOLUME უნარი და NodeUnpublishVolume წარმატებით დასრულდა.

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

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

• გვერდითა კონტეინერში csi-attacher, რომელიც პასუხისმგებელი უნდა იყოს მონტაჟებს შორის საჭირო უფსკრულის არსებობაზე, ეს ფუნქცია უბრალოდ არ არის დანერგილი ხაზგარეშე ზომის შეცვლაში. ამის შესახებ დისკუსია დაიწყო აქ.
• კონკრეტულად რა არის გვერდითი კარის კონტეინერი ამ კონტექსტში? თავად CSI მოდული არ ურთიერთქმედებს Kubernetes API-სთან, მაგრამ მხოლოდ პასუხობს gRPC ზარებს, რომლებიც მას გვერდითი კარის კონტეინერებით იგზავნება. უახლესი ვითარდება კუბერნეტების საზოგადოების მიერ.

ჩვენს შემთხვევაში (CSI მოდული), დისკის გაზრდის ოპერაცია ასე გამოიყურება:

1. ჩვენ ვიღებთ gRPC ზარს ControllerExpandVolume;
2. ჩვენ ვცდილობთ გავზარდოთ დისკი API-ში, მაგრამ ვიღებთ შეცდომას ოპერაციის შეუძლებლობის შესახებ, რადგან დისკი დამონტაჟებულია;
3. ჩვენ ვინახავთ დისკის იდენტიფიკატორს რუკაზე, რომელიც შეიცავს დისკებს, რომლებისთვისაც საჭიროა გაზრდის ოპერაციის შესრულება. ქვემოთ, მოკლედ, ამ რუკას დავარქმევთ როგორც volumeResizeRequired;
4. ხელით ამოიღეთ დისკი, რომელიც იყენებს დისკს. Kubernetes განაახლებს მას. ისე, რომ დისკს არ ჰქონდეს დრო დამონტაჟება (ControllerPublishVolume) გაზრდის ოპერაციის დასრულებამდე დამონტაჟების მცდელობისას ვამოწმებთ, რომ მოცემული დისკი ჯერ კიდევ შეყვანილია volumeResizeRequired და დააბრუნეთ შეცდომა;
5. CSI დრაივერი ცდილობს ხელახლა განახორციელოს ზომის შეცვლის ოპერაცია. თუ ოპერაცია წარმატებით დასრულდა, ამოიღეთ დისკი volumeResizeRequired;
6. იმიტომ რომ დისკის ID აკლია volumeResizeRequired, ControllerPublishVolume წარმატებით გადის, დისკი დამონტაჟებულია, pod იწყება.

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

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

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

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

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

როგორ დავიწყოთ მისი გამოყენება?

დრაივერი მხარდაჭერილია Kubernetes 1.15 და უფრო მაღალ ვერსიაზე. იმისათვის, რომ მძღოლმა იმუშაოს, უნდა აკმაყოფილებდეს შემდეგი მოთხოვნები:

• დროშა --allow-privileged მნიშვნელობაზე დაყენებული true API სერვერისა და კუბელეტისთვის;
• შედის --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true API სერვერისა და კუბელეტისთვის;
• მთის გამრავლება (მთის გამრავლება) უნდა იყოს ჩართული კლასტერზე. Docker-ის გამოყენებისას, დემონი უნდა იყოს კონფიგურირებული ისე, რომ დაუშვას საერთო სამონტაჟო.

ყველა საჭირო ნაბიჯი თავად ინსტალაციისთვის აღწერილია README-ში. ინსტალაცია მოიცავს Kubernetes-ში ობიექტების შექმნას მანიფესტებისგან.

მძღოლის მუშაობისთვის დაგჭირდებათ შემდეგი:

• მიუთითეთ დირექტორიაში იდენტიფიკატორი manifest-ში (folder-id) Yandex.Cloud (იხილეთ დოკუმენტაცია);
• Yandex.Cloud API-სთან ურთიერთობისთვის, CSI დრაივერი იყენებს სერვისის ანგარიშს. მანიფესტში საიდუმლო უნდა გადაიცეს ავტორიზებული გასაღებები სერვისის ანგარიშიდან. დოკუმენტაციაში აღწერილი, როგორ შევქმნათ სერვისის ანგარიში და მიიღოთ გასაღებები.

Საერთო ჯამში - სცადეთ, და მოხარული ვიქნებით მივიღოთ გამოხმაურება და ახალი საკითხებითუ რაიმე პრობლემა შეგექმნათ!

შემდგომი მხარდაჭერა

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

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

PS

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

• «მოცულობის დანამატები Kubernetes შენახვისთვის: Flexvolume-დან CSI-მდე";
• «ჩვენ გვესმის კონტეინერის შენახვის ინტერფეისი (კუბერნეტში და არა მხოლოდ)";
• «ადვილი და მოსახერხებელია Kubernetes კლასტერის მომზადება? აცხადებენ დანამატის ოპერატორს";
• «Kubernetes-ის გაფართოება და შევსება (მიმოხილვა და ვიდეო ანგარიში)".

წყარო: www.habr.com