ადვილი და მოსახერხებელია Kubernetes კლასტერის მომზადება? აცხადებენ დანამატის ოპერატორს

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

რატომ საერთოდ რაიმე დამატება?

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

კლასტერში დამატებითი კომპონენტების საჭიროება გამოვლინდა მოხსენება კოლეგები დრიუშა. მოკლედ, Kubernetes-თან ამ მომენტში სიტუაცია ისეთია, რომ მარტივი "თამაშის გარშემო" ინსტალაციისთვის შეგიძლიათ გაუმკლავდეთ კომპონენტებს გარეთ, დეველოპერებისთვის და ტესტირებისთვის შეგიძლიათ დაამატოთ Ingress, მაგრამ სრული ინსტალაციისთვის, რომლის შესახებაც შეგიძლიათ თქვათ „თქვენი წარმოება მზად არის“, თქვენ უნდა დაამატოთ ათეული სხვადასხვა დანამატი: რაღაც მონიტორინგისთვის, რაღაც ჟურნალისთვის, არ დაივიწყოთ შესვლა და სერტიფიკატის მენეჯერი, შეარჩიეთ კვანძების ჯგუფები, დაამატეთ ქსელის პოლიტიკა, სეზონი. sysctl და pod autoscaler პარამეტრებით...

რა არის მათთან მუშაობის სპეციფიკა?

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

მაშ, იქნებ Ansible საკმარისი იქნება აქ? Შესაძლოა. მაგრამ ზოგადად, სრულფასოვანი დანამატები არ ცხოვრობენ პარამეტრების გარეშე. ეს პარამეტრები შეიძლება განსხვავდებოდეს კლასტერული ვარიანტის მიხედვით (aws, gce, azure, bare-metal, do, ...). ზოგიერთი პარამეტრის წინასწარ განსაზღვრა შეუძლებელია; ისინი უნდა იქნას მიღებული კლასტერიდან. და კლასტერი არ არის სტატიკური: ზოგიერთი პარამეტრისთვის მოგიწევთ ცვლილებების მონიტორინგი. და აქ Ansible უკვე აკლია: გჭირდებათ პროგრამა, რომელიც ცხოვრობს კლასტერში, ე.ი. Kubernetes ოპერატორი.

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

როგორ არის ეს ორგანიზებული addon-ოპერატორში?

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

• დანამატის ინსტალერს უნდა ჰქონდეს მხარდაჭერა შაბლონი და დეკლარაციული კონფიგურაცია. ჩვენ არ ვაკეთებთ ჯადოსნურ სკრიპტებს, რომლებიც დააინსტალირებენ დანამატებს. Addon-ოპერატორი იყენებს Helm-ს დამატებების დასაყენებლად. ინსტალაციისთვის, თქვენ უნდა შექმნათ სქემა და აირჩიოთ მნიშვნელობები, რომლებიც გამოყენებული იქნება კონფიგურაციისთვის.
• პარამეტრები შეიძლება იყოს გენერირება ინსტალაციისას, მათ შეუძლიათ მიიღეთ კლასტერიდანან განახლებების მიღება, კლასტერული რესურსების მონიტორინგი. ეს ოპერაციები შეიძლება განხორციელდეს კაკვების გამოყენებით.
• პარამეტრები შეიძლება იყოს შენახვა კლასტერში. კლასტერში პარამეტრების შესანახად იქმნება ConfigMap/addon-ოპერატორი და Addon-ოპერატორი აკონტროლებს ამ ConfigMap-ში ცვლილებებს. Addon-ოპერატორი ანიჭებს კაუჭებს წვდომას პარამეტრებზე მარტივი კონვენციების გამოყენებით.
• დამატება დამოკიდებულია პარამეტრებზე. თუ პარამეტრები შეიცვალა, მაშინ Addon-ოპერატორი გამოაქვეყნებს Helm სქემას ახალი მნიშვნელობებით. ჩვენ ვუწოდეთ Helm დიაგრამის კომბინაციას, მისთვის მნიშვნელობებს და კაკვებს მოდული (დაწვრილებით იხილეთ ქვემოთ).
• Დადგმა. არ არსებობს ჯადოსნური გამოშვების სკრიპტები. განახლების მექანიზმი ჩვეულებრივი აპლიკაციის მსგავსია - შეაგროვეთ დანამატები და დანამატების ოპერატორები სურათში, მონიშნეთ ისინი და გააფართოვეთ ისინი.
• შედეგის კონტროლი. Addon-ოპერატორს შეუძლია Prometheus-ის მეტრიკის მიწოდება.

