წავიდეთ? ბაშ! შეხვდით shell-ოპერატორს (მიმოხილვა და ვიდეო ანგარიში KubeCon EU'2020-დან)

წელს, მთავარი ევროპული Kubernetes კონფერენცია - KubeCon + CloudNativeCon Europe 2020 - ვირტუალური იყო. თუმცა, ფორმატის ასეთმა ცვლილებამ ხელი არ შეგვიშალა ჩვენი დიდი ხნის დაგეგმილი მოხსენების „წადი? ბაშ! გაიცანით Shell-ოპერატორი“ რომელიც ეძღვნება ჩვენს ღია კოდის პროექტს ჭურვი-ოპერატორი.

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

გაცნობა მოხსენების ვიდეო (~ 23 წუთი ინგლისურად, შესამჩნევად უფრო ინფორმაციული ვიდრე სტატია) და მისგან მთავარი ამონაწერი ტექსტის სახით. წადი!

Flant-ში ჩვენ მუდმივად ვახორციელებთ ყველაფრის ოპტიმიზაციას და ავტომატიზაციას. დღეს კიდევ ერთ საინტერესო კონცეფციაზე ვისაუბრებთ. Შეხვედრა: ღრუბლოვანი ჭურვის სკრიპტირება!

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

Kubernetes API და კონტროლერები

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

• მიიღეთ რესურსი თავისი სახისა და დასახელების მიხედვით;
• შეცვლა რესურსი (ამ შემთხვევაში, სერვერი ინახავს მხოლოდ „სწორ“ ობიექტებს - ყველა არასწორად ჩამოყალიბებული ან სხვა დირექტორიებისთვის განკუთვნილი ყველა უგულებელყოფილია);
• თვალყური ადევნეთ რესურსისთვის (ამ შემთხვევაში მომხმარებელი დაუყოვნებლივ იღებს მის მიმდინარე/განახლებულ ვერსიას).

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

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

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

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

• განლაგების კონტროლერი (შედის kube-controller-manager) იღებს ინფორმაციას განლაგების შესახებ და ქმნის ReplicaSet-ს.
• ReplicaSet ამ ინფორმაციის საფუძველზე ქმნის ორ რეპლიკას (ორ პოდს), მაგრამ ეს პოდი ჯერ არ არის დაგეგმილი.
• დამგეგმავი აწყობს პოდებს და ამატებს კვანძების ინფორმაციას მათ YAML-ებში.
• Kubelets ცვლის გარე რესურსს (ვთქვათ Docker).

შემდეგ მთელი ეს თანმიმდევრობა მეორდება საპირისპირო თანმიმდევრობით: კუბელეტი ამოწმებს კონტეინერებს, ითვლის პოდის სტატუსს და აგზავნის უკან. ReplicaSet კონტროლერი იღებს სტატუსს და განაახლებს რეპლიკა ნაკრების მდგომარეობას. იგივე ხდება Deployment Controller-თან დაკავშირებით და მომხმარებელი საბოლოოდ იღებს განახლებულ (მიმდინარე) სტატუსს.

Shell-ოპერატორი

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

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

მოდით შევხედოთ მარტივ მაგალითს.

ვთქვათ, გვაქვს კუბერნეტის კლასტერი. მას აქვს სახელთა სივრცე default რაღაც საიდუმლოებით mysecret. გარდა ამისა, კლასტერში არის სხვა სახელთა სივრცეები. ზოგიერთ მათგანს სპეციალური ეტიკეტი აქვს მიმაგრებული. ჩვენი მიზანია დავაკოპიროთ Secret სახელთა სივრცეში ლეიბლით.

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

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

როგორ მუშაობს shell-ოპერატორი

Kubernetes-ის სხვა დატვირთვების მსგავსად, shell-ოპერატორი მუშაობს საკუთარ პოდში. ამ პოდში დირექტორიაში /hooks შესრულებადი ფაილები ინახება. ეს შეიძლება იყოს სკრიპტები Bash, Python, Ruby და ა.შ. ასეთ შესრულებად ფაილებს ჩვენ ვუწოდებთ ჰუკებს (კაკვები).

Shell-ოპერატორი გამოიწერს Kubernetes-ის მოვლენებს და აწარმოებს ამ კაკვებს იმ მოვლენების საპასუხოდ, რაც ჩვენ გვჭირდება.

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

ოპერატორის დამზადება ბაშში

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

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

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

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

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

გამოიწერეთ საიდუმლო წყარო

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

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

შედეგად, კაკალი ამოქმედდება, როდესაც წყაროს საიდუმლო შეიცვლება (src_secret) და მიიღეთ შემდეგი სავალდებულო კონტექსტი:

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

სახელთა სივრცის თვალყურის დევნება

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

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

როგორც ხედავთ, კონფიგურაციაში გამოჩნდა ახალი ველი სახელწოდებით jqფილტრი. როგორც მისი სახელი გვთავაზობს, jqFilter ფილტრავს ყველა არასაჭირო ინფორმაციას და ქმნის ახალ JSON ობიექტს ჩვენთვის საინტერესო ველებით. მსგავსი კონფიგურაციის მქონე ჰუკი მიიღებს შემდეგ სავალდებულო კონტექსტს:

ის შეიცავს მასივს filterResults კლასტერში თითოეული სახელთა სივრცისთვის. ლოგიკური ცვლადი hasLabel მიუთითებს, არის თუ არა ეტიკეტი მიმაგრებული მოცემულ სახელთა სივრცეზე. სელექტორი keepFullObjectsInMemory: false მიუთითებს, რომ არ არის საჭირო სრული ობიექტების მეხსიერებაში შენახვა.

სამიზნე საიდუმლოების თვალყურის დევნება

ჩვენ ვიწერთ ყველა საიდუმლოებას, რომელსაც აქვს მითითებული ანოტაცია managed-secret: "yes" (ეს არის ჩვენი სამიზნე dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

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

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

ყველა ამ ინფორმაციის საფუძველზე შეიძლება შემუშავდეს ძირითადი ალგორითმი. ის იმეორებს ყველა სახელთა სივრცეს და:

• თუ hasLabel საკითხები true მიმდინარე სახელთა სივრცისთვის:
  • ადარებს გლობალურ საიდუმლოს ადგილობრივს:
    • თუ ისინი იგივეა, ეს არაფერს აკეთებს;
    • თუ ისინი განსხვავდებიან - ახორციელებს kubectl replace ან create;
• თუ hasLabel საკითხები false მიმდინარე სახელთა სივრცისთვის:
  • დარწმუნდით, რომ საიდუმლო არ არის მოცემულ სახელთა სივრცეში:
    • თუ ადგილობრივი საიდუმლო არსებობს, წაშალეთ იგი გამოყენებით kubectl delete;
    • თუ ადგილობრივი საიდუმლო არ არის აღმოჩენილი, ის არაფერს აკეთებს.

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

სწორედ ასე შევძელით შეგვექმნა მარტივი Kubernetes კონტროლერი YAML კონფიგურაციის 35 ხაზის და დაახლოებით იგივე რაოდენობის Bash კოდის გამოყენებით! Shell-ოპერატორის ამოცანაა მათი ერთმანეთთან დაკავშირება.

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

მაგალითი 1: ცვლილებების შეტანა ConfigMap-ში

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

ახლა დავუშვათ, რომ ConfigMap შეიცვალა (v.2). თუმცა, pods გამოიყენებს ConfigMap-ის წინა ვერსიას (v.1):

როგორ მივიყვანო ახალ ConfigMap-ზე (v.2) გადართვა? პასუხი მარტივია: გამოიყენეთ შაბლონი. მოდით დავამატოთ საკონტროლო ჯამის ანოტაცია განყოფილებაში template განლაგების კონფიგურაციები:

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

თუ მომხმარებელი შეიტანს ცვლილებებს ConfigMap-ში, shell-ოპერატორი შეამჩნევს მათ და ხელახლა გამოთვლის საკონტროლო ჯამს. რის შემდეგაც კუბერნეტესის ჯადოსნობა ამოქმედდება: ორკესტრი მოკლავს პოდს, შექმნის ახალს, დაელოდება მის გაქცევას. Ready, და გადადის შემდეგზე. შედეგად, Deployment სინქრონიზდება და გადაერთვება ConfigMap-ის ახალ ვერსიაზე.

მაგალითი 2: მუშაობა მორგებული რესურსების განმარტებებთან

მოგეხსენებათ, Kubernetes გაძლევთ საშუალებას შექმნათ ობიექტების ინდივიდუალური ტიპები. მაგალითად, შეგიძლიათ შექმნათ სახის MysqlDatabase. ვთქვათ, ამ ტიპს აქვს ორი მეტამონაცემების პარამეტრი: name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

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

მაგალითი 3: კლასტერული ქსელის მონიტორინგი

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

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

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

პარამეტრის executeHookOnEvent: [] ხელს უშლის კაუჭის გაშვებას ნებისმიერი მოვლენის საპასუხოდ (ანუ კვანძების შეცვლის, დამატების, წაშლის საპასუხოდ). თუმცა, ის გაიქცევა (და განაახლეთ კვანძების სია) დაგეგმილი - ყოველ წუთს, როგორც ამას ველი ითვალისწინებს schedule.

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

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

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

აქ ასე თქვენ შეგიძლიათ შექმნათ ოპერატორი მარტივი ქსელის მონიტორინგისთვის კლასტერში.

რიგის მექანიზმი

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

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

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

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

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

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

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

დასკვნა

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

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

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

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

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

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

PS

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

• «Kubernetes-ის ოპერატორების მარტივი შექმნა shell-ოპერატორთან: პროექტის პროგრესი წლის განმავლობაში";
• «Shell-ოპერატორის წარმოდგენა: Kubernetes-ისთვის ოპერატორების შექმნა ახლახან გამარტივდა";
• «ადვილი და მოსახერხებელია Kubernetes კლასტერის მომზადება? აცხადებენ დანამატის ოპერატორს";
• «Kubernetes-ის გაფართოება და შევსება" (მიმოხილვა და ვიდეო ანგარიში).

წყარო: www.habr.com