După îi prezentăm fratele său mai mare — . Acesta este un proiect Open Source, care este folosit pentru instalarea componentelor sistemului în cluster-ul Kubernetes, pe care le putem numi într-un cuvânt comun — addon-uri.
De ce avem nevoie de addon-uri?
Nu este un secret că Kubernetes nu este un produs gata pregătit, all-in-one, iar pentru construirea unui cluster "matur" sunt necesare diverse addon-uri. Addon-operator va ajuta la instalarea, configurarea și menținerea acestor addon-uri actualizate.
Nevoia de componente suplimentare în cluster este discutată în colegilor . Pe scurt, situația cu Kubernetes în acest moment este că pentru o instalare simplă, pentru a "experimentat", poți folosi componentele din cutie, pentru dezvoltatori și testare poți adăuga Ingress, dar pentru o instalare completă, despre care putem spune că "producția ta este gata", este necesar să adaugi o duzină de addon-uri diferite: ceva pentru monitorizare, ceva pentru jurnale, să nu uităm de ingress și cert-manager, să alocăm grupuri de noduri, să adăugăm politici de rețea, să condimentăm cu setări sysctl și pod autoscaler…
Care este specificul lucrului cu ele?
După cum arată practica, instalarea singură nu este suficientă. Pentru a lucra confortabil cu cluster-ul, addon-urile trebuie actualizate, dezactivate (eliminate din cluster), iar unele vor trebui testate înainte de a fi instalate în cluster-ul de producție.
Deci, poate că aici ar fi suficient Ansible? Posibil. Dar addon-urile complete, în general, nu funcționează fără configurații. Aceste configurații pot varia în funcție de tipul de cluster (aws, gce, azure, bare-metal, do, …). Unele setări nu pot fi definite dinainte — trebuie obținute din cluster. Iar cluster-ul nu este static: pentru anumite configurații va trebui să urmărești modificările. Și aici Ansible nu este suficient: este nevoie de un program care să trăiască în cluster, adică un Kubernetes Operator.
Cei care au încercat în practică , vor spune că sarcinile de instalare și actualizare a addon-urilor și de urmărire a configurațiilor pot fi, de fapt, rezolvate cu ajutorul pentru shell-operator. Poți scrie un script care va face un fel de kubectl apply și va urmări, de exemplu, ConfigMap-ul, unde vor fi stocate configurațiile. Aproape asta este implementat în addon-operator.
Cum este organizat în addon-operator?
Creând o nouă soluție, ne-am bazat pe următoarele principii:
- Instalatorul de addon-uri trebuie să suportă șabloane și configurație declarativă. Nu creăm scripturi magice care instalează addon-uri. Addon-operator folosește Helm pentru instalarea addon-urilor. Pentru instalare, trebuie să creați un chart și să definiți valori care vor fi utilizate pentru configurare.
- Setările pot fi generate la instalare, pot fi obținute din cluster, sau obține actualizări, monitorizând resursele cluster-ului. Aceste operațiuni pot fi realizate cu ajutorul hook-urilor.
- Setările pot fi stocate în cluster. Pentru a stoca setările în cluster, se creează ConfigMap/addon-operator, iar Addon-operator monitorizează modificările acestui ConfigMap. Addon-operator oferă hook-urilor acces la setări prin convenții simple.
- Addon-ul depinde de setări. Dacă setările s-au schimbat, Addon-operator desface Helm-chart cu noile valori. Combinarea Helm-chart-ului, valorilor pentru acesta și hook-urilor le-am numit modul (mai multe detalii mai jos).
- Stage-izare. Nu există scripturi magice de lansare. Mecanismul de actualizare este similar cu o aplicație obișnuită — să construim addon-urile și addon-operatorul într-un imagine, etichetăm și lansăm.
- Controlul rezultatelor. Addon-operator poate oferi metrici pentru Prometheus.
Ce este un addon în addon-operator?
Un addon poate fi considerat tot ceea ce adaugă funcții noi în cluster. De exemplu, instalarea Ingress - un exemplu excelent de addon. Poate fi orice operator sau controler cu propriul său CRD: prometheus-operator, cert-manager, kube-controller-manager etc. Sau ceva mai mic, dar care simplifică operațiunile - de exemplu, secret copier, care copiază secretele registry în noi spații de nume, sau sysctl tuner, care configurează parametrii sysctl pe noi noduri.
Pentru a implementa addon-uri, Addon-operator oferă câteva concepte:
- Helm-chart este folosit pentru a instala diverse software în cluster — de exemplu, Prometheus, Grafana, nginx-ingress. Dacă componenta necesară are un Helm-chart, va fi foarte simplu să-l instalați cu Addon-operator.
- Depozitul de valori. Helm-charts au de obicei multe setări diferite, care pot varia în timp. Addon-operator suportă stocarea acestor setări și poate monitoriza modificările pentru a reinstala Helm-chart-ul cu noile valori.
- Hook-uri — sunt fișiere executabile pe care Addon-operator le rulează la evenimente și care au acces la depozitul de valori. Hook-ul poate monitoriza modificările din cluster și actualiza valorile din depozitul de valori. Asta înseamnă că, cu ajutorul hook-urilor, se poate realiza un discovery pentru a colecta valori din cluster la pornire sau conform unui program, sau se poate realiza un discovery continuu, colectând valori din cluster pe baza modificărilor din cluster.
- Modulul — este o combinație de chart Helm, depozit de valori și hook-uri. Modulele pot fi activate sau dezactivate. Dezactivarea unui modul constă în eliminarea tuturor eliberărilor chart-ului Helm. Modulele se pot include dinamic, de exemplu, dacă toate modulele necesare sunt activate sau dacă discovery-ul din hook-uri a găsit parametrii necesari — acest lucru se face cu ajutorul unui script auxiliary enabled.
- Hook-uri globale. Acestea sunt hook-uri „de sine stătătoare”, nu sunt incluse în module și au acces la depozitul global de valori, ale căror valori sunt accesibile tuturor hook-urilor din module.
Cum funcționează aceste părți împreună? Să ne uităm la imaginea din documentație:
Există două scenarii de lucru:
- Hook-ul global este déclanșat de un eveniment — de exemplu, la modificarea unei resurse din cluster. Acest hook procesează modificările și scrie noi valori în depozitul global de valori. Addon-operator observă că depozitul global a fost modificat și declanșează toate modulele. Fiecare modul, prin hook-urile sale, stabilește dacă trebuie să se activeze și își actualizează propria depozit de valori. Dacă modulul este activat, atunci Addon-operator începe instalarea chart-ului Helm. Chart-ului Helm îi sunt disponibile valorile din depozitul modulului și din depozitul global.
- Al doilea scenariu este mai simplu: hook-ul modular este déclanșat de un eveniment și modifică valorile din depozitul de valori al modulului. Addon-operator observă acest lucru și lansează chart-ul Helm cu valorile actualizate.
Un addon poate fi implementat ca un singur hook sau ca un chart Helm, sau chiar ca mai multe module dependente. — depinde de complexitatea componentei instalate în cluster și de nivelul necesar de flexibilitate a setărilor. De exemplu, în repository-ul () există addon-ul sysctl-tuner, care este implementat atât ca un modul simplu cu un hook și chart Helm, cât și utilizând depozitul de valori, ceea ce oferă posibilitatea de a adăuga setări prin editarea ConfigMap-ului.
Livrarea actualizărilor
Câteva cuvinte despre organizarea actualizărilor componentelor pe care le instalează Addon-operator.
Pentru a lansa Addon-operator în cluster, trebuie să construiești o imagine cu adăugiri sub formă de fișiere hook și chart-uri Helm, să adaugi fișierul binar addon-operator și tot ce este necesar pentru hooks: bash, kubectl, jq, python etc. Apoi, această imagine poate fi lansată în cluster ca o aplicație obișnuită și, cel mai probabil, vei dori să organizezi un anumit sistem de etichetare. Dacă există puține clustere, același abordare ca și cu aplicațiile ar putea funcționa: nouă versiune, nouă versiune, să mergi prin toate clusterele și să modifici imaginea Pod-urilor. Totuși, în cazul lansării pe un număr considerabil de clustere, ne-a fost mai utilă concepția de auto-actualizare din canal.
La noi, este organizat astfel:
- Canalul este, în esență, un identificator, care poate fi setat la orice (de exemplu, dev/stage/ea/stable).
- Numele canalului este eticheta imaginii. Când trebuie să lansezi actualizări în canal, se construiește o nouă imagine și se etichetează cu numele canalului.
- Când o nouă imagine apare în registry, Addon-operator se restartează și pornește cu noua imagine.
Aceasta nu este cea mai bună practică, așa cum este menționat în . Așa ceva nu este recomandat, dar este vorba despre o aplicație obișnuită, care trăiește într-un singur cluster. În cazul Addon-operator, aplicația este un număr mare de Deployments, dispersate prin clustere, iar auto-actualizarea ajută foarte mult și simplifică viața.
Canalele ajută și în testare: dacă există un cluster auxiliar, acesta poate fi configurat pentru canalul stage și poți rula actualizări în el înainte de a le lansa în canalele ea și stable. Dacă a apărut o eroare cu clusterul pe canal, acesta poate fi schimbat pe ea , în timp ce se investighează problema cu acest cluster. Dacă clusterul este scos din suport activ, acesta este schimbat pe canalul său 'înghețat' — de exemplu, stablefreeze-2019-03-20 Pe lângă actualizările hooks și chart-uri Helm, este posibil să fie necesar.
să actualizezi și un component extern . De exemplu, ai observat o eroare în node-exporter și chiar ai găsit o soluție pentru a-l patch-ui. Apoi, ai deschis un PR și aștepți o nouă lansare pentru a merge prin toate clusterele și a crește versiunea imaginii. Pentru a nu aștepta o perioadă nedeterminată, poți construi propriul node-exporter și să treci pe el până la aprobarea PR-ului.. De exemplu, ai observat o eroare în node-exporter și chiar ai găsit o modalitate de a o corecta. Apoi, ai deschis un PR și aștepți o nouă versiune pentru a trece prin toate clusterele și a actualiza versiunea imaginii. Pentru a nu aștepta o perioadă nedeterminată, poți să-ți compilezi propriul node-exporter și să te schimbi pe el până la acceptarea PR-ului.
În general, este posibil și fără Addon-operator, dar cu Addon-operator, modulul pentru instalarea node-exporter va fi vizibil într-un singur depozit, Dockerfile-ul pentru construirea propriei imagini poate fi păstrat aici, astfel fiind mai ușor pentru toți participanții să înțeleagă ce se întâmplă... Iar dacă sunt mai multe clustere, devine mai ușor atât să testezi PR-ul tău, cât și să aplici o nouă versiune!
Această organizație de actualizare a componentelor funcționează cu succes pentru noi, dar poate fi implementată orice altă schemă potrivită — pentru că în acest caz, Addon-operator este un simplu fișier binar.
Concluzie
Principiile implementate în Addon-operator permit construirea unui proces transparent de creare, testare, instalare și actualizare a extensiilor în cluster, similar proceselor de dezvoltare a aplicațiilor obișnuite.
Extensiile pentru Addon-operator în format de module (Helm-chart + hooks) pot fi publicate în acces larg. Noi, compania Flant, planificăm să publicăm pe parcursul verii rezultatele noastre sub formă de astfel de extensii. Alăturați-vă dezvoltării pe GitHub (, ), încercați să creați propria extensie pe baza și , așteptați știri pe Habr și pe canalul nostru de !
P.S.
Citiți și în blogul nostru:
- «»;
- «».
Sursa: habr.com