რა არის padding addon-ოპერატორში?

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

დანამატების განსახორციელებლად, Addon-ოპერატორი გთავაზობთ რამდენიმე კონცეფციას:

• ჩაფხუტის სქემა გამოიყენება კლასტერში სხვადასხვა პროგრამული უზრუნველყოფის დასაყენებლად - მაგალითად, Prometheus, Grafana, nginx-ingress. თუ საჭირო კომპონენტს აქვს Helm სქემა, მაშინ მისი ინსტალაცია Addon-ოპერატორის გამოყენებით ძალიან მარტივი იქნება.
• ღირებულებების შენახვა. ჩაფხუტის დიაგრამებს, როგორც წესი, აქვთ მრავალი განსხვავებული პარამეტრი, რომელიც შეიძლება შეიცვალოს დროთა განმავლობაში. Addon-ოპერატორი მხარს უჭერს ამ პარამეტრების შენახვას და შეუძლია აკონტროლოს მათი ცვლილებები, რათა ხელახლა დააინსტალიროს Helm სქემა ახალი მნიშვნელობებით.
• კაკვები არის შესრულებადი ფაილები, რომლებსაც Addon-ოპერატორი აწარმოებს მოვლენებზე და რომლებიც წვდებიან მნიშვნელობების მაღაზიაში. ჰუკს შეუძლია აკონტროლოს ცვლილებები კლასტერში და განაახლოს მნიშვნელობები მნიშვნელობების მაღაზიაში. იმათ. კაკვების გამოყენებით, შეგიძლიათ გააკეთოთ აღმოჩენა, რომ შეაგროვოთ მნიშვნელობები კლასტერიდან გაშვებისას ან გრაფიკის მიხედვით, ან შეგიძლიათ გააკეთოთ უწყვეტი აღმოჩენა, შეაგროვოთ მნიშვნელობები კლასტერიდან კლასტერში ცვლილებების საფუძველზე.
• მოდული არის Helm დიაგრამის, ღირებულებების შენახვისა და კაკვების კომბინაცია. მოდულების ჩართვა ან გამორთვა შესაძლებელია. მოდულის გამორთვა ნიშნავს Helm ჩარტების ყველა გამოშვების წაშლას. მოდულებს შეუძლიათ საკუთარი თავის დინამიურად ჩართვა, მაგალითად, თუ ჩართულია მისთვის საჭირო ყველა მოდული ან თუ აღმოჩენამ აღმოაჩინა საჭირო პარამეტრები კაკვებში - ეს კეთდება დამხმარე ჩართული სკრიპტის გამოყენებით.
• გლობალური კაკვები. ეს არის კაკვები "თავისთავად", ისინი არ შედის მოდულებში და აქვთ წვდომა გლობალური ღირებულებების მაღაზიაში, რომლის მნიშვნელობები ხელმისაწვდომია მოდულების ყველა კაკვისთვის.

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

არსებობს ორი სამუშაო სცენარი:

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

დამატება შეიძლება განხორციელდეს როგორც ერთი კაუჭი, ან როგორც ერთი ჩაფხუტი, ან თუნდაც რამდენიმე დამოკიდებული მოდული - ეს დამოკიდებულია კლასტერში ინსტალირებული კომპონენტის სირთულეზე და კონფიგურაციის მოქნილობის სასურველ დონეზე. მაგალითად, საცავში (/მაგალითები) არის sysctl-ტიუნერის დანამატი, რომელიც განხორციელებულია როგორც მარტივი მოდულის სახით კაუჭით და Helm დიაგრამით, ასევე მნიშვნელობების შენახვის გამოყენებით, რაც შესაძლებელს ხდის პარამეტრების დამატებას ConfigMap-ის რედაქტირებით.

