Kubernetes DomClick-ზე: როგორ დავიძინოთ მშვიდად, მართოთ 1000 მიკროსერვისის კლასტერი

მე მქვია ვიქტორ იაგოფაროვი და ვამუშავებ Kubernetes-ის პლატფორმას DomClick-ში, როგორც ტექნიკური განვითარების მენეჯერი Ops (ოპერაციების) გუნდში. მსურს ვისაუბრო ჩვენი Dev <-> Ops პროცესების სტრუქტურაზე, რუსეთში ერთ-ერთი ყველაზე დიდი k8s კლასტერის მუშაობის მახასიათებლებზე, ასევე DevOps/SRE პრაქტიკაზე, რომელსაც ჩვენი გუნდი იყენებს.

ოპერაციების გუნდი

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

ყველას აქვს სხვადასხვა კომპეტენცია: ქსელის დამფუძნებლები, DBA-ები, ELK სტეკის სპეციალისტები, Kubernetes-ის ადმინისტრატორები/დეველოპერები, მონიტორინგი, ვირტუალიზაცია, ტექნიკის სპეციალისტები და ა.შ. ერთი რამ აერთიანებს ყველას - ყველას შეუძლია შეცვალოს ნებისმიერი ჩვენგანი გარკვეულწილად: მაგალითად, შემოიტანეთ ახალი კვანძები k8s კლასტერში, განაახლეთ PostgreSQL, დაწერეთ CI/CD + Ansible მილსადენი, ავტომატიზეთ რამე Python/Bash/Go-ში, დააკავშირეთ აპარატურა. Მონაცემთა ცენტრი. ძლიერი კომპეტენციები ნებისმიერ სფეროში არ გიშლით ხელს შეცვალოთ თქვენი საქმიანობის მიმართულება და დაიწყოთ გაუმჯობესება სხვა სფეროში. მაგალითად, მე შევუერთდი კომპანიას, როგორც PostgreSQL სპეციალისტი და ახლა ჩემი პასუხისმგებლობის მთავარი სფეროა Kubernetes კლასტერები. გუნდში ნებისმიერი სიმაღლე მისასალმებელია და ბერკეტის გრძნობა ძალიან განვითარებულია.

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

გუნდის ინსტრუმენტები

Tools-ის გუნდი მნიშვნელოვან როლს ასრულებს ავტომატიზაციაში. მათი მთავარი ამოცანაა დეველოპერებისთვის მოსახერხებელი გრაფიკული და CLI ინსტრუმენტების შექმნა. მაგალითად, ჩვენი შიდა განვითარების Confer საშუალებას გაძლევთ სიტყვასიტყვით გააფართოვოთ აპლიკაცია Kubernetes-ში მაუსის რამდენიმე დაწკაპუნებით, დააკონფიგურიროთ მისი რესურსები, გასაღებები სარდაფიდან და ა.შ. ადრე იყო Jenkins + Helm 2, მაგრამ მე უნდა შემემუშავებინა საკუთარი ინსტრუმენტი კოპირ-პასტის აღმოსაფხვრელად და პროგრამული უზრუნველყოფის სასიცოცხლო ციკლის ერთგვაროვნების მოტანა.

Ops-ის გუნდი არ წერს მილსადენებს დეველოპერებისთვის, მაგრამ შეუძლია რჩევა მისცეს ნებისმიერ საკითხს თავის წერილში (ზოგიერთ ადამიანს ჯერ კიდევ აქვს Helm 3).

DevOps

რაც შეეხება DevOps-ს, ჩვენ მას ასე ვხედავთ:

დეველოპერის გუნდები წერენ კოდს, ავრცელებენ მას Confer to dev -> qa/stage -> prod. პასუხისმგებლობა იმის უზრუნველსაყოფად, რომ კოდი არ შენელდება და არ შეიცავს შეცდომებს ეკისრება Dev და Ops გუნდებს. დღისით Ops-ის გუნდიდან მორიგე პირმა პირველ რიგში უნდა უპასუხოს ინციდენტს თავისი აპლიკაციით, ხოლო საღამოს და ღამით მორიგე ადმინისტრატორმა (Ops) უნდა გააღვიძოს მორიგე დეველოპერი, თუ იცის ამის შესახებ. დარწმუნებული ვარ, რომ პრობლემა ინფრასტრუქტურაში არ არის. ყველა მეტრიკა და გაფრთხილება მონიტორინგში გამოჩნდება ავტომატურად ან ნახევრად ავტომატურად.

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

დეველოპერები ურჩევენ ადმინისტრატორებს, თუ მათ დახმარება სჭირდებათ ადმინისტრატორის მიკროსერვისის დაწერაში (მაგალითად, Go backend + HTML5), და ადმინისტრატორები ურჩევენ დეველოპერებს ინფრასტრუქტურის ნებისმიერ საკითხზე ან k8-ებთან დაკავშირებულ საკითხებზე.

