K8S მრავალკლასტერული მოგზაურობა

ჰეი ჰაბრ!

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

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

• ჩვენი განვითარების დეპარტამენტი შედგება 100+ ადამიანისგან, მათ შორის 10-ზე მეტი განსხვავებული გუნდი თვითკმარი QA, DevOps და Scrum პროცესებით. განვითარების სტეკი - Python, PHP, C++, Java და Golang. 
• სატესტო და საწარმოო გარემოს ზომა შეადგენს დაახლოებით 2000 კონტეინერს. ისინი აწარმოებენ Rancher v1.6-ს საკუთარ ვირტუალიზაციაზე და VMware-ის ქვეშ. 

მოტივაცია

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

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

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

პირველი ნაბიჯები

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

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

დასაწყისისთვის, კუბეადმი ჩვენთვის ზედმეტად რთულ გზად გვეჩვენებოდა, უფრო მეტად „ველოსიპედის“ გამომგონებლად და კოპებს არ ჰქონდათ საკმარისი მოქნილობა.

და გამარჯვებული იყო:

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

პირველი პრობლემები

Ansible არის ის, რაზეც არის აგებული kubespray, ის არ არის ინსტრუმენტი, რომელიც საშუალებას გაძლევთ მიჰყვეთ IaC-ს: კვანძების გაშვებისას/გამორთვისას რაღაც მუდმივად ხდებოდა არასწორად და საჭირო იყო რაიმე სახის ჩარევა, ხოლო სხვადასხვა OS-ის გამოყენებისას სათამაშო წიგნი სხვაგვარად იქცეოდა. სხვაგვარად. . როდესაც კლასტერში გუნდებისა და კვანძების რაოდენობა იზრდებოდა, ჩვენ დავიწყეთ შევამჩნიეთ, რომ სათამაშო წიგნის დასრულებას უფრო და უფრო მეტი დრო სჭირდებოდა და შედეგად, ჩვენი რეკორდი იყო 3,5 საათი, რაც შეეხება თქვენსას? 🙂

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

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


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

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

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

რა უნდა გავაკეთოთ?

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

ასე რომ, ჩვენ მივიღეთ მეორე:

და შემდეგ მესამე კლასტერი: 

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

სრული კუბერნეტები მოვიდოდნენ! ეს არის ერთგვარი MultiKubernetes, თურმე. 

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

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

ჩვენი კვლევის პირველ ეტაპზე, Rancher Labs-მა უკვე გააკეთა მე-2 ვერსიის პირველი გამოშვება, მაგრამ მიუხედავად იმისა, რომ მისი ამაღლება ძალიან სწრაფად შეიძლებოდა გარე დამოკიდებულების გარეშე კონტეინერის გაშვებით რამდენიმე პარამეტრით ან ოფიციალური HELM ჩარტის გამოყენებით, ის უხეში ჩანდა. ჩვენთვის და ჩვენ არ ვიცოდით, შეგვეძლო დავეყრდნოთ ამ გადაწყვეტილებას, განვითარდება თუ სწრაფად მიტოვებული. კლასტერი = დაწკაპუნების პარადიგმა თავად ინტერფეისში ასევე არ გვერგებოდა და არ გვინდოდა მიბმა RKE-სთან, რადგან ის საკმაოდ ვიწრო ორიენტირებული ინსტრუმენტია. 

Rancher 2.2 ვერსიას უკვე ჰქონდა უფრო ფუნქციონალური გარეგნობა და, წინასთან ერთად, ჰქონდა რამდენიმე საინტერესო ფუნქცია, როგორიცაა ინტეგრაცია ბევრ გარე პროვაიდერთან, უფლებებისა და kubeconfig ფაილების განაწილების ერთი წერტილი, kubectl-ის გაშვება. სურათი თქვენი უფლებებით UI-ში, ჩადგმული სახელების სივრცეები, რომლებიც ცნობილია პროექტებში. 

ასევე იყო საზოგადოება უკვე ჩამოყალიბებული Rancher 2-ის ირგვლივ და მის სამართავად შეიქმნა პროვაიდერი სახელად HashiCorp Terraform, რომელიც დაგვეხმარა ყველაფრის შეკრებაში.

Რა მოხდა

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

gitlab-ci და Terraform-ის გამოყენებით შეიქმნა სისტემა, რომელიც საშუალებას გაძლევთ შექმნათ ნებისმიერი კონფიგურაციის კლასტერი ღრუბლოვან პროვაიდერებში ან ჩვენს საკუთარ ინფრასტრუქტურაში და დააკავშიროთ ისინი Rancher-თან. ეს ყველაფერი კეთდება IaC სტილში, სადაც თითოეული კლასტერი აღწერილია საცავის მიერ და მისი მდგომარეობა არის ვერსია. ამავდროულად, მოდულების უმეტესობა დაკავშირებულია გარე საცავებიდან ისე, რომ რჩება მხოლოდ ცვლადების გადაცემა ან თქვენი მორგებული კონფიგურაციის აღწერა, რაც ხელს უწყობს კოდის გამეორების პროცენტის შემცირებას.

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

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

წყარო: www.habr.com