On-prem Kubernetes grozd – vrnitev k tradicionalnemu razvojnemu načinu razmišljanja 

Ko smo dobili nalogo, da za eno stranko izvedemo celovit pregled Kubernetes okolja, smo se prvič srečali s scenarijem, kjer je Kubernetes v celoti nameščen lokalno – na fizičnih strežnikih v grozdih – in čaka na produkcijsko uporabo oziroma končno zeleno luč. Da je bilo še bolj zanimivo, je bila stranka MVNO v Nemčiji. Telefonija in Kubernetes zagotovo nista kombinacija, ki bi jo srečali vsak dan. 

On-prem Kubernetes grozd: Zveni preprosto, vendar…

Zahteve stranke so bile na prvi pogled preproste. Dobili naj bi dostop do razvojnega (read-only) grozda, pripravili natančen seznam vseh komponent z opisom delovanja, da bi razumeli delovanje njihovega sistema, in ocenili, ali so izbrani pristopi ustrezni – če niso, bi predlagali alternative.

Zveni preprosto. Časovno zahtevno, a preprosto. 

Tudi mi smo mislili tako.

Motili smo se. 

Povratek h koreninam: Old school dev vs. cloud-first tim

Kot ekipa smo vajeni oblaka – vseh malenkosti, ki ga zaznamujejo, in vseh prednosti, ki jih prinaša. Lahko rečemo, da nas ni posebej presenetilo, ko smo odkrili, da nekateri viri niso ravno “oblaku podobni”. Dvojec, ki je delal na tem projektu, ima skupaj približno 40 let izkušenj v IT-ju, vse iz obdobja pred razširjeno uporabo oblaka.  Hitro smo ugotovili, da smo se vrnili v čase tradicionalnega pristopa in da se moramo temu prilagoditi tudi v razmišljanju. 

Kako je videti, ko več razvijalcev oblikuje Kubernetes arhitekturo? 

Relativno hitro smo dobili dostop do razvojnega grozda in potrditev, da sta razvojno, testno in prihodnje produkcijsko okolje enaka – razen razlik, ki nam jih bodo sproti pojasnili. To je pripeljalo do namestitve številnih komponent v Kubernetes, saj je vsaka imela svojo vlogo.

Naše prvo vprašanje je bilo: ali so vse te komponente res nujno potrebne? 

Ko smo vprašanje zastavili razvijalcem, smo dobili odgovor, ki temelji na tipičnem razvijalskem načinu razmišljanja: vse se obravnava kot ločena celota in vsaka zahteva, ki jo je treba izpolniti, pomeni eno komponento. Težko bi rekli, da je tak način razmišljanja napačen.  

Ops pristop pomeni, da se postavi osnovno ogrodje in namesti čim manj, pri tem pa se uporablja vse, kar se že lahko uporabi. V primeru naše stranke je bil pristop ravno nasproten – vsaka potreba je bila rešena z ločeno, namensko komponento. Ker tega nismo mogli ovreči, smo se poskušali prilagoditi.

Izzivi in predlagane rešitve 

Za začetek smo morali razumeti, kaj in kako stranka počne ter na kakšen način deluje njihova aplikacija. Čeprav smo prejeli diagram aplikacije s pripadajočim pojasnilom, smo morali ročno preučiti celotno notranjo komunikacijo med komponentami, da bi razumeli vse odnose znotraj Kubernetesa in celotnega stacka. 

Ker je narava aplikacije komunikacija in izmenjava informacij, je bilo jasno, da se vse dogaja varno – znotraj grozda. Zaradi read-only dostopa smo lahko zgolj pregledovali vire, ne pa tudi vzpostavljali seje do njih, zato smo se zanašali na analizo virov in konfiguracijskih datotek, shranjenih kot config mape. Imena storitev, ingressi in endpointi so nam skozi konfiguracijo razkrili, katera storitev komunicira s katero drugo. V analizi smo odkrili, da se je ekipa odločila za precej napredne rešitve iz FOSS ekosistema, kar je zelo pohvalno. 

Izziv 1:  HA storage 

Eden od večjih izzivov je bila odločitev stranke, da uporablja lokalne diske na strežnikih prek local path provisionerja. Zelo težko je zagotoviti visoko razpoložljivost s takšnim pristopom. Stranka je uvedla GlusterFS, vendar to ni optimalna rešitev, saj Kubernetes tega sistema ne prepozna neposredno in provisioned volume ne delujejo ustrezno v kontekstu backup-a and recovery-ja

Naš predlog je bil, da se opusti GlusterFS in preide na kombinacijo CEPH + Rook. CEPH kot distribuiran sistem podpira široko paleto shranjevalnih naprav, Rook pa skrbi za njihovo upravljanje. Prav tako smo svetovali, da se storage v celoti preseli na ločen strežnik znotraj podatkovnega centra z možnostjo offsite varnostnega kopiranja – s tem smo naslovili tudi izziv DFS.

Izziv 2: Konfiguracija 