სხვათა შორის, ჩვენ საერთოდ არ გვაქვს მონოლითი, მხოლოდ მიკროსერვისები. მათი რიცხვი ჯერჯერობით მერყეობს 900-დან 1000-მდე prod k8s კლასტერში, თუ იზომება რიცხვით. განლაგება. წიპწების რაოდენობა მერყეობს 1700-დან 2000-მდე. ამჟამად დაახლოებით 2000 ჯიშია პროდ კლასტერში.

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

Რესურსების მართვა

მონიტორინგი

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

• ზაბქსი. კარგი ძველი მონიტორინგი, რომელიც მიზნად ისახავს პირველ რიგში ინფრასტრუქტურის საერთო მდგომარეობის თვალყურის დევნებას. ის გვეუბნება, როდის კვდება კვანძი დამუშავების, მეხსიერების, დისკების, ქსელის და ა.შ. არაფერი ზებუნებრივი, მაგრამ ჩვენ ასევე გვაქვს აგენტების ცალკეული DaemonSet, რომლის დახმარებით, მაგალითად, ჩვენ ვაკვირდებით DNS-ის მდგომარეობას კლასტერში: ვეძებთ სულელური coredns pods, ვამოწმებთ გარე ჰოსტების ხელმისაწვდომობას. როგორც ჩანს, რატომ უნდა შეგაწუხოთ ეს, მაგრამ დიდი მოცულობის ტრაფიკით, ეს კომპონენტი სერიოზული წარუმატებლობის წერტილია. მე უკვე აღწერილი, როგორ ვიბრძოდი DNS შესრულებასთან კლასტერში.
• პრომეთეს ოპერატორი. სხვადასხვა ექსპორტიორთა ნაკრები დიდ მიმოხილვას იძლევა კლასტერის ყველა კომპონენტის შესახებ. შემდეგი, ჩვენ ამ ყველაფერს ვიზუალურად ვახდენთ Grafana-ს დიდ დაფებზე და ვიყენებთ alertmanager-ს გაფრთხილებისთვის.

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

გუნდის რესურსები კუბში

სანამ მაგალითებს შევეხებით, ღირს იმის ახსნა, თუ როგორ გამოვყოფთ რესურსებს მიკროსერვისები.

იმის გაგება, თუ რომელი გუნდები და რა რაოდენობით იყენებენ მათ რესურსები (პროცესორი, მეხსიერება, ადგილობრივი SSD), თითოეულ ბრძანებას გამოვყოფთ თავისებურად სახელთა სივრცე "კუბში" და შეზღუდოს მისი მაქსიმალური შესაძლებლობები პროცესორის, მეხსიერების და დისკის თვალსაზრისით, მანამდე განიხილა გუნდების საჭიროებები. შესაბამისად, ერთი ბრძანება, ზოგადად, არ დაბლოკავს მთელ კლასტერს განლაგებისთვის, გამოყოფს ათასობით ბირთვს და მეხსიერების ტერაბაიტს. სახელთა სივრცეზე წვდომა ნებადართულია AD (ჩვენ ვიყენებთ RBAC). სახელთა სივრცეები და მათი ლიმიტები ემატება GIT საცავში pull-ის მოთხოვნის მეშვეობით, შემდეგ კი ყველაფერი ავტომატურად გადადის Ansible მილსადენის მეშვეობით.

გუნდში რესურსების განაწილების მაგალითი:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

მოთხოვნები და შეზღუდვები

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

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

ზემოთ მოცემულ სკრინშოტებში ხედავთ, რომ "მოთხოვნილი" პროცესორები შეესაბამება ძაფების რეალურ რაოდენობას და ლიმიტები შეიძლება აღემატებოდეს CPU ძაფების რეალურ რაოდენობას =)

ახლა მოდით დეტალურად გადავხედოთ სახელთა სივრცეს (მე ავირჩიე სახელთა სივრცე kube-system - სისტემის სახელთა სივრცე თავად "კუბის" კომპონენტებისთვის) და ვნახოთ რეალურად გამოყენებული პროცესორის დროისა და მეხსიერების თანაფარდობა მოთხოვნილთან:

აშკარაა, რომ გაცილებით მეტი მეხსიერება და CPU არის რეზერვირებული სისტემის სერვისებისთვის, ვიდრე რეალურად გამოიყენება. kube-სისტემის შემთხვევაში ეს გამართლებულია: მოხდა ისე, რომ nginx ingress კონტროლერი ან nodelocaldns პიკზე მოხვდა CPU-ს და მოიხმარა ბევრი ოპერატიული მეხსიერება, ამიტომ აქ ასეთი რეზერვი გამართლებულია. გარდა ამისა, ბოლო 3 საათის განმავლობაში დიაგრამებს ვერ დავეყრდნობით: სასურველია ვიხილოთ ისტორიული მეტრიკა დიდი ხნის განმავლობაში.

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

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

