🥇Kubernetes-in genişləndirilməsi və əlavə edilməsi (baxış və video hesabat)

8 aprel konfransda Saint HighLoad++ 2019, "DevOps və Əməliyyatlar" bölməsinin bir hissəsi olaraq, Flant şirkətinin üç əməkdaşının iştirak etdiyi "Kubernetes-in genişləndirilməsi və tamamlanması" hesabatı verildi. Orada Kubernetes-in imkanlarını genişləndirmək və tamamlamaq istədiyimiz, lakin hazır və sadə bir həll tapmadığımız çoxsaylı vəziyyətlərdən danışırıq. Açıq Mənbə layihələri şəklində lazımi həllərimiz var və bu çıxış da onlara həsr olunub.

Ənənəyə uyğun olaraq təqdim etməkdən məmnunuq məruzə ilə video (50 dəqiqə, məqalədən daha çox məlumatlandırıcı) və mətn şəklində əsas xülasə. Get!

K8-lərdə əsas və əlavələr

Kubernetes sənayeni və çoxdan qurulmuş idarəetmə yanaşmalarını dəyişdirir:

Onun sayəsində abstraksiyalar, biz artıq konfiqurasiyanın qurulması və ya əmrin icrası (Chef, Ansible...) kimi anlayışlarla işləmirik, lakin konteynerlərin, xidmətlərin və s. qruplaşdırılmasından istifadə edirik.
Nüansları düşünmədən ərizə hazırlaya bilərik xüsusi sayt, onun işə salınacağı: çılpaq metal, provayderlərdən birinin buludu və s.
K8s ilə heç vaxt daha əlçatan olmamısınız ən yaxşı təcrübələr infrastrukturun təşkili üzrə: miqyaslaşdırma üsulları, özünü sağaltma, nasazlığa dözümlülük və s.

Bununla belə, əlbəttə ki, hər şey o qədər də hamar deyil: Kubernetes də öz yeni çağırışlarını gətirdi.

Kubernetes heç bir bütün istifadəçilərin bütün problemlərini həll edən kombindir. Kernel Kubernetes yalnız mövcud olan minimum zəruri funksiyalar dəstinə cavabdehdir hər biri klaster:

Kubernetes nüvəsi konteynerləri qruplaşdırmaq, trafiki idarə etmək və s. üçün primitivlərin əsas dəstini müəyyən edir. Onlar haqqında daha ətraflı danışdıq 2 il əvvəl hesabat.

Digər tərəfdən, K8s başqalarını bağlamağa kömək edən mövcud funksiyaları genişləndirmək üçün böyük imkanlar təklif edir - spesifik - istifadəçi ehtiyacları. Kubernetes-ə əlavələr klaster inzibatçılarının məsuliyyətidir, onlar klasterlərini “düzgün formada” [öz xüsusi problemlərini həll etmək üçün] lazım olan hər şeyi quraşdırmalı və konfiqurasiya etməlidirlər. Bunlar hansı əlavələrdir? Gəlin bəzi nümunələrə baxaq.

Əlavələrin nümunələri

Kubernetes-i quraşdırdıqdan sonra, həm qovşaq daxilində, həm də qovşaqlar arasında podların qarşılıqlı əlaqəsi üçün çox zəruri olan şəbəkənin öz-özünə işləməməsinə təəccüblənə bilərik. Kubernetes nüvəsi lazımi əlaqələrə zəmanət vermir, əksinə şəbəkəni müəyyənləşdirir interfeys (CNI) üçüncü tərəf əlavələri üçün. Şəbəkə konfiqurasiyasına cavabdeh olacaq bu əlavələrdən birini quraşdırmalıyıq.

Yaxın bir nümunə məlumat saxlama həlləridir (lokal disk, şəbəkə bloku cihazı, Ceph...). Əvvəlcə onlar nüvədə idilər, lakin gəlişi ilə CSI vəziyyət artıq təsvir edilənə bənzər bir şeyə dəyişir: interfeys Kubernetes-də və onun həyata keçirilməsi üçüncü tərəf modullarındadır.

Digər nümunələrə aşağıdakılar daxildir:

Girme-nəzarətçilər (onların rəyinə baxın son məqaləmiz).
sertifikat meneceri:
Operatorlar bütöv bir sinif əlavələrdir (buraya qeyd olunan sertifikat meneceri daxildir), onlar primitiv(lər) və nəzarətçi(lər)i müəyyən edirlər. Onların işinin məntiqi yalnız təxəyyülümüzlə məhdudlaşır və bizə hazır infrastruktur komponentlərini (məsələn, DBMS) işləmək daha asan olan primitivlərə çevirməyə imkan verir (bir sıra konteynerlər və onların parametrləri ilə müqayisədə). Çox sayda operator yazılmışdır - onların bir çoxu hələ istehsala hazır olmasa da, bu, yalnız vaxt məsələsidir:
Metriklər - Kubernetesin interfeysi (Metrics API) icradan necə ayırdığını göstərən başqa bir təsvir (Prometheus adapteri, Datadog klaster agenti kimi üçüncü tərəf əlavələri...).
Uğrunda monitorinq və statistika, burada praktikada yalnız lazım deyil Prometey və Qrafana, həm də kube-state-metrics, node-exporter və s.

Və bu əlavələrin tam siyahısı deyil... Məsələn, hazırda quraşdırdığımız Flant şirkətində 29 əlavələr (hamısı cəmi 249 Kubernetes obyekti yaradır). Sadə dillə desək, biz əlavələr olmadan bir klasterin həyatını görə bilmərik.

Avtomatlaşdırma

Operatorlar hər gün qarşılaşdığımız rutin əməliyyatları avtomatlaşdırmaq üçün nəzərdə tutulub. Operator yazmağın əla həll olacağı real həyat nümunələri:

Tətbiq üçün şəkilləri olan şəxsi (yəni giriş tələb edən) reyestr var. Güman edilir ki, hər bir pod reyestrdə autentifikasiyaya imkan verən xüsusi sirr verilir. Bizim vəzifəmiz podların şəkilləri endirə bilməsi üçün bu sirrin ad məkanında tapılmasını təmin etməkdir. Çox sayda proqram ola bilər (hər birinə sirr lazımdır) və sirləri mütəmadi olaraq yeniləmək faydalıdır, buna görə sirləri əl ilə qoymaq seçimi aradan qaldırılır. Burada operator köməyə gəlir: biz ad sahəsinin görünməsini gözləyəcək və bu hadisəyə əsaslanaraq ad sahəsinə sirr əlavə edəcək bir nəzarətçi yaradırıq.
Defolt olaraq podlardan İnternetə giriş qadağandır. Ancaq bəzən tələb oluna bilər: giriş icazəsi mexanizminin xüsusi bacarıq tələb etmədən, məsələn, ad məkanında müəyyən etiketin olması ilə sadəcə işləməsi məntiqlidir. Operator burada bizə necə kömək edə bilər? Etiketin ad məkanında görünməsini gözləyən və İnternetə giriş üçün müvafiq siyasəti əlavə edən nəzarətçi yaradılır.
Bənzər bir vəziyyət: güman edək ki, müəyyən bir əlavə etməliyik ləkə, əgər onun oxşar etiketi varsa (bir növ prefikslə). Operatorla hərəkətlər göz qabağındadır...

İstənilən klasterdə rutin vəzifələr həll edilməlidir və doğru bu operatorlardan istifadə etməklə edilə bilər.

Təsvir edilən bütün hekayələri yekunlaşdıraraq belə bir nəticəyə gəldik ki Kubernetesdə rahat iş üçün sizə lazımdır: A) əlavələri quraşdırın, b) operatorları inkişaf etdirmək (gündəlik admin tapşırıqlarını həll etmək üçün).

Kubernetes üçün necə bir bəyanat yazmaq olar?

Ümumiyyətlə, sxem sadədir:

... amma sonra belə çıxır:

Kubernetes API mənimsəmək üçün çox vaxt tələb edən olduqca qeyri-ciddi bir şeydir;
proqramlaşdırma da hər kəs üçün deyil (Go dili üstünlük verilən dil kimi seçildi, çünki bunun üçün xüsusi çərçivə var - Operator SDK);
Çərçivənin özü ilə də vəziyyət oxşardır.

Alt line: nəzarətçi yazmaq (operator) məcburidir əhəmiyyətli resurslar sərf edirlər material öyrənmək. Bu, "böyük" operatorlar üçün, məsələn, MySQL DBMS üçün haqlı olardı. Ancaq yuxarıda təsvir olunan nümunələri (sirləri açmaq, İnternetə daxil olmaq ...) xatırlasaq, bunu da düzgün yerinə yetirmək istəyirik, onda başa düşəcəyik ki, sərf olunan zəhmət indi bizə lazım olan nəticədən daha çox olacaq:

Ümumiyyətlə, dilemma yaranır: çoxlu resurs xərcləyin və bəyanatlar yazmaq üçün düzgün alət tapın və ya bunu köhnə üsulla edin (lakin tez). Bunu həll etmək üçün - bu ifratlar arasında kompromis tapmaq üçün - öz layihəmizi yaratdıq: mərmi operatoru (həmçinin bax son elan mərkəzdə).

Shell-operator

O necə işləyir? Klasterdə shell-operatoru olan Go binarını ehtiva edən pod var. Yanında bir dəst var qarmaqlar (onlar haqqında ətraflı məlumat - aşağıya baxın). Shell-operator özü müəyyən abunə olur inkişaf Kubernetes API-də, baş verdikdə müvafiq qarmaqları işə salır.

Shell-operator hansı hadisələrə hansı qarmaqları çağıracağını necə bilir? Bu məlumat mərmi operatoruna qarmaqların özləri tərəfindən ötürülür və onlar bunu çox sadə edirlər.

Qarmaq Bash skripti və ya tək bir arqumenti qəbul edən hər hansı digər icra edilə bilən fayldır --config və JSON ilə cavab verir. Sonuncu, hansı obyektlərin onun üçün maraqlı olduğunu və hansı hadisələrə (bu obyektlər üçün) cavab verilməli olduğunu müəyyənləşdirir:

Nümunələrimizdən birinin shell-operatorunda tətbiqini təsvir edəcəyəm - tətbiq şəkilləri ilə şəxsi reyestrə daxil olmaq üçün sirlərin parçalanması. İki mərhələdən ibarətdir.

Təcrübə: 1. Qarmaq yazın

Əvvəlcə çəngəldə emal edəcəyik --config, ad boşluqları və xüsusilə onların yaradılma anları ilə maraqlandığımızı göstərir:

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

Məntiq necə görünəcək? Həm də olduqca sadə:

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

Birinci addım hansı ad sahəsinin yaradıldığını öyrənmək, ikincisi isə onu istifadə edərək yaratmaqdır kubectl bu ad sahəsinin sirri.

Təcrübə: 2. Təsvirin yığılması

Yaradılmış qarmağı mərmi operatoruna ötürmək qalır - bunu necə etmək olar? Shell-operator özü Docker təsviri kimi gəlir, ona görə də bizim vəzifəmiz bu şəkildəki xüsusi qovluğa qarmaq əlavə etməkdir:

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

Qalan yalnız onu yığmaq və itələməkdir:

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

Son toxunuş, təsviri klasterə yerləşdirməkdir. Bunun üçün yazaq Deployment:

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

Diqqət edilməli iki məqam var:

yeni yaradılmış təsvirin göstəricisi;
Bu, (ən azı) Kubernetes-dəki hadisələrə abunə olmaq və ad boşluqlarına sirrlər ayırmaq hüquqlarını tələb edən sistem komponentidir, ona görə də biz qarmaq üçün ServiceAccount (və bir sıra qaydalar) yaradırıq.

Nəticə - problemimizi həll etdik qohumlar Kubernetes üçün sirləri parçalamaq üçün operator yaradan bir şəkildə.

Digər shell-operator xüsusiyyətləri

Qarmağın işləyəcəyi seçdiyiniz tipli obyektləri məhdudlaşdırmaq üçün, süzülə bilərlər, müəyyən etiketlərə görə seçmək (və ya istifadə edərək matchExpressions):

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

Təmin edilmişdir deduplikasiya mexanizmijq filtrindən istifadə edərək, böyük JSON obyektlərini kiçik obyektlərə çevirməyə imkan verir, burada yalnız dəyişiklikləri izləmək istədiyimiz parametrlər qalır.

Bir çəngəl çağırıldıqda, shell-operator onu keçir obyekt məlumatları, istənilən ehtiyac üçün istifadə edilə bilər.

Qarmaqları tetikleyen hadisələr Kubernetes hadisələri ilə məhdudlaşmır: qabıq operatoru dəstək verir zaman qarmaqları çağırır (ənənəvi planlaşdırıcıda crontab-a bənzəyir), həmçinin xüsusi bir hadisə onStartup. Bütün bu hadisələr birləşdirilə və eyni çəngəl üçün təyin edilə bilər.

Və shell-operatorun daha iki xüsusiyyəti:

Bu işləyir asinxron. Kubernetes hadisəsi (məsələn, yaradılan obyekt) qəbul edildiyi üçün klasterdə digər hadisələr (məsələn, silinən eyni obyekt) baş verə bilər və qarmaqlar bunu hesablamalıdır. Əgər çəngəl xəta ilə icra olunubsa, deməli, standart olaraq belə olacaq yenidən zəng edin uğurla başa çatana qədər (bu davranış dəyişdirilə bilər).
İxrac edir ölçülər shell-operatorun işlədiyini başa düşə biləcəyiniz Prometheus üçün hər bir çəngəl üçün səhvlərin sayını və cari növbə ölçüsünü öyrənin.

Hesabatın bu hissəsini ümumiləşdirmək üçün:

Eklentileri quraşdırın

Kubernetes ilə rahat işləmək üçün əlavələrin quraşdırılması zərurəti də qeyd edildi. Bu barədə şirkətimizin indi bunu necə etdiyimiz nümunəsindən istifadə edərək sizə danışacağam.

Kubernetes ilə bir neçə klasterlə işləməyə başladıq, bunlara yeganə əlavə Ingress idi. Onu hər klasterdə fərqli quraşdırmaq lazım idi və biz müxtəlif mühitlər üçün bir neçə YAML konfiqurasiyası etdik: çılpaq metal, AWS...

Daha çox klaster olduğu üçün daha çox konfiqurasiya var idi. Bundan əlavə, biz bu konfiqurasiyaları özləri yaxşılaşdırdıq, nəticədə onlar olduqca heterojen oldular:

Hər şeyi qaydasına salmaq üçün bir ssenari ilə başladıq (install-ingress.sh), yerləşdirəcəyimiz klaster növünü arqument kimi götürərək, lazımi YAML konfiqurasiyasını yaratdı və Kubernetes-ə yaydı.

Qısacası, bundan sonrakı yolumuz və onunla bağlı əsaslandırmamız belə idi:

YAML konfiqurasiyaları ilə işləmək üçün şablon mühərriki tələb olunur (ilk mərhələdə bu sadədir);
klasterlərin sayının artması ilə avtomatik yeniləmə ehtiyacı yarandı (ən erkən həll skripti Git-ə yerləşdirmək, cron vasitəsilə yeniləmək və işə salmaq idi);
Prometey üçün də oxşar ssenari tələb olunurdu (install-prometheus.sh), lakin daha çox giriş məlumatı tələb etməsi, həmçinin onların saxlanması (yaxşı mənada - mərkəzləşdirilmiş və çoxluqda) və bəzi məlumatların (parolların) avtomatik olaraq yaradıla bilməsi ilə diqqət çəkir:
artan sayda klaster üçün səhv bir şeyin yayılması riski daim artır, ona görə də biz başa düşdük ki, quraşdırıcılar (yəni iki skript: Ingress və Prometey üçün) səhnələşdirmə tələb olundu (Git-də bir neçə filial, onları müvafiq olaraq yeniləmək üçün bir neçə cron: sabit və ya test klasterləri);
с kubectl apply onunla işləmək çətinləşdi, çünki deklarativ deyil və yalnız obyektlər yarada bilər, lakin onların statusu haqqında qərar qəbul edə bilməz / onları silə bilməz;
Biz o vaxt heç həyata keçirmədiyimiz bəzi funksiyalardan məhrum idik:
- klaster yeniləmələrinin nəticələrinə tam nəzarət,
- klasterdən əldə edilə bilən məlumatlar əsasında bəzi parametrlərin (quraşdırma skriptləri üçün giriş) avtomatik müəyyən edilməsi (kəşf),
- onun davamlı kəşf şəklində məntiqi inkişafı.

Bütün bu toplanmış təcrübəmizi digər layihəmiz çərçivəsində həyata keçirdik - addon-operator.

Addon-operator

Artıq qeyd olunan shell-operatora əsaslanır. Bütün sistem belə görünür:

Qabıq-operator qarmaqlarına aşağıdakılar əlavə olunur:

dəyərlərin saxlanması,
Sükan diaqramı,
komponenti dəyərlər anbarına nəzarət edir və - hər hansı bir dəyişiklik olarsa - Helm-dən diaqramı yenidən yuvarlamağı xahiş edir.

Beləliklə, biz Kubernetes-də baş verən hadisəyə reaksiya verə, çəngəl işə sala bilərik və bu qarmaqdan yaddaşa dəyişikliklər edə bilərik, bundan sonra diaqram yenidən yüklənəcək. Yaranan diaqramda biz qarmaqlar dəstini və diaqramı adlandırdığımız bir komponentə ayırırıq modul:

Bir çox modul ola bilər və onlara qlobal qarmaqlar, qlobal dəyərlər mağazası və bu qlobal mağazanı izləyən komponent əlavə edirik.

İndi Kubernetes-də nəsə baş verəndə qlobal çəngəldən istifadə edərək buna reaksiya verə və qlobal mağazada nəyisə dəyişə bilərik. Bu dəyişiklik nəzərə alınacaq və klasterdəki bütün modulların yayılmasına səbəb olacaq:

Bu sxem yuxarıda göstərilən əlavələrin quraşdırılması üçün bütün tələblərə cavab verir:

Helm şablon və deklarativliyə görə məsuliyyət daşıyır.
Avtomatik yeniləmə problemi qlobal çəngəldən istifadə edərək həll edildi, o, cədvəl üzrə reyestrə gedir və orada yeni bir sistem şəklini görərsə, onu çıxarır (yəni "özü").
Çoxluqda parametrlərin saxlanması istifadə edərək həyata keçirilir ConfigMap, yaddaşlar üçün ilkin məlumatları ehtiva edir (başlanğıcda onlar anbarlara yüklənir).
Parolun yaradılması, kəşfi və davamlı kəşfi ilə bağlı problemlər qarmaqlar vasitəsilə həll edildi.
Səhnələşdirmə Docker-in qutudan kənarda dəstəklədiyi teqlər sayəsində əldə edilir.
Nəticə statusu anlaya biləcəyimiz metriklərdən istifadə etməklə izlənilir.

Bütün bu sistem Go-da addon-operator adlanan tək binar şəklində həyata keçirilir. Bu, diaqramı daha sadə edir:

Bu diaqramdakı əsas komponent modullar dəstidir (aşağıda boz rənglə vurğulanmışdır). İndi bir az səylə tələb olunan əlavə üçün modul yaza bilərik və əmin ola bilərik ki, o, hər klasterdə quraşdırılacaq, yenilənəcək və klasterdə lazım olan hadisələrə cavab verəcəkdir.

"Flant" istifadə edir addon-operator 70+ Kubernetes klasterində. Cari vəziyyət - alfa versiyası. İndi biz beta versiyasını buraxmaq üçün sənədlər hazırlayırıq, lakin hələlik depoda nümunələri mövcuddur, bunun əsasında öz addonunuzu yarada bilərsiniz.

Addon-operator üçün modulları haradan əldə edə bilərəm? Kitabxanamızın nəşri bizim üçün növbəti mərhələdir, biz bunu yayda etməyi planlaşdırırıq.

Videolar və slaydlar

Tamaşadan video (~50 dəqiqə):

Hesabat təqdimatı:

PS

Bloqumuzdakı digər hesabatlar:

«Verilənlər bazaları və Kubernetes"; (Dmitri Stolyarov; 8 noyabr 2018-ci il HighLoad++ ilə);
«Monitorinq və Kubernetes"; (Dmitri Stolyarov; 28 may 2018-ci il, RootConf-da);
«Kubernetes və GitLab ilə CI/CD ən yaxşı təcrübələri"; (Dmitri Stolyarov; 7 noyabr 2017-ci il HighLoad++ ilə);
«Kiçik layihələrdə Kubernetes ilə təcrübəmiz"; (Dmitri Stolyarov; 6 iyun 2017-ci ildə RootConf-da).

Aşağıdakı nəşrlərlə də maraqlana bilərsiniz:

«Shell-operatorun təqdimatı: Kubernetes üçün operatorlar yaratmaq daha asan oldu.

Mənbə: www.habr.com

Kubernetes-in genişləndirilməsi və əlavə edilməsi (baxış və video hesabat)