განახლებების მიწოდება

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

Addon-ოპერატორის კლასტერში გასაშვებად გჭირდებათ შექმენით სურათი დამატებებით hook და Helm ჩარტის ფაილების სახით, დაამატეთ ბინარული ფაილი addon-operator და ყველაფერი რაც თქვენ გჭირდებათ კაკვებისთვის: bash, kubectl, jq, python და ა.შ. შემდეგ ეს სურათი შეიძლება გადაიტანოს კლასტერში, როგორც ჩვეულებრივი აპლიკაცია და, სავარაუდოდ, მოგინდებათ მონიშვნის ამა თუ იმ სქემის ორგანიზება. თუ კლასტერები ცოტაა, იგივე მიდგომა, რაც აპლიკაციებთან დაკავშირებით შეიძლება იყოს შესაფერისი: ახალი გამოშვება, ახალი ვერსია, გადადით ყველა კლასტერზე და შეასწორეთ Pods-ის გამოსახულება. თუმცა, კლასტერების მნიშვნელოვან რაოდენობაზე გადატანის შემთხვევაში, არხიდან თვითგანახლების კონცეფცია უფრო შესაფერისი იყო ჩვენთვის.

აი, როგორ ვაკეთებთ ამას:

• არხი არსებითად არის იდენტიფიკატორი, რომლის დაყენება შესაძლებელია ნებისმიერზე (მაგალითად, dev/stage/ea/stable).
• არხის სახელი არის სურათის ტეგი. როდესაც არხზე განახლებების გავრცელება გჭირდებათ, ახალი სურათი იკრიბება და არხის სახელით მონიშნულია.
• როდესაც ახალი სურათი გამოჩნდება რეესტრში, Addon-ოპერატორი გადაიტვირთება და ამოქმედდება ახალი სურათით.

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

არხები ეხმარება და ტესტირებაში: თუ არის დამხმარე კლასტერი, შეგიძლიათ მისი კონფიგურაცია არხზე stage და გადაიტანეთ მასში განახლებები არხებზე გადატანამდე ea и stable. თუ არხზე კლასტერთან ერთად ea მოხდა შეცდომა, შეგიძლიათ გადართოთ stable, სანამ ამ კლასტერთან დაკავშირებული პრობლემა გამოძიების პროცესშია. თუ კლასტერი ამოღებულია აქტიური მხარდაჭერიდან, ის გადადის თავის "გაყინულ" არხზე - მაგალითად, freeze-2019-03-20.

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

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

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

დასკვნა

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

დანამატები Addon-ოპერატორისთვის მოდულის ფორმატში (Helm Chart + Hooks) შეიძლება გახდეს საჯაროდ ხელმისაწვდომი. ჩვენ, კომპანია Flant, ვგეგმავთ ზაფხულის განმავლობაში გამოვაქვეყნოთ ჩვენი განვითარება მსგავსი დამატებების სახით. შეუერთდით განვითარებას GitHub-ზე (ჭურვი-ოპერატორი, დანამატის ოპერატორი), შეეცადეთ გააკეთოთ თქვენი საკუთარი დამატება საფუძველზე მაგალითები и დოკუმენტაციადაელოდეთ სიახლეებს Habré-ზე და ჩვენს შესახებ YouTube არხი!

PS

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

• «Kubernetes-ის გაფართოება და შევსება (მიმოხილვა და ვიდეო ანგარიში)";
• «Shell-ოპერატორის წარმოდგენა: Kubernetes-ისთვის ოპერატორების შექმნა ახლახან გამარტივდა".

წყარო: www.habr.com