on ჩახშობა + რესურსების მონიტორინგი, შეგიძლიათ დაწეროთ ერთზე მეტი სტატია, ასე რომ დასვით შეკითხვები კომენტარებში. რამდენიმე სიტყვით, შემიძლია ვთქვა, რომ ასეთი მეტრიკის ავტომატიზაციის ამოცანა ძალიან რთულია და მოითხოვს დიდ დროს და დაბალანსებულ მოქმედებას "ფანჯრის" ფუნქციებით და "CTE" Prometheus / VictoriaMetrics (ეს ტერმინები ბრჭყალებშია, რადგან თითქმის არსებობს მსგავსი არაფერი PromQL-ში და თქვენ უნდა დაყოთ საშინელი მოთხოვნები ტექსტის რამდენიმე ეკრანად და ოპტიმიზაცია მოახდინოთ).

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

მეთოდოლოგიები

კომპანიაში, როგორც ახლაა მოდური, ჩვენ ვიცავთ DevOps- და SRE-პრაქტიკოსი როდესაც კომპანიას აქვს 1000 მიკროსერვისი, დაახლოებით 350 დეველოპერი და 15 ადმინი მთელი ინფრასტრუქტურისთვის, თქვენ უნდა იყოთ „მოდური“: ყველა ამ „ბაზის“ მიღმა არის გადაუდებელი აუცილებლობა ყველაფრისა და ყველას ავტომატიზაციისთვის და ადმინისტრატორები არ უნდა იყვნენ ბოსტნეული. პროცესებში.

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

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

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

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

განხორციელება სერვისის ბადე ახლოს არის და უნდა გაუადვილოს ცხოვრება ყველას, Tools-ის კოლეგები უკვე ახლოს არიან აბსტრაქტული „ჯანმრთელი ადამიანის ისტიოს“ განხორციელებასთან: თითოეული HTTP(ებ)ის მოთხოვნის სასიცოცხლო ციკლი ხილული იქნება მონიტორინგში და ის ყოველთვის შესაძლებელი იქნება იმის გაგება, რომ „რომელ ეტაპზე გაფუჭდა ყველაფერი“ სამსახურებრივ (და არა მხოლოდ) ურთიერთქმედების დროს. გამოიწერეთ სიახლეები DomClick ჰაბიდან. =)

Kubernetes ინფრასტრუქტურის მხარდაჭერა

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

ყველა k8s კლასტერის განახლების პროცესი ასე გამოიყურება:

• მიიღეთ კუბესპრეი Southbridge-დან, გადაამოწმეთ ჩვენი თემით, Merjim.
• ჩვენ ვავრცელებთ განახლებას სტრესი- "კუბი".
• ჩვენ გამოვაქვეყნებთ განახლებას თითო კვანძში (Ansible-ში ეს არის „სერიული: 1“) dev- "კუბი".
• ვაახლებთ გამოშვების შაბათს საღამოს თითო კვანძი.

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

საერთო ჯამში გვაქვს სამი „კუბი“: სტრესი, დევი და პროდ. ვგეგმავთ კიდევ ერთის გაშვებას (ცხელი ლოდინი) პროდ-„კუბი“ მეორე მონაცემთა ცენტრში. სტრესი и dev იცხოვრე „ვირტუალურ მანქანებში“ (oVirt სტრესისთვის და VMWare ღრუბელი Dev-ისთვის). გამოშვების- "კუბი" ცხოვრობს "შიშველ მეტალზე": ეს არის იდენტური კვანძები 32 CPU ძაფით, 64-128 GB მეხსიერებით და 300 GB SSD RAID 10 - სულ 50 მათგანია. სამი "თხელი" კვანძი ეძღვნება "ოსტატებს" გამოშვების- "კუბა": 16 GB მეხსიერება, 12 CPU ძაფი.

გასაყიდად, ჩვენ ურჩევნიათ გამოვიყენოთ "შიშველი ლითონი" და თავიდან ავიცილოთ არასაჭირო ფენები, როგორიცაა OpenStack: ჩვენ არ გვჭირდება "ხმაურიანი მეზობლები" და CPU დროის მოპარვა. და ადმინისტრირების სირთულე დაახლოებით ორმაგდება შიდა OpenStack-ის შემთხვევაში.

CI/CD „Cubic“ და სხვა ინფრასტრუქტურული კომპონენტებისთვის ჩვენ ვიყენებთ ცალკე GIT სერვერს, Helm 3 (ეს იყო საკმაოდ მტკივნეული გადასვლა Helm 2-დან, მაგრამ ჩვენ ძალიან კმაყოფილი ვართ პარამეტრებით. ატომური), ჯენკინსი, ანსიბლი და დოკერი. ჩვენ გვიყვარს ფუნქციების ფილიალები და განლაგება სხვადასხვა გარემოში ერთი საცავიდან.

დასკვნა

ზოგადად, ასე გამოიყურება DevOps პროცესი DomClick-ზე ოპერაციების ინჟინრის პერსპექტივიდან. სტატია იმაზე ნაკლებად ტექნიკური აღმოჩნდა, ვიდრე ველოდი: ამიტომ, მიჰყევით DomClick-ის ამბებს Habré-ზე: იქნება მეტი „მყარი“ სტატია Kubernetes-ის შესახებ და სხვა.

წყარო: www.habr.com