Bilješka. transl.: U Kubernetes zajednici trend zvan GitOps postaje sve popularniji, kao što smo lično vidjeli, KubeCon Europe 2019. Ovaj termin je bio relativno noviji od strane šefa Weaveworksa - Alexis Richardson - i znači korištenje alata poznatih programerima (prvenstveno Git, otuda i ime) za rješavanje operativnih problema. Konkretno, govorimo o radu Kubernetesa pohranjivanjem njegovih konfiguracija u Git i automatskim uvođenjem promjena u klaster. Matthias Jg u ovom članku govori o dva pristupa ovom uvođenju.
Prošle godine (u stvari, formalno se to dogodilo u avgustu 2017. - pribl. prev.) Postoji novi pristup postavljanju aplikacija u Kubernetes. Zove se GitOps i zasniva se na osnovnoj ideji da se verzije implementacije prate u sigurnom okruženju Git spremišta.
Glavne prednosti ovog pristupa su sljedeće::
- Verzija implementacije i historija promjena. Stanje cijelog klastera je pohranjeno u Git spremištu, a implementacije se ažuriraju samo putem urezivanja. Osim toga, sve promjene se mogu pratiti korištenjem historije urezivanja.
- Vraća se koristeći poznate Git komande. Jednostavno
git resetomogućava vam da poništite promjene u implementacijama; prošla stanja su uvijek dostupna. - Spremna kontrola pristupa. Tipično, Git sistem sadrži mnogo osjetljivih podataka, tako da većina kompanija posvećuje posebnu pažnju njihovoj zaštiti. Shodno tome, ova zaštita se odnosi i na operacije sa raspoređivanjem.
- Pravila za implementacije. Većina Git sistema izvorno podržava politike grane po granu – na primjer, samo zahtjevi za povlačenjem mogu ažurirati master, a promjene mora pregledati i prihvatiti drugi član tima. Kao i kod kontrole pristupa, ista pravila se primjenjuju na ažuriranja implementacije.
Kao što vidite, GitOps metoda ima mnogo prednosti. Tokom protekle godine, dva pristupa su stekla posebnu popularnost. Jedan je zasnovan na guranje, drugi na povlačenje. Prije nego što ih pogledamo, pogledajmo prvo kako izgledaju tipične Kubernetes implementacije.
Metode implementacije
Posljednjih godina u Kubernetesu su uspostavljene različite metode i alati za implementaciju:
- Zasnovano na izvornim Kubernetes/Kustomize predlošcima. Ovo je najlakši način za implementaciju aplikacija na Kubernetes. Programer kreira osnovne YAML datoteke i primjenjuje ih. Da bismo se riješili stalnog ponovnog pisanja istih šablona, razvijen je Kustomize (pretvara Kubernetes šablone u module). Bilješka. transl.: Kustomize je integriran u kubectl sa .
- Helm Charts. Helm grafikoni vam omogućavaju da kreirate skupove šablona, init kontejnera, sidecara, itd., koji se koriste za implementaciju aplikacija sa fleksibilnijim opcijama prilagođavanja nego u pristupu zasnovanom na šablonima. Ova metoda je zasnovana na šablonskim YAML datotekama. Helm ih ispunjava različitim parametrima, a zatim ih šalje Tiller-u, komponenti klastera koja ih postavlja u klaster i dozvoljava ažuriranja i vraćanja. Važno je da Helm u suštini samo ubacuje željene vrijednosti u šablone i zatim ih primjenjuje na isti način kao što se radi u tradicionalnom pristupu (više o tome kako sve funkcionira i kako to možete koristiti pročitajte u našoj - cca. prevod). Postoji širok izbor gotovih Helm karti koje pokrivaju širok raspon zadataka.
- Alternativni alati. Postoji mnogo alternativnih alata. Ono što im je svima zajedničko je da neke šablonske datoteke pretvaraju u Kubernetes čitljive YAML datoteke i zatim ih koriste.
U svom radu konstantno koristimo Helm grafikone za važne alate (s obzirom da imaju dosta stvari već spremnih, što znatno olakšava život) i „čiste“ Kubernetes YAML datoteke za implementaciju vlastitih aplikacija.
Pull & Push
U jednom od mojih nedavnih postova na blogu, predstavio sam alat , koji vam omogućava da urezujete šablone u Git spremište i ažurirate implementaciju nakon svakog urezivanja ili pritiskanja kontejnera. Moje iskustvo pokazuje da je ovaj alat jedan od glavnih u promociji pull pristupa, pa ću ga često spominjati. Ako želite saznati više o tome kako ga koristiti, ovdje .
NB! Sve prednosti korištenja GitOps-a ostaju iste za oba pristupa.
Pristup zasnovan na povlačenju
Pristup povlačenja zasniva se na činjenici da se sve promjene primjenjuju unutar klastera. Unutar klastera postoji operater koji redovno provjerava pridružena Git i Docker Registry spremišta. Ako se na njima dogodi bilo kakva promjena, stanje klastera se interno ažurira. Ovaj proces se općenito smatra vrlo sigurnim, jer nijedan vanjski klijent nema pristup administratorskim pravima klastera.
Pros:
- Nijedan spoljni klijent nema prava da pravi promene u klasteru; sva ažuriranja se uvode iznutra.
- Neki alati vam također omogućavaju da sinhronizirate ažuriranja Helm grafikona i povežete ih s klasterom.
- Docker Registry se može skenirati za nove verzije. Ako je nova slika dostupna, Git spremište i implementacija ažuriraju se na novu verziju.
- Alati za povlačenje mogu se distribuirati u različitim imenskim prostorima s različitim Git repozitorijumima i dozvolama. Zahvaljujući tome, može se koristiti model sa više stanara. Na primjer, tim A može koristiti imenski prostor A, tim B može koristiti imenski prostor B, a infrastrukturni tim može koristiti globalni prostor.
- Alati su po pravilu vrlo lagani.
- U kombinaciji sa alatima kao što je operater , tajne se mogu pohraniti šifrirane u Git spremište i preuzeti unutar klastera.
- Nema veze s CD cjevovodima jer se implementacije dešavaju unutar klastera.
Minusy:
- Upravljanje tajnama implementacije iz Helm grafikona je teže od uobičajenih, jer se prvo moraju generirati u obliku, recimo, zapečaćenih tajni, zatim dešifrirati od strane internog operatera, a tek nakon toga postaju dostupne alatu za povlačenje. Zatim možete pokrenuti izdanje u Helmu sa vrijednostima u već raspoređenim tajnama. Najlakši način je kreirati tajnu sa svim Helm vrijednostima koje se koriste za implementaciju, dešifrirati je i predati Gitu.
- Kada uzmete pristup povlačenju, postajete vezani za alate za povlačenje. Ovo ograničava mogućnost prilagođavanja procesa implementacije u klasteru. Na primjer, Kustomize je komplikovan činjenicom da se mora pokrenuti prije nego što se konačni predlošci predaju Gitu. Ne kažem da ne možete koristiti samostalne alate, ali ih je teže integrirati u vaš proces implementacije.
Push pristup
U push pristupu, vanjski sistem (uglavnom CD cjevovodi) pokreće implementacije u klaster nakon urezivanja u Git spremište ili ako je prethodni CI cjevovod uspješan. U ovom pristupu, sistem ima pristup klasteru.
Plûsy:
- Sigurnost je određena Git repozitorijom i cevovodom izgradnje.
- Uvođenje Helm grafikona je lakše i podržava Helm dodatke.
- Tajnama je lakše upravljati jer se tajne mogu koristiti u cjevovodima i također se mogu pohraniti šifrirane u Git (ovisno o preferencijama korisnika).
- Ne postoji veza sa određenim alatom, jer se može koristiti bilo koji tip.
- Ažuriranja verzije kontejnera mogu se pokrenuti cevovodom izgradnje.
Minusy:
- Podaci za pristup klasteru su unutar sistema izgradnje.
- Ažuriranje kontejnera za implementaciju je još lakše uz proces povlačenja.
- Velika zavisnost od CD sistema, budući da su cevovodi koji su nam potrebni možda originalno napisani za Gitlab Runners, a onda tim odlučuje da pređe na Azure DevOps ili Jenkins... i moraće da migrira veliki broj build pipelinea.
Rezultati: Gurnite ili Povucite?
Kao što to obično biva, svaki pristup ima svoje prednosti i nedostatke. Neke zadatke je lakše izvršiti s jednim, a teže s drugim. U početku sam implementirao ručno, ali nakon što sam naišao na nekoliko članaka o Weave Fluxu, odlučio sam implementirati GitOps procese za sve projekte. Za osnovne šablone to je bilo lako, ali onda sam počeo da nailazim na poteškoće sa Helm grafikonima. U to vrijeme, Weave Flux je nudio samo rudimentarnu verziju Helm Chart Operatora, ali čak su i sada neki zadaci teži zbog potrebe da se ručno kreiraju tajne i primjenjuju. Mogli biste tvrditi da je pristup povlačenja mnogo sigurniji jer vjerodajnici klastera nisu dostupni izvan klastera, što ga čini toliko sigurnijim da je vrijedan dodatnog truda.
Nakon malo razmišljanja, došao sam do neočekivanog zaključka da to nije tako. Ako govorimo o komponentama koje zahtijevaju maksimalnu zaštitu, ova lista će uključivati tajnu pohranu, CI/CD sisteme i Git spremišta. Informacije unutar njih su vrlo ranjive i trebaju maksimalnu zaštitu. Dodatno, ako neko uđe u vaše Git spremište i može tamo ubaciti kod, može implementirati šta god želi (bilo da je to pull ili push) i infiltrirati se u sisteme klastera. Dakle, najvažnije komponente koje treba zaštititi su Git repozitorijum i CI/CD sistemi, a ne akreditivi klastera. Ako imate dobro konfigurisane politike i sigurnosne kontrole za ove vrste sistema, a vjerodajnice klastera se izvlače u cjevovode samo kao tajne, dodatna sigurnost pristupa povlačenja možda neće biti tako vrijedna kao što se prvobitno mislilo.
Dakle, ako je pristup povlačenja radno intenzivniji i ne pruža sigurnosnu korist, zar nije logično koristiti samo push pristup? Ali neko bi mogao da tvrdi da ste u push pristupu previše vezani za CD sistem i možda je bolje da to ne radite kako bi bilo lakše izvršiti migracije u budućnosti.
Po mom mišljenju (kao i uvijek) treba koristiti ono što je najprikladnije za određeni slučaj ili kombinaciju. Lično koristim oba pristupa: Weave Flux za implementacije zasnovane na povlačenju koje uglavnom uključuju naše vlastite usluge i push pristup s Helmom i dodacima, koji olakšava primjenu Helm grafikona na klaster i omogućava vam da neprimetno kreirate tajne. Mislim da nikada neće postojati jedinstveno rješenje pogodno za sve slučajeve, jer uvijek ima puno nijansi i one zavise od konkretne primjene. S obzirom na to, toplo preporučujem GitOps – on čini život mnogo lakšim i poboljšava sigurnost.
Nadam se da će vam moje iskustvo na ovoj temi pomoći da odlučite koja metoda je prikladnija za vaš tip implementacije i bilo bi mi drago čuti vaše mišljenje.
PS Napomena prevodioca
Nedostatak modela povlačenja je taj što je teško staviti renderirane manifeste u Git, ali nema loše strane to što cjevovod CD-a u modelu povlačenja živi odvojeno od uvođenja i u suštini postaje cevovod kategorije Kontinuirana primjena. Stoga će biti potrebno još više truda da se prikupi njihov status od svih implementacija i na neki način omogući pristup evidenciji/statusu, po mogućnosti u odnosu na CD sistem.
U tom smislu, push model nam omogućava da pružimo barem neke garancije uvođenja, jer se životni vijek cevovoda može učiniti jednakim vijeku trajanja uvođenja.
Isprobali smo oba modela i došli do istih zaključaka kao i autor članka:
- Model povlačenja je pogodan za nas da organizujemo ažuriranja komponenti sistema na velikom broju klastera (vidi. ).
- Push model baziran na GitLab CI je vrlo pogodan za uvođenje aplikacija koje koriste Helmove grafikone. U isto vrijeme, uvođenje implementacija unutar cjevovoda se prati pomoću alata . Inače, u kontekstu ovog našeg projekta, čuli smo stalni „GitOps“ kada smo na našem štandu na KubeCon Europe'19 razgovarali o gorućim problemima DevOps inženjera.
PPS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
Samo registrovani korisnici mogu učestvovati u anketi. molim.
Koristite li GitOps?
-
Da, povuci pristup
-
Da, guraj
-
Da, povuci + guraj
-
Da, nešto drugo
-
Nijedan
Glasalo je 30 korisnika. Uzdržano je bilo 10 korisnika.
izvor: www.habr.com