Poslije predstavljamo njegovog starijeg brata - . Ovo je projekat otvorenog koda koji se koristi za instaliranje sistemskih komponenti u Kubernetes klaster, koji se može nazvati dodacima.
Zašto uopće bilo kakvi dodaci?
Nije tajna da Kubernetes nije gotov proizvod „sve u jednom“, a da biste izgradili „odrasli“ klaster trebat će vam razni dodaci. Addon-operator će vam pomoći da instalirate, konfigurirate i održavate ove dodatke ažurnim.
Potreba za dodatnim komponentama u klasteru je otkrivena u Kolege . Ukratko, situacija sa Kubernetesom u ovom trenutku je takva da za jednostavnu instalaciju "zaigrati" možete proći sa komponentama iz kutije, za programere i testiranje možete dodati Ingress, ali za potpunu instalaciju, o čemu možete reći "vaša proizvodnja je spremna", trebate dodati s desetak različitih dodataka: nešto za praćenje, nešto za logovanje, ne zaboravite ingress i cert-manager, odaberite grupe čvorova, dodajte mrežne politike, sezonu sa sysctl i pod autoscaler postavkama...
Koje su specifičnosti rada sa njima?
Kao što pokazuje praksa, stvar nije ograničena na jednu instalaciju. Za udoban rad s klasterom, dodaci će morati biti ažurirani, onemogućeni (uklonjeni iz klastera), a vi ćete htjeti testirati neke prije nego što ih instalirate u proizvodni klaster.
Dakle, možda će Ansible biti dovoljan ovdje? Možda. Ali Općenito, punopravni dodaci ne žive bez postavki. Ove postavke mogu se razlikovati ovisno o varijanti klastera (aws, gce, azure, bare-metal, do, ...). Neke postavke se ne mogu specificirati unaprijed, moraju se dobiti iz klastera. A klaster nije statičan: za neke postavke morat ćete pratiti promjene. A ovdje Ansible već nedostaje: potreban vam je program koji živi u klasteru, tj. Kubernetes Operator.
Oni koji su to probali na poslu , oni će reći da se zadaci instaliranja i ažuriranja dodataka i postavki nadzora mogu u potpunosti riješiti korištenjem za shell-operatora. Možete napisati skriptu koja će raditi uslov kubectl apply i nadgledati, na primjer, ConfigMap, gdje će postavke biti pohranjene. To je otprilike ono što je implementirano u addon-operatoru.
Kako je to organizirano u addon-operatoru?
Prilikom kreiranja novog rješenja polazili smo od sljedećih principa:
- Program za instalaciju dodataka mora podržavati šablonske i deklarativne konfiguracije. Ne pravimo magične skripte koje instaliraju dodatke. Addon-operator koristi Helm za instaliranje dodataka. Da biste instalirali, trebate kreirati grafikon i odabrati vrijednosti koje će se koristiti za konfiguraciju.
- Postavke mogu biti generirati pri instalaciji, oni mogu dobiti iz klastera, ili primati ažuriranja, praćenje resursa klastera. Ove operacije se mogu implementirati pomoću kukica.
- Postavke mogu biti pohraniti u klaster. Za pohranjivanje postavki u klaster, kreira se ConfigMap/addon-operator i Addon-operator prati promjene na ovoj ConfigMap. Addon-operator daje kukicama pristup podešavanjima koristeći jednostavne konvencije.
- Dodavanje zavisi od podešavanja. Ako su se postavke promijenile, Addon-operator izbacuje Helm grafikon s novim vrijednostima. Kombinaciju Helm grafikona, vrijednosti za njega i zakačivanja nazvali smo modulom (pogledajte dolje za više detalja).
- Inscenacija. Ne postoje magične skripte za oslobađanje. Mehanizam ažuriranja je sličan običnoj aplikaciji - sakupite dodatke i addon-operatore u sliku, označite ih i pustite ih.
- Kontrola rezultata. Addon-operator može dati metriku za Prometheus.
Šta je padding u addon-operatoru?
Dodatkom se može smatrati sve što dodaje nove funkcije klasteru. Na primjer, instalacija Ingressa je odličan primjer dodatka. To može biti bilo koji operater ili kontroler sa vlastitim CRD-om: prometheus-operator, cert-manager, kube-controller-manager, itd. Ili nešto malo, ali jednostavnije za korištenje - na primjer, tajni alat za kopiranje, koji kopira tajne registra u nove prostore imena, ili sysctl tuner, koji konfigurira sysctl parametre na novim čvorovima.
Za implementaciju dodataka, Addon-operator nudi nekoliko koncepata:
- Helm chart koristi se za instaliranje raznih softvera u klaster - na primjer, Prometheus, Grafana, nginx-ingress. Ako potrebna komponenta ima Helm grafikon, tada će je instalirati pomoću Addon-operatora biti vrlo jednostavno.
- Skladištenje vrijednosti. Helm karte obično imaju mnogo različitih postavki koje se mogu mijenjati tokom vremena. Addon-operator podržava pohranjivanje ovih postavki i može pratiti njihove promjene kako bi ponovo instalirao Helm grafikon s novim vrijednostima.
- Kuke su izvršne datoteke koje Addon-operator pokreće na događajima i koje pristupaju spremištu vrijednosti. Hook može pratiti promjene u klasteru i ažurirati vrijednosti u skladištu vrijednosti. One. Koristeći kuke, možete napraviti otkriće za prikupljanje vrijednosti iz klastera pri pokretanju ili prema rasporedu, ili možete raditi kontinuirano otkrivanje, prikupljajući vrijednosti iz klastera na osnovu promjena u klasteru.
- Modul je kombinacija Helm grafikona, skladišta vrijednosti i kukica. Moduli se mogu uključiti ili onemogućiti. Onemogućavanje modula znači brisanje svih izdanja Helm grafikona. Moduli se mogu dinamički omogućiti, na primjer, ako su svi moduli koji su im potrebni uključeni ili ako je otkrivanje pronašlo potrebne parametre u zakačama - to se radi pomoću pomoćne omogućene skripte.
- Globalne kuke. Ovo su kuke „same za sebe“, nisu uključene u module i imaju pristup globalnoj pohrani vrijednosti čije su vrijednosti dostupne svim zakačanjima u modulima.
Kako ovi dijelovi funkcionišu zajedno? Pogledajmo sliku iz dokumentacije:
Postoje dva scenarija rada:
- Globalnu zakačicu pokreće događaj - na primjer, kada se promijeni resurs u klasteru. Ova kuka obrađuje promjene i upisuje nove vrijednosti u globalnu pohranu vrijednosti. Addon-operator primjećuje da se globalna memorija promijenila i pokreće sve module. Svaki modul, koristeći svoje kuke, određuje da li treba da bude omogućen i ažurira svoju pohranu vrijednosti. Ako je modul omogućen, Addon-operator započinje instalaciju Helm karte. U ovom slučaju, Helmova karta ima pristup vrijednostima iz skladišta modula i iz globalne memorije.
- Drugi scenario je jednostavniji: zakačivanje modula pokreće se događajem i mijenja vrijednosti u skladištu vrijednosti modula. Addon-operator to primjećuje i pokreće Helm grafikon sa ažuriranim vrijednostima.
Dodatak se može implementirati kao jedna udica, ili kao jedna Helm karta, ili čak i kao nekoliko zavisnih modula - ovo zavisi od složenosti komponente koja se instalira u klaster i od željenog nivoa fleksibilnosti konfiguracije. Na primjer, u spremištu () postoji dodatak sysctl-tuner, koji je implementiran i kao jednostavan modul sa kukom i Helm grafikonom, i koristeći skladište vrijednosti, što omogućava dodavanje postavki uređivanjem ConfigMap.
Isporuka ažuriranja
Nekoliko riječi o organiziranju ažuriranja komponenti koje Addon-operator instalira.
Da biste pokrenuli Addon-operator u klasteru, trebate izgraditi sliku s dodacima u obliku hook i Helm grafikona, dodajte binarnu datoteku addon-operator i sve što je potrebno za kuke: bash, kubectl, jq, python itd. Tada se ova slika može razvući u klaster kao redovna aplikacija i najvjerovatnije ćete htjeti organizirati jednu ili drugu šemu označavanja. Ako ima malo klastera, može biti prikladan isti pristup kao kod aplikacija: novo izdanje, nova verzija, idite na sve klastere i ispravite sliku Podova. Međutim, u slučaju uvođenja na značajan broj klastera, više nam je odgovarao koncept samoažuriranja iz kanala.
Evo kako to radimo:
- Kanal je u suštini identifikator koji se može postaviti na bilo šta (na primjer, dev/stage/ea/stable).
- Naziv kanala je oznaka slike. Kada treba da objavite ažuriranja na kanalu, nova slika se sastavlja i označava imenom kanala.
- Kada se nova slika pojavi u registru, Addon-operator se ponovo pokreće i pokreće sa novom slikom.
Ovo nije najbolja praksa, kao što je napisano . Nije preporučljivo to učiniti, ali govorimo o tome obična aplikacija koja živi u istom klasteru. U slučaju Addon-operatora, aplikacija je mnogo Deploymenta razbacanih po klasterima, a samo-ažuriranje puno pomaže i olakšava život.
Kanali pomažu i u testiranju: ako postoji pomoćni klaster, možete ga konfigurirati za kanal stage i ubacite ažuriranja u njega prije nego što ga objavite na kanalima ea и stable. Ako sa klasterom na kanalu ea došlo je do greške, možete je prebaciti na stable, dok se problem sa ovim klasterom istražuje. Ako je klaster isključen iz aktivne podrške, prebacuje se na svoj "zamrznuti" kanal - npr. freeze-2019-03-20.
Osim ažuriranja kukica i Helm grafikona, možda će vam trebati ažuriranje i komponenta treće strane. Na primjer, primijetili ste grešku u uslovnom izvozniku čvorova i čak ste shvatili kako da je zakrpite. Zatim ste otvorili PR i čekate da novo izdanje prođe kroz sve klastere i poveća verziju slike. Kako ne biste čekali beskonačno, možete izgraditi svoj node-exporter i prebaciti se na njega prije nego što prihvatite PR.
Generalno, ovo se može uraditi bez Addon-operatora, ali sa Addon-operatorom modul za instalaciju node-exportera će biti vidljiv u jednom spremištu, Dockerfile za pravljenje vašeg imidža može se čuvati upravo tamo, postaje lakše za sve učesnike u proces da se shvati šta se dešava... A ako postoji nekoliko klastera, onda postaje lakše i testirati svoj PR i izbaciti novu verziju!
Ova organizacija ažuriranja komponenti uspješno funkcionira za nas, ali bilo koja druga prikladna shema se može implementirati - uostalom u ovom slučaju Addon-operator je jednostavna binarna datoteka.
zaključak
Principi implementirani u Addon-operatoru omogućavaju vam da izgradite transparentan proces za kreiranje, testiranje, instaliranje i ažuriranje dodataka u klasteru, slično razvojnim procesima običnih aplikacija.
Dodaci za Addon-operator u formatu modula (Helm chart + kuke) mogu biti javno dostupni. Mi, kompanija Flant, planiramo da tokom ljeta objavimo naše razvoje u vidu ovakvih dodataka. Pridružite se razvoju na GitHubu (, ), pokušajte napraviti svoj vlastiti dodatak na osnovu и , čekajte vijesti na Habréu i na našem !
PS
Pročitajte i na našem blogu:
- «»;
- «".
izvor: www.habr.com