Drug izziv je bila vzpostavitev nadzora nad procesi v Kubernetesu, da bi avtomatizacija nenehno sledila pravilom, ki se jih ne sme kršiti. Stranka se je odločila za uporabo kombinacije orodij Falco in Kyverno. Vendar nobeno od teh orodij ni bilo konfigurirano preko demo nastavitev, kar samo po sebi ni napačno, vendar so ta orodja namenjena delovanju v dobro povezanem, setup-u. Težko jih je ustrezno nastaviti v razvojnem grozdu, ki še ni v celoti konfiguriran. Bilo je očitno, da razvojno okolje ni enako produkcijskemu. Naš izziv je bil integracija dveh policy management sistemov z dvema kompletoma pravil, ki bi skupaj delovala usklajeno. 

Izziv 3: Monitoring 

V analizi smo identificirali težavo z monitoringom v porazdeljenem sistemu – izpad posameznega node-a vpliva na celoten sistem. Stranka uporablja klasičen master-worker pristop, kjer ima vsako okolje enako število workerjev in vozlišč. Tako kot pri v okiru storage-a, je tudi monitoring občutljiv na odpovedi. Kaj storiti, ko odpove bare-metal strežnik ali je potrebno izklopiti node zaradi vzdrževanja?

Imeli smo dilemo, kje naj bo monitoring sploh umeščen. Monitoring ni bil premaknjen iz grozda, saj stranka tega v tej fazi projekta ni želela. Uporabljen je bil standardni Prometheus stack, ki ni bil namenjen distribuiranemu delovanju. Federacija obstaja, vendar ni zadostna rešitev. Naš predlog oziroma potrditev, do katere smo prišli skozi skupno razpravo, je bil uporaba Thanosa – distribuirane nadgradnje Prometheusa, ki omogoča obstoj neodvisnih instanc, ne glede na to, kje se nahajajo. 

Naša rešitev je temeljila na že predlaganem DFS pristopu, kjer je sloj shranjevanja ostal abstrakten, s čimer spremembe niso vplivale na neprekinjen pretok podatkov iz monitoringa. Thanos je postal de facto rešitev za celotno aplikacijo in vsa tri okolja, ko bo stranka pripravljena izločiti monitoring iz Kubernetes strežnikov. 

Izziv 4: Backup rešitev 

Rešitev, ki jo je stranka poskušala uporabiti za backup, se imenuje Velero. Gre za zrel backup projekt, ki omogoča varnostno kopiranje volumnov znotraj Kubernetesa, vendar to ni njegov primarni namen ali osnovna zamisel. 

Naš predlog je bil podoben razvojnemu pristopu, ki ga je ubrala stranka. Velero je sicer orodje za varnostno kopiranje, a je bilo sprva zasnovano kot rešitev za celovito varnostno kopiranje Kubernetes grozda kot sistema za orkestracijo kontejnerjev. Ker je Kubernetes sestavljen iz več komponent, ne obstaja integriran backup sistem, ki bi omogočal obnovitev popolnoma uničenega grozda. Velero rešuje to težavo tako, da premakne ključne konfiguracije na oddaljeno in varno varnostno lokacijo po izbiri uporabnika. V našem primeru je bila object storage, ki ga je stranka že uporabljala in se ni nahajal v istem podatkovnem centru.

Izziv 5: Backup volumnov

Na isti ravni kot izziv backup konfiguracij je bil tudi izziv backup podatkovnih volumnov. Na tej točki je v ospredje stopil Kanister – odprtokodni projekt, ki omogoča definiranje API-ja znotraj Kubernetesa v obliki virov, ki jih je mogoče klicati za izvajanje varnostnih kopij glede na specifične potrebe stranke. Kanister vključuje že pripravljene definicije za varnostno kopiranje različnih vrst podatkovnih baz: SQL, NoSQL, GraphQL, timeseries itd. Varnostno kopiranje običajne shrambe se definira kot Kubernetes job – enako velja za postopek obnove. 

Kaj smo se naučili 

Delo s tradicionalnimi tehnologijami v sodobnem času predstavlja velik izziv. Cloud-centric IT scena nas vse spreminja, vendar je vedno dobra vaja vrniti se h koreninam in razmišljati ročno – komponento po komponento. Tako tudi ugotovimo, da smo kot Ops še vedno združljivi z Dev načinom razmišljanja – kjer ena komponenta rešuje en problem. Takšen pristop decentralizira procese in omogoča, da sistem, ki morda deluje (navidezno) prekomerno robustno, v resnici deluje zelo dobro in je izredno odporen na katastrofalne scenarije.

Med projektom smo odkrili nova orodja, ki so uporabna v različnih situacijah – kot so Kanister, Reflector, Karpenter in Kyverno.

Ugotovili smo tudi, da vsaka distribuirana rešitev ni v vsakem primeru resnično distribuirana. Rešitve morajo biti zasnovane namensko za on-prem okolja – sicer se obnašajo kot preprosta unija virov, katerih delovanje je odvisno od tega, kdaj in kako so bili dodani. Takšna zbirka virov ni odporna – in posledično tudi ne posebej učinkovita.