Kubernetes-ის გაფართოება და შევსება (მიმოხილვა და ვიდეო ანგარიში)

8 აპრილს კონფერენციაზე Saint HighLoad++ 2019 წელი, როგორც "DevOps და ოპერაციების" განყოფილების ნაწილი, მიეცა მოხსენება "Kubernetes-ის გაფართოება და შევსება", რომლის შექმნაში მონაწილეობდა Flant კომპანიის სამი თანამშრომელი. მასში ჩვენ ვსაუბრობთ უამრავ სიტუაციაზე, რომლებშიც გვინდოდა Kubernetes-ის შესაძლებლობების გაფართოება და შევსება, მაგრამ მზა და მარტივი გამოსავალი ვერ ვიპოვეთ. ჩვენ გვაქვს საჭირო გადაწყვეტილებები ღია კოდის პროექტების სახით და ეს გამოსვლაც მათ ეძღვნება.

ტრადიციულად, სიამოვნებით წარმოგიდგენთ მოხსენების ვიდეო (50 წუთი, სტატიაზე ბევრად უფრო ინფორმაციული) და ძირითადი რეზიუმე ტექსტის სახით. წადი!

ბირთვი და დამატებები K8-ში

Kubernetes ცვლის ინდუსტრიას და ადმინისტრაციის მიდგომებს, რომლებიც დიდი ხანია ჩამოყალიბდა:

• მადლობა მას აბსტრაქციები, ჩვენ აღარ ვმუშაობთ ისეთი ცნებებით, როგორიცაა კონფიგურაციის დაყენება ან ბრძანების გაშვება (Chef, Ansible...), მაგრამ ვიყენებთ კონტეინერების დაჯგუფებას, სერვისებს და ა.შ.
• ჩვენ შეგვიძლია მოვამზადოთ აპლიკაციები ნიუანსების შესახებ ფიქრის გარეშე კონკრეტული საიტი, რომელზედაც ის ამოქმედდება: შიშველი მეტალი, ერთ-ერთი პროვაიდერის ღრუბელი და ა.შ.
• K8-ებით არასოდეს ყოფილხართ უფრო ხელმისაწვდომი საუკეთესო პრაქტიკა ინფრასტრუქტურის ორგანიზებაზე: სკალირების ტექნიკა, თვითგანკურნება, ხარვეზების ტოლერანტობა და ა.შ.

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

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

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

მეორეს მხრივ, K8s გთავაზობთ დიდ შესაძლებლობებს ხელმისაწვდომი ფუნქციების გაფართოებისთვის, რაც ხელს უწყობს სხვების დახურვას - კონკრეტული - მომხმარებლის საჭიროებები. Kubernetes-ში დამატებები პასუხისმგებელია კლასტერის ადმინისტრატორებზე, რომლებმაც უნდა დააინსტალირონ და დააკონფიგურირონ ყველაფერი, რაც საჭიროა მათი კლასტერის „სწორ ფორმაში“ მისაღებად [მათი კონკრეტული პრობლემების გადასაჭრელად]. რა სახის დამატებებია ეს? მოდით შევხედოთ რამდენიმე მაგალითს.

დანამატების მაგალითები

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

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

სხვა მაგალითები მოიცავს:

• Ingress- კონტროლერები (იხილეთ მათი მიმოხილვა ჩვენი ბოლო სტატია).
• სერტიფიცირებული მენეჯერი:

  

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

  

• მეტრიკა - კიდევ ერთი ილუსტრაცია იმისა, თუ როგორ გამოეყო Kubernetes-მა ინტერფეისი (Metrics API) განხორციელებისგან (მესამე მხარის დანამატები, როგორიცაა Prometheus ადაპტერი, Datadog კლასტერული აგენტი...).
• იყიდება მონიტორინგი და სტატისტიკა, სადაც პრაქტიკაში არა მხოლოდ საჭიროა პრომეთე და გრაფანა, არამედ kube-state-metrics, node-exporter და ა.შ.

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

ავტომატიკა

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

1. არსებობს პირადი (ანუ მოითხოვს შესვლას) რეესტრი აპლიკაციის სურათებით. ვარაუდობენ, რომ თითოეულ პოდს ენიჭება სპეციალური საიდუმლო, რომელიც საშუალებას იძლევა რეესტრში ავთენტიფიკაცია. ჩვენი ამოცანაა უზრუნველვყოთ, რომ ეს საიდუმლო მოიძებნოს სახელთა სივრცეში, რათა პოდებმა შეძლონ სურათების ჩამოტვირთვა. შეიძლება იყოს უამრავი აპლიკაცია (რომელთაგან თითოეულს საიდუმლო სჭირდება) და სასარგებლოა თავად საიდუმლოების რეგულარულად განახლება, ასე რომ, საიდუმლოების ხელით გაყვანის ვარიანტი აღმოფხვრილია. სწორედ აქ მოდის ოპერატორი სამაშველოში: ჩვენ ვქმნით კონტროლერს, რომელიც დაელოდება სახელთა სივრცის გამოჩენას და ამ მოვლენის საფუძველზე დაამატებს საიდუმლოს სახელთა სივრცეში.
2. ნაგულისხმევად აკრძალულია პოდებიდან ინტერნეტში წვდომა. მაგრამ ზოგჯერ შეიძლება საჭირო გახდეს: ლოგიკურია, რომ წვდომის ნებართვის მექანიზმმა იმუშაოს უბრალოდ, სპეციფიკური უნარების მოთხოვნის გარეშე, მაგალითად, სახელთა სივრცეში გარკვეული ეტიკეტის არსებობით. როგორ დაგვეხმარება ოპერატორი აქ? იქმნება კონტროლერი, რომელიც ელოდება ეტიკეტის გამოჩენას სახელთა სივრცეში და ამატებს შესაბამის პოლიტიკას ინტერნეტთან წვდომისთვის.
3. მსგავსი სიტუაცია: დავუშვათ, რომ გვჭირდებოდა გარკვეულის დამატება დაბინდვა, თუ მას აქვს მსგავსი იარლიყი (რაღაც პრეფიქსით). ოპერატორთან ქმედებები აშკარაა...

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

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

როგორ დავწეროთ განცხადება Kubernetes-ისთვის?

ზოგადად, სქემა მარტივია:

მაგრამ შემდეგ გამოდის, რომ:

• Kubernetes API არის საკმაოდ არატრივიალური რამ, რომლის დაუფლებას დიდი დრო სჭირდება;
• პროგრამირება ასევე არ არის ყველასთვის (სასურველ ენად აირჩიეს Go ენა, რადგან მას აქვს სპეციალური ჩარჩო - ოპერატორი SDK);
• ანალოგიური სიტუაციაა თავად ჩარჩოსთან დაკავშირებით.

დედააზრი: კონტროლერის დასაწერად (ოპერატორს) უნდა მნიშვნელოვანი რესურსების დახარჯვა მასალის შესასწავლად. ეს გამართლებული იქნებოდა "დიდი" ოპერატორებისთვის - ვთქვათ, MySQL DBMS-ისთვის. მაგრამ თუ გავიხსენებთ ზემოთ აღწერილ მაგალითებს (საიდუმლოების გამჟღავნება, წვდომა ინტერნეტში...), რაც ასევე გვინდა სწორად გავაკეთოთ, მაშინ მივხვდებით, რომ დახარჯული ძალისხმევა გადაწონის იმ შედეგს, რომელიც ახლა გვჭირდება:

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

Shell-ოპერატორი

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

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

Hook არის Bash სკრიპტი ან ნებისმიერი სხვა შესრულებადი ფაილი, რომელიც იღებს ერთ არგუმენტს --config და პასუხობს JSON-ით. ეს უკანასკნელი განსაზღვრავს, თუ რომელი ობიექტებია მისთვის საინტერესო და რომელ მოვლენებზე (ამ ობიექტებისთვის) უნდა უპასუხოს:

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

პრაქტიკა: 1. დაწერეთ კაუჭი

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

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

როგორი იქნება ლოგიკა? ასევე საკმაოდ მარტივია:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

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

პრაქტიკა: 2. გამოსახულების აწყობა

რჩება მხოლოდ შექმნილი კაკლის გადაცემა ჭურვის ოპერატორს - როგორ გავაკეთოთ ეს? თავად shell-ოპერატორი მოდის როგორც Docker გამოსახულება, ამიტომ ჩვენი ამოცანაა დავამატოთ კაკალი სპეციალურ დირექტორიაში ამ სურათზე:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

რჩება მხოლოდ მისი აწყობა და დაძაბვა:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

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

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

ორი პუნქტია, რომელსაც ყურადღება უნდა მიაქციოთ:

1. ახლად შექმნილი სურათის მითითება;
2. ეს არის სისტემის კომპონენტი, რომელსაც (მინიმუმ) ესაჭიროება უფლებები Kubernetes-ში მოვლენების გამოსაწერად და სახელების სივრცისთვის საიდუმლოების გამოყოფისთვის, ამიტომ ჩვენ ვქმნით ServiceAccount-ს (და წესების კომპლექტს) hook-ისთვის.

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

Shell-ოპერატორის სხვა მახასიათებლები

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

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

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

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

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

და ჭურვის ოპერატორის კიდევ ორი ​​მახასიათებელი:

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

რომ შევაჯამოთ მოხსენების ეს ნაწილი:

დამატებების ინსტალაცია

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

დავიწყეთ Kubernetes-თან მუშაობა რამდენიმე კლასტერით, რომლის ერთადერთი დამატება იყო Ingress. თითოეულ კლასტერში მისი განსხვავებულად დაყენება სჭირდებოდა და ჩვენ გავაკეთეთ რამდენიმე YAML კონფიგურაცია სხვადასხვა გარემოსთვის: შიშველი ლითონი, AWS...

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

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

მოკლედ, ჩვენი შემდგომი გზა და მასთან დაკავშირებული მსჯელობა შემდეგი იყო:

• YAML კონფიგურაციებთან მუშაობისთვის საჭიროა შაბლონის ძრავა (პირველ ეტაპზე ეს მარტივია);
• კლასტერების რაოდენობის მატებასთან ერთად გაჩნდა ავტომატური განახლების საჭიროება (ყველაზე ადრეული გამოსავალი იყო სკრიპტის Git-ში ჩადება, მისი განახლება cron-ის გამოყენებით და გაშვება);
• მსგავსი დამწერლობა იყო საჭირო პრომეთესთვის (install-prometheus.sh), თუმცა, აღსანიშნავია ის ფაქტი, რომ ის მოითხოვს ბევრად მეტ შეყვანის მონაცემებს, ასევე მათ შენახვას (კარგი თვალსაზრისით - ცენტრალიზებული და კლასტერში) და ზოგიერთი მონაცემი (პაროლები) შეიძლება ავტომატურად გენერირებული იყოს:

  

• მზარდი რაოდენობის კლასტერებში რაიმე არასწორი გადატანის რისკი მუდმივად იზრდებოდა, ამიტომ მივხვდით, რომ ინსტალატორები (ანუ ორი დამწერლობა: ინგრესის და პრომეთესთვის) საჭირო იყო დადგმა (რამდენიმე ფილიალი Git-ში, რამდენიმე კრონი მათი განახლებისთვის შესაბამისში: სტაბილური ან სატესტო კლასტერები);
• с kubectl apply რთული გახდა მუშაობა, რადგან არ არის დეკლარაციული და შეუძლია შექმნას მხოლოდ ობიექტები, მაგრამ არ მიიღოს გადაწყვეტილებები მათ სტატუსზე/წაშლა;
• ჩვენ გვაკლდა რამდენიმე ფუნქცია, რომელიც იმ დროს საერთოდ არ გვქონდა განხორციელებული:
  • სრული კონტროლი კლასტერის განახლების შედეგებზე,
  • ზოგიერთი პარამეტრის ავტომატური განსაზღვრა (ინსტალაციის სკრიპტების შეყვანა) მონაცემების საფუძველზე, რომლებიც შეიძლება მიიღოთ კლასტერიდან (აღმოჩენა),
  • მისი ლოგიკური განვითარება უწყვეტი აღმოჩენის სახით.

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

დანამატის ოპერატორი

იგი ეფუძნება უკვე აღნიშნულ შელ-ოპერატორს. მთელი სისტემა ასე გამოიყურება:

შემდეგი ემატება ჭურვის ოპერატორის კაკვებს:

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

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

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

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

ეს სქემა აკმაყოფილებს ყველა მოთხოვნას დანამატების ინსტალაციისთვის, რომლებიც ზემოთ იყო ნათქვამი:

• Helm პასუხისმგებელია შაბლონისა და დეკლარაციულობისთვის.
• ავტომატური განახლების საკითხი მოგვარდა გლობალური კაკლის გამოყენებით, რომელიც რეესტრში მიდის გრაფიკის მიხედვით და, თუ იქ ხედავს სისტემის ახალ სურათს, ავრცელებს მას (ანუ „თვითონ“).
• კლასტერში პარამეტრების შენახვა ხორციელდება გამოყენებით ConfigMap, რომელიც შეიცავს საცავის პირველად მონაცემებს (დატვირთვისას ისინი იტვირთება საცავებში).
• პაროლის გენერირების, აღმოჩენისა და უწყვეტი აღმოჩენის პრობლემები მოგვარდა კაკვების გამოყენებით.
• დადგმა მიიღწევა ტეგების წყალობით, რომლებსაც Docker მხარს უჭერს გარეთ.
• შედეგის მონიტორინგი ხდება მეტრიკის გამოყენებით, რომლითაც შეგვიძლია გავიგოთ სტატუსი.

მთელი ეს სისტემა დანერგილია Go-ში ერთი ბინარის სახით, რომელსაც addon-operator ეწოდება. ეს ხდის დიაგრამას უფრო მარტივს:

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

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

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

ვიდეოები და სლაიდები

ვიდეო სპექტაკლიდან (~50 წუთი):

ანგარიშის პრეზენტაცია:

PS

სხვა მოხსენებები ჩვენს ბლოგზე:

• «მონაცემთა ბაზები და კუბერნეტები"; (დმიტრი სტოლიაროვი; 8 წლის 2018 ნოემბერი HighLoad++-ზე);
• «მონიტორინგი და კუბერნეტები"; (დმიტრი სტოლიაროვი; 28 წლის 2018 მაისი RootConf-ზე);
• «CI/CD საუკეთესო პრაქტიკა Kubernetes-თან და GitLab-თან"; (დმიტრი სტოლიაროვი; 7 წლის 2017 ნოემბერი HighLoad++-ზე);
• «ჩვენი გამოცდილება Kubernetes-თან მცირე პროექტებში"; (დმიტრი სტოლიაროვი; 6 წლის 2017 ივნისი RootConf-ზე).

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

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

წყარო: www.habr.com