ოპერატორები Kubernetes-ისთვის: როგორ გავუშვათ სახელმწიფო აპლიკაციები

სახელმწიფო აპლიკაციების პრობლემა Kubernetes-ში

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

მარტივად რომ ვთქვათ, PHP/Ruby/Python-ში ბექენდის კიდევ ხუთი ასლის გასაშვებად კონტეინერების კლასტერში, საჭიროა მხოლოდ 5-ჯერ დააყენოთ ახალი სერვერი და დააკოპიროთ წყაროები. ვინაიდან წყაროს კოდიც და საწყისი სკრიპტიც სურათზეა, მოქალაქეობის არმქონე აპლიკაციის სკალირება სრულიად ელემენტარული ხდება. როგორც კონტეინერებისა და მიკროსერვისის არქიტექტურის მოყვარულებმა კარგად იციან, სირთულე იწყება სახელმწიფოებრივი აპლიკაციები, ე.ი. მონაცემთა მდგრადობით, როგორიცაა მონაცემთა ბაზები და ქეშები (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). ეს ეხება როგორც პროგრამულ უზრუნველყოფას, რომელიც დამოუკიდებლად ახორციელებს კვორუმის კლასტერს (მაგალითად, Percona XtraDB და Cassandra), ასევე პროგრამულ უზრუნველყოფას, რომელიც მოითხოვს ცალკეული მართვის უტილიტებს (როგორიცაა Redis, MySQL, PostgreSQL...).

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

CoreOS ოპერატორები

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

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

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

როგორ მუშაობენ ოპერატორები

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

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

აქედან გამომდინარე, როგორ მუშაობს ეს ყველაფერი? ოპერატორი არის მენეჯერის დემონი, რომელიც:

1. გამოიწერს ღონისძიება API-ს Kubernetes-ში;
2. მისგან იღებს მონაცემებს სისტემის შესახებ (მის შესახებ ReplicaSets, pods, მომსახურება და ასე შემდეგ.);
3. იღებს მონაცემებს შესახებ მესამე მხარის რესურსები (იხილეთ მაგალითები ქვემოთ);
4. რეაგირებს გარეგნობაზე/ცვლილებებზე მესამე მხარის რესურსები (მაგალითად, ზომის შეცვლა, ვერსიის შეცვლა და ა.შ.);
5. რეაგირებს სისტემის მდგომარეობის ცვლილებებზე (მის შესახებ ReplicaSets, pods, მომსახურება და ასე შემდეგ.);
6. ყველაზე მნიშვნელოვანია:
   1. მოუწოდებს Kubernetes API-ს შექმნას ყველაფერი, რაც მას სჭირდება (ისევ საკუთარი ReplicaSets, pods, მომსახურება...),
   2. ასრულებს რაღაც მაგიას (გამარტივების მიზნით, შეგიძლიათ იფიქროთ, რომ ოპერატორი თავად შედის პოდებში და იძახებს ბრძანებებს, მაგალითად, შეუერთდეს კლასტერს ან განაახლოს მონაცემთა ფორმატი ვერსიის განახლებისას).

სინამდვილეში, როგორც სურათიდან ჩანს, ცალკე აპლიკაცია უბრალოდ ემატება Kubernetes-ს (რეგულარულ განლაგება с ReplicaSet), რომელსაც ოპერატორი ეწოდება. ის ცხოვრობს ჩვეულებრივ ბუდეში (ჩვეულებრივ მხოლოდ ერთში) და, როგორც წესი, მხოლოდ მასზეა პასუხისმგებელი სახელთა სივრცე. ეს ოპერატორის აპლიკაცია ახორციელებს თავის API-ს - თუმცა არა პირდაპირ, არამედ მეშვეობით მესამე მხარის რესურსები კუბერნეტეში.

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

მაგალითი და ა.შ (დეტალებისთვის იხილეთ ქვემოთ):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

მაგალითი Elasticsearch-ისთვის:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

მოთხოვნები ოპერატორებისთვის

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

1. ინსტალაცია უნდა განხორციელდეს ერთჯერადი საშუალებით განლაგება: kubectl შექმნა -f SOME_OPERATOR_URL/deployment.yaml - და არ საჭიროებს დამატებით მოქმედებებს.
2. Kubernetes-ში ოპერატორის დაყენებისას უნდა შეიქმნას ახალი მესამე მხარის ტიპი (ThirdPartyResource). აპლიკაციის ინსტანციების (კლასტერული ინსტანციების) გასაშვებად და მათი შემდგომი მართვისთვის (ვერსიების განახლება, ზომის შეცვლა და ა.შ.), მომხმარებელი გამოიყენებს ამ ტიპს.
3. შეძლებისდაგვარად, თქვენ უნდა გამოიყენოთ კუბერნეტებში ჩაშენებული პრიმიტივები, როგორიცაა მომსახურება и ReplicaSetsგამოიყენოს კარგად გამოცდილი და გასაგები კოდი.
4. მოითხოვს ოპერატორების ჩამორჩენილ თავსებადობას და მომხმარებლის მიერ შექმნილი რესურსების ძველი ვერსიების მხარდაჭერას.
5. თუ ოპერატორი ამოღებულია, თავად აპლიკაციამ უნდა განაგრძოს ფუნქციონირება ცვლილებების გარეშე.
6. მომხმარებლებს უნდა შეეძლოთ აპლიკაციის სასურველი ვერსიის განსაზღვრა და აპლიკაციის ვერსიების განახლებების ორკესტრირება. პროგრამული უზრუნველყოფის განახლებების ნაკლებობა არის ოპერატიული და უსაფრთხოების პრობლემების საერთო წყარო, ამიტომ ოპერატორებმა უნდა დაეხმარონ მომხმარებლებს ამ საკითხში.
7. ოპერატორები უნდა შემოწმდეს ისეთი ხელსაწყოთი, როგორიც არის Chaos Monkey, რომელიც განსაზღვრავს პოტენციურ წარუმატებლობებს პოდებში, კონფიგურაციებში და ქსელში.

etcd ოპერატორი

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

და რადგან etcd ასევე შეიქმნა CoreOS-ში, სავსებით ლოგიკური იყო მისი ოპერატორის პირველი გამოჩენა. როგორ მუშაობს ის? ოპერატორის ლოგიკა და ა.შ განისაზღვრება სამი კომპონენტით:

1. დააკვირდი. ოპერატორი აკონტროლებს კლასტერის მდგომარეობას Kubernetes API-ის გამოყენებით.
2. ანალიზი. პოულობს განსხვავებებს მიმდინარე სტატუსსა და სასურველს შორის (განსაზღვრულია მომხმარებლის კონფიგურაციით).
3. მოქმედება. აგვარებს გამოვლენილ განსხვავებებს etcd და/ან Kubernetes სერვისის API-ების გამოყენებით.

ამ ლოგიკის განსახორციელებლად ოპერატორში მომზადდა ფუნქციები შექმნა/განადგურება (ettd კლასტერის წევრების შექმნა და წაშლა) და პასუხის (კლასტერის წევრების რაოდენობის ცვლილება). მისი მუშაობის სისწორე შემოწმდა ნეტფლიქსისგან Chaos Monkey-ის მსგავსებით შექმნილი უტილიტის გამოყენებით, ე.ი. კლავს etcd pods შემთხვევით.

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

რას ჰგავს ოპერატორთან მუშაობა?

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

etcd ოპერატორის ამჟამინდელი სტატუსი არის ბეტა ვერსია, რომელიც მოითხოვს Kubernetes 1.5.3+ და etcd 3.0+ გასაშვებად. წყაროს კოდი და დოკუმენტაცია (მათ შორის გამოყენების ინსტრუქცია) ხელმისაწვდომია აქ GitHub.

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

სტატუსი და პერსპექტივები

Kubernetes Operators-ის გამოცხადებიდან 5 თვე გავიდა. ოფიციალური CoreOS საცავში ჯერ კიდევ არის მხოლოდ ორი დანერგვა (tdd და Prometheus-ისთვის). ორივე ჯერ არ მიუღწევია თავის სტაბილურ ვერსიას, მაგრამ ვალდებულებები ყოველდღიურად შეინიშნება.

დეველოპერები წარმოადგენენ „მომავალს, რომელშიც მომხმარებლები დააინსტალირებენ Postgres ოპერატორებს, კასანდრას ოპერატორებს ან რედის ოპერატორებს თავიანთ Kubernetes კლასტერებზე და იმუშავებენ ამ აპლიკაციების მასშტაბირებად ერთეულებთან ისე მარტივად, როგორც დღეს არის მოქალაქეობის არმქონე ვებ აპლიკაციების ასლების დაყენება“. Პირველი ოპერატორები მესამე მხარის დეველოპერებისგან მართლაც დაიწყო გამოჩენა:

• Elasticsearch ოპერატორი UPMC Enterprises-ისგან;
• PostgreSQL ოპერატორი Crunchy Data-დან (გამოცხადებული 2017 წლის მარტის ბოლოს);
• Rook ოპერატორი Ceph-ზე დაფუძნებული მონაცემთა შენახვის განაწილებული სისტემის ავტორებისგან (Rook არის ალფა სტატუსში);
• Openstack ოპერატორები SAP CCloud-დან.

უდიდეს ევროპულ უფასო პროგრამული უზრუნველყოფის კონფერენციაზე FOSDEM, რომელიც ჩატარდა 2017 წლის თებერვალში ბრიუსელში, ჯოშ ვუდმა CoreOS-დან გამოაცხადა ოპერატორები მოხსენება (ვიდეო ხელმისაწვდომია ბმულზე!), რამაც ხელი უნდა შეუწყოს ამ კონცეფციის პოპულარობის ზრდას ღია კოდის ფართო საზოგადოებაში.

PS გმადლობთ სტატიით დაინტერესებისთვის! გამოიწერეთ ჩვენი ცენტრი, რათა არ გამოტოვოთ ახალი მასალები და რეცეპტები DevOps-ზე და GNU/Linux სისტემის ადმინისტრირებაზე - ჩვენ მათ რეგულარულად გამოვაქვეყნებთ!

წყარო: www.habr.com