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

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

რატომ?

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

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

ოპერატორი 15 წუთში

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

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

მარტივი ავტომატიზაცია

მოდით დავწეროთ shell სკრიპტი, რომელიც გადის ყოველ N წამში ერთხელ და ამოწმებს სახელთა სივრცეებს ​​საიდუმლოს არსებობისთვის და თუ საიდუმლო არ არის, მაშინ ის იქმნება. ამ გადაწყვეტის უპირატესობა ის არის, რომ ის ჰგავს ჭურვის სკრიპტს cron-ში - კლასიკური და გასაგები მიდგომა ყველასთვის. მინუსი ის არის, რომ მის გაშვებებს შორის შუალედში შეიძლება შეიქმნას ახალი სახელთა სივრცე და გარკვეული დროის განმავლობაში ის დარჩეს საიდუმლოების გარეშე, რაც გამოიწვევს შეცდომებს პოდების გაშვებაში.

ავტომატიზაცია shell-ოპერატორთან

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

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

#!/bin/bash
if [[ $1 == "--config" ]] ; then
cat <<EOF
{
"onKubernetesEvent": [
  { "kind": "namespace",
    "event":["add"]
  }
]}
EOF
fi

აქ აღწერილია, რომ ჩვენ დაინტერესებული ვართ მოვლენების დამატებით (add) ტიპის ობიექტები namespace.

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

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  # конфигурация
cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "namespace",
  "event":["add"]
}
]}
EOF
else
  # реакция:
  # узнать, какой namespace появился
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  # создать в нём нужный секрет
  kubectl create -n ${createdNamespace} -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
EOF
fi

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

გამოსახულების მომზადება კაუჭით

თუ დააკვირდებით სკრიპტს, ხედავთ, რომ ბრძანებები გამოიყენება kubectl и jq. ეს ნიშნავს, რომ სურათს უნდა ჰქონდეს შემდეგი ნივთები: ჩვენი hook, shell-ოპერატორი, რომელიც მონიტორინგს გაუწევს მოვლენებს და გაუშვებს Hook-ს, და ბრძანებები, რომლებიც გამოიყენება Hook-ის მიერ (kubectl და jq). Hub.docker.com-ს უკვე აქვს მზა სურათი, რომელშიც შეფუთულია shell-operator, kubectl და jq. რჩება მხოლოდ მარტივი კაკლის დამატება Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

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

სირბილი კლასტერში

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

1. იწერს სახელთა სივრცის შექმნის მოვლენებს;
2. ქმნის საიდუმლოს სახელთა სივრცეში, გარდა იმისა, სადაც ის გაშვებულია.

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

YAML-ში საბოლოო აღწერა ასე გამოიყურება:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

თქვენ შეგიძლიათ გაუშვათ აწყობილი სურათი, როგორც მარტივი განლაგება:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

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

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

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

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

ამ საკითხზე კიდევ ერთი ილუსტრაციაა...

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

ფილტრაცია

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

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

მაგალითად, განლაგების ობიექტების ეტიკეტების ცვლილებებზე რეაგირებისთვის, თქვენ უნდა გაფილტროთ ველი labels მინდორს გარეთ metadata. კონფიგურაცია იქნება ასეთი:

cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "deployment",
  "event":["update"],
  "jqFilter": ".metadata.labels"
}
]}
EOF

ეს jqFilter გამოხატულება აქცევს Deployment-ის გრძელ JSON მანიფესტს მოკლე JSON-ად ლეიბლებით:

shell-ოპერატორი გაუშვებს Hook-ს მხოლოდ მაშინ, როდესაც ეს მოკლე JSON შეიცვლება და სხვა თვისებების ცვლილებები იგნორირებული იქნება.

Hook გაშვების კონტექსტი

Hook-ის კონფიგურაცია საშუალებას გაძლევთ მიუთითოთ მოვლენების რამდენიმე ვარიანტი - მაგალითად, 2 ვარიანტი ღონისძიებებისთვის Kubernetes-დან და 2 განრიგი:

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

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

იმის გასარკვევად, თუ რატომ გაუშვა კაკალი, shell-ოპერატორი ქმნის დროებით ფაილს და გადასცემს მისკენ მიმავალ გზას ცვლადში Hook-ში. BINDING_CONTEXT_TYPE. ფაილი შეიცავს Hook-ის გაშვების მიზეზს JSON-ის აღწერას. მაგალითად, ყოველ 10 წუთში კაუჭი იმუშავებს შემდეგი შინაარსით:

[{ "binding": "every 10 min"}]

და ორშაბათს დაიწყება ამით:

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

იყიდება onKubernetesEvent იქნება მეტი JSON ტრიგერები, რადგან იგი შეიცავს ობიექტის აღწერას:

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

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

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH

თქვენ შეგიძლიათ მიიღოთ სხვა ველები ანალოგიურად.

რა არის შემდეგი?

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

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

როგორც თქვენ ალბათ მიხვდებით, shell-ოპერატორი დაწერილია Go-ში და ნაწილდება ღია წყაროს ლიცენზიით (Apache 2.0). ჩვენ მადლობელი ვიქნებით განვითარების ნებისმიერი დახმარებისთვის პროექტი GitHub-ზე: და ვარსკვლავები, და საკითხები, და მოთხოვნების ამოღება.

საიდუმლოების ფარდის მოხსნით, ასევე გაცნობებთ, რომ ჭურვი-ოპერატორია небольшая ჩვენი სისტემის ნაწილი, რომელსაც შეუძლია განაახლოს Kubernetes კლასტერში დაინსტალირებული დანამატები და შეასრულოს სხვადასხვა ავტომატური მოქმედებები. წაიკითხეთ მეტი ამ სისტემის შესახებ განუცხადა სიტყვასიტყვით ორშაბათს 2019 წლის HighLoad++-ზე სანკტ-პეტერბურგში - მალე გამოვაქვეყნებთ ამ მოხსენების ვიდეოს და ტრანსკრიპტს.

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

ადევნეთ თვალყური!

PS

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

• «ოპერატორები Kubernetes-ისთვის: როგორ გავუშვათ სახელმწიფო აპლიკაციები";
• «Kubernetes-ისთვის ოპერატორის დაწერა გოლანგში";
• «წარმოგიდგენთ ახალ დანამატს Grafana-სთვის - Statusmap პანელი";
• «წარმოგიდგენთ loghouse - ღია კოდის სისტემას Kubernetes-ში ჟურნალებთან მუშაობისთვის";
• «ჩვენ ოფიციალურად წარმოგიდგენთ dapp - DevOps პროგრამას CI/CD შენარჩუნებისთვის".

წყარო: www.habr.com