După Îi prezentăm fratele mai mare - . Acesta este un proiect Open Source care este folosit pentru a instala componente de sistem într-un cluster Kubernetes, care poate fi numit suplimente.
De ce vreo completare?
Nu este un secret pentru nimeni că Kubernetes nu este un produs all-in-one gata făcut și pentru a construi un cluster „adult” veți avea nevoie de diverse completări. Addon-operator vă va ajuta să instalați, să configurați și să păstrați aceste suplimente la zi.
Necesitatea componentelor suplimentare în cluster este dezvăluită în Colegi . Pe scurt, situația cu Kubernetes în acest moment este de așa natură încât pentru o simplă instalare „play around” te poți descurca cu componentele din cutie, pentru dezvoltatori și testare poți adăuga Ingress, dar pentru o instalare completă, despre care puteți spune „producția dvs. este gata”, trebuie să adăugați cu o duzină de suplimente diferite: ceva pentru monitorizare, ceva pentru înregistrare, nu uitați de intrare și certificat-manager, selectați grupuri de noduri, adăugați politici de rețea, sezon cu setări de autoscaler sysctl și pod...
Care sunt particularitățile lucrului cu ei?
După cum arată practica, problema nu se limitează la o singură instalare. Pentru a lucra confortabil cu clusterul, suplimentele vor trebui actualizate, dezactivate (eliminate din cluster) și veți dori să testați unele înainte de a le instala în clusterul de producție.
Deci, poate Ansible va fi suficient aici? Pot fi. Dar În general, suplimentele cu drepturi depline nu trăiesc fără setări. Aceste setări pot diferi în funcție de varianta de cluster (aws, gce, azure, bare-metal, do, ...). Unele setări nu pot fi specificate în prealabil; acestea trebuie obținute din cluster. Și clusterul nu este static: pentru unele setări va trebui să monitorizați modificările. Și aici Ansible deja lipsește: aveți nevoie de un program care să trăiască într-un cluster, adică. Operator Kubernetes.
Cei care au încercat-o la serviciu , vor spune că sarcinile de instalare și actualizare a suplimentelor și setărilor de monitorizare pot fi rezolvate complet folosind pentru shell-operator. Puteți scrie un script care va face un condițional kubectl apply și monitorizați, de exemplu, ConfigMap, unde vor fi stocate setările. Acesta este aproximativ ceea ce este implementat în addon-operator.
Cum este organizat acest lucru în addon-operator?
La crearea unei noi soluții, am pornit de la următoarele principii:
- Programul de instalare a suplimentului trebuie să accepte modelare și configurație declarativă. Nu facem scripturi magice care instalează suplimente. Operatorul de suplimente folosește Helm pentru a instala suplimente. Pentru a instala, trebuie să creați o diagramă și să selectați valorile care vor fi utilizate pentru configurare.
- Setările pot fi genera la instalare, poti ia din clusterSau primi actualizări, monitorizarea resurselor clusterului. Aceste operațiuni pot fi implementate folosind cârlige.
- Setările pot fi depozitați într-un cluster. Pentru a stoca setările în cluster, este creat un ConfigMap/addon-operator, iar Addon-operator monitorizează modificările aduse acestui ConfigMap. Operatorul de supliment oferă cârligelor acces la setări folosind convenții simple.
- Adăugarea depinde de setări. Dacă setările s-au schimbat, atunci operatorul de supliment lansează diagrama Helm cu noi valori. Am numit combinația diagramei Helm, a valorilor pentru aceasta și a cârlige un modul (a se vedea mai jos pentru mai multe detalii).
- Înscenare. Nu există scripturi de lansare magică. Mecanismul de actualizare este similar cu o aplicație obișnuită - colectați suplimente și operatori de suplimente într-o imagine, etichetați-le și lansați-le.
- Controlul rezultatelor. Operatorul de supliment poate furniza valori pentru Prometheus.
Ce este padding în addon-operator?
O adăugare poate fi considerată orice adaugă funcții noi cluster-ului. De exemplu, instalarea Ingress este un exemplu excelent de supliment. Acesta poate fi orice operator sau controler cu propriul CRD: prometheus-operator, cert-manager, kube-controller-manager etc. Sau ceva mic, dar mai ușor de utilizat - de exemplu, secret copier, care copiază secretele de registry în spații de nume noi sau sysctl tuner, care configurează parametrii sysctl pe noduri noi.
Pentru a implementa suplimente, Addon-operator oferă mai multe concepte:
- Diagrama de cârmă folosit pentru a instala diverse software în cluster - de exemplu, Prometheus, Grafana, nginx-ingress. Dacă componenta necesară are o diagramă Helm, atunci instalarea acesteia folosind Addon-operator va fi foarte simplă.
- Stocarea valorilor. Diagramele Helm au de obicei multe setări diferite care se pot schimba în timp. Operatorul de supliment acceptă stocarea acestor setări și poate monitoriza modificările acestora pentru a reinstala diagrama Helm cu valori noi.
- Cârlige sunt fișiere executabile pe care operatorul Addon le rulează pe evenimente și care accesează magazinul de valori. Cârligul poate monitoriza modificările din cluster și poate actualiza valorile din magazinul de valori. Acestea. Folosind cârlige, puteți face descoperire pentru a colecta valori din cluster la pornire sau conform unui program, sau puteți face descoperire continuă, colectând valori din cluster pe baza modificărilor din cluster.
- Modul este o combinație între o diagramă Helm, un magazin de valori și cârlige. Modulele pot fi activate sau dezactivate. Dezactivarea unui modul înseamnă ștergerea tuturor lansărilor de diagrame Helm. Modulele se pot activa dinamic, de exemplu, dacă toate modulele de care are nevoie sunt activate sau dacă descoperirea a găsit parametrii necesari în cârlige - acest lucru se face folosind un script auxiliar activat.
- Cârlige globale. Acestea sunt cârlige „pe cont propriu”, nu sunt incluse în module și au acces la un magazin de valori global, ale cărui valori sunt disponibile pentru toate cârligele din module.
Cum funcționează aceste părți împreună? Să ne uităm la poza din documentație:
Există două scenarii de lucru:
- Cârligul global este declanșat de un eveniment - de exemplu, atunci când o resursă din cluster se modifică. Acest cârlig procesează modificările și scrie noile valori în magazinul de valori globale. Operatorul de supliment observă că stocarea globală s-a schimbat și pornește toate modulele. Fiecare modul, folosind cârligele sale, determină dacă trebuie activat și își actualizează stocul de valori. Dacă modulul este activat, operatorul de supliment începe instalarea diagramei Helm. În acest caz, diagrama Helm are acces la valorile din stocarea modulului și din stocarea globală.
- Al doilea scenariu este mai simplu: un cârlig de modul este declanșat de un eveniment și modifică valorile din magazinul de valori al modulului. Operatorul de supliment observă acest lucru și lansează diagrama Helm cu valori actualizate.
Adăugarea poate fi implementată ca un singur cârlig, sau ca o diagramă Helm, sau chiar ca mai multe module dependente - aceasta depinde de complexitatea componentei instalate în cluster și de nivelul dorit de flexibilitate de configurare. De exemplu, în depozit () există un add-on sysctl-tuner, care este implementat atât ca un simplu modul cu un cârlig și o diagramă Helm, cât și folosind magazinul de valori, care face posibilă adăugarea setărilor prin editarea ConfigMap.
Livrarea actualizărilor
Câteva cuvinte despre organizarea actualizărilor componentelor pe care le instalează Addon-operator.
Pentru a rula Addon-operator într-un cluster, aveți nevoie construiți o imagine cu adăugiri sub formă de fișiere cu cârlig și diagramă Helm, adăugați un fișier binar addon-operator și tot ce aveți nevoie pentru cârlige: bash, kubectl, jq, python etc. Apoi această imagine poate fi difuzată în cluster ca o aplicație obișnuită și, cel mai probabil, veți dori să organizați una sau alta schemă de etichetare. Dacă există puține clustere, aceeași abordare ca și în cazul aplicațiilor poate fi potrivită: versiune nouă, versiune nouă, accesați toate clusterele și corectați imaginea Pod-urilor. Totuși, în cazul unei lansări la un număr semnificativ de clustere, conceptul de auto-actualizare de la un canal ne-a fost mai potrivit.
Iată cum o facem:
- Un canal 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ă lansați actualizări pentru un canal, o nouă imagine este asamblată și etichetată cu numele canalului.
- Când apare o nouă imagine în registry, Addon-operator este repornit și lansat cu noua imagine.
Aceasta nu este cea mai bună practică, așa cum este scris în . Nu este recomandat să faceți acest lucru, dar despre care vorbim o aplicație obișnuită care locuiește în același cluster. În cazul Addon-operator, o aplicație este o mulțime de implementări împrăștiate în clustere, iar auto-actualizarea ajută foarte mult și face viața mai ușoară.
Canalele ajută și în testare: dacă există un cluster auxiliar, îl puteți configura pe canal stage și introduceți actualizări în el înainte de a o lansa pe canale ea и stable. Dacă cu un cluster pe canal ea a apărut o eroare, o puteți comuta la stable, în timp ce problema cu acest cluster este investigată. Dacă clusterul este scos din suport activ, acesta trece la canalul său „înghețat” - de exemplu, freeze-2019-03-20.
Pe lângă actualizarea cârligelor și diagramelor Helm, este posibil să aveți nevoie actualizare și componentă terță parte. De exemplu, ați observat o eroare în nodul-exportator condiționat și chiar v-ați dat seama cum să o corectați. Apoi, ați deschis PR și așteptați ca noua versiune să treacă prin toate clusterele și să mărească versiunea imaginii. Pentru a nu aștepta la infinit, puteți să vă construiți nodul-exportator și să treceți la el înainte de a accepta PR.
În general, acest lucru se poate face fără Addon-operator, dar cu Addon-operator modulul pentru instalarea nod-exporter va fi vizibil într-un singur depozit, Dockerfile pentru construirea imaginii dvs. poate fi păstrat chiar acolo, devine mai ușor pentru toți participanții la procesul pentru a înțelege ce se întâmplă... Și dacă există mai multe clustere, atunci devine mai ușor să-ți testezi PR și să lansezi o nouă versiune!
Această organizare a actualizării componentelor funcționează cu succes pentru noi, dar orice altă schemă adecvată poate fi implementată - până la urmă în acest caz, Addon-operator este un simplu fișier binar.
Concluzie
Principiile implementate în Addon-operator vă permit să construiți un proces transparent pentru crearea, testarea, instalarea și actualizarea suplimentelor într-un cluster, similar proceselor de dezvoltare ale aplicațiilor obișnuite.
Suplimentele pentru Addon-operator în format modul (Helm chart + hooks) pot fi puse la dispoziția publicului. Noi, compania Flant, plănuim să publicăm dezvoltările noastre sub forma unor astfel de completări în timpul verii. Alăturați-vă dezvoltării pe GitHub (, ), încercați să faceți propria adăugare pe baza и , așteptați știri pe Habré și pe noastre !
PS
Citește și pe blogul nostru:
- «»;
- «".
Sursa: www.habr.com