Kada smo dobili zadatak da za jednog klijenta uradimo full audit Kubernetesa, prvi put smo se susreli sa scenarijem u kome je Kubernetes potpuno on-prem, na fizičkim mašinama u klasterima, i čeka produkciju, odnosno finalno zeleno svetlo. Da sve bude interesantnije, klijent je bio MVNO u Nemačkoj. Telefonija i Kubernetes su definitivno nešto što se ne sreće svaki dan.
Zahtevi klijenta su bili naizgled prosti. Dobićemo read-only pristup dev klasteru, napravićemo detaljan popis svega sa opisom funkcionisanja da bismo bili sigurni da razumemo kako radi njihov sistem, procenićemo da li su odabrana rešenja adekvatna – ako nisu, predložićemo alternative.
Zvuči jednostavno. Vremenski zahtevno, ali jednostavno.
Mi smo mislili da jeste.
Nismo bili u pravu.
Kao tim smo navikli na cloud – na sve sitnice koje ga karakterišu i sve pogodnosti koje pruža. Blago iznenađenje doživeli smo kada smo (sasvim očekivano) otkrili da neki resursi nisu „klaudoliki”. Dvojac koji je radio na ovom projektu ima zbirno oko 40 godina iskustva u IT-u koje datira pre cloud-a. Nije nam dugo trebalo da shvatimo da smo se vratili na old school sistem i da bi trebalo tako i da razmišljamo.
Relativno lako smo došli do pristupa dev klasteru i uverenja da su dev, staging i buduća produkcija isti, osim razlika koje će nam biti revnosno predočene na vreme.Sam klaster je pratio filozofiju da svaki best practise segment zahteva svoje rešenje. To je dovelo do instalacije mnogo komponenti u Kubernetes, jer je svaka imala svoju ulogu.
Naša prvo pitanje je bilo; da li su sve ove komponente zaista neophodne?
Kada smo ga postavili programerima, dobili smo odgovor zasnovan na tipičnom programerskom razmišljanju: sve se posmatra kao zasebna celina i svaki zahtev koji mora da se ispuni je jedna komponenta. Ne može se reći da je ovaj način razmišljanja pogrešan.
Ops pristup podrazumeva da se pravi skelet i instalira što manje, a da se koristi sve što se može koristiti. U slučaju našeg klijenta, pristup je bio da svaka potreba bude podmirena posebnim, adekvatnim rešenjem. Kako nismo mogli da ga osporimo, probali smo da se prilagodimo.
Za početak je trebalo da razumemo šta i kako klijent radi i na koji način im funkcioniše aplikacija. Premda smo dobili app diagram koji je pratilo objašnjenje, morali smo da ručni prođemo kompletnu unutrašnju komunikaciju komponenti da bismo razumeli sve odnose unutar Kubernetesa i samog stack-a.
Kako je priroda aplikacije komunikacija i razmena informacija, jasno je da je sve potpuno sigurno i da se odvija u okviru klastera. Obzirom da read-only pristup dozvoljava samo pregled resursa, ali ne i uspostavljanje sesije ka njima, oslonili smo se na analizu resursa i config fajlova koji stoje kao config mape. Imena servisa, ingress-i i endpointi su samo neki od aspekata koji su nam kroz konfiguraciju otkrili koji servis komunicira sa čime. U toku analize otkrili smo da su se timovi odlučili za prilično cutting-edge rešenja i i da su sva bila iz FOSS ekosistema, što je jako pohvalno.
Kao jedan od izazova izdvojio bih odluku klijenta da koristi lokalne diskove na serverima kroz local path provisioner. Jako je teško koristiti storage na taj način a da bude u HA. Klijent je podigao GlusterFS, što nije najbolje rešenje jer Kubernetes nije svestan toga i provisioned volumi ne mogu da rade kako treba u smislu backup-a and recovery-ja.
Ovo smo rešili predlogom da se napusti GlusterFS i da se pređe na kombinaciju CEPH + Rook. CEPH kao distribuirani sistem može da uveže široku paletu storage-a, a Rook da njima upravlja. Naš predlog je takođe bio da se storage u potpunosti izmesti na poseban server u okviru data centra koji može da se bekapuje offsite, čime smo adresirali izazov DFS-a.
Drugi izazov je bio da se obezbedi kontrola procesa unutar Kubernetesa kako bi automatizacija procesa kontantno pratilapravila koja ne sme da prekrši. Klijent je odabrao kombinaciju Falco i Kyverno kao rešenje. Nijedan od njih nije bio konfigurisan dalje od demo pravila, što je prihvatljivo, ali je problematično što su ova rešenja predviđena da rade u zrelom setup-u – uvezano. Teško ih je konfigurisati na dev klasteru koji nije u potpunosti podešen. Bilo je jasno i da dev okruženje nije isto kao produkciono. Naš izazov je bio da uvežemo dva policy managementa, što smo i predložili sa dva seta polisa koje zajedno funkcionišu.
U analizi smo otkrili problem distribuiranog monitoringa na koji može da utiče pad nekog node-a. Naime, klijent koristi master-worker setup u kome svako okruženje ima isti broj workera i nodova. Poput storage-a, i monitoring pati od iste boljke. Šta kada nešto neminovno otkaze na bare metal serveru ili neki node mora da se ugasi radi maintenance-a?
Imali smo dilemu gde da stoji monitoring. Klijent nije bio voljan da u ovoj fazi projekta izmesti monitoriing u klaster servera. Odabrano rešenje je bio standardni Prometheus stack, koji nije zamišljen da bude distribuiran. Doduše, postoji federacija, ali to nije rešenje problema. Naš predlog, tj. potvrda kroz zajedničku diskusiju, bio je da se koristi Thanos – distribuirani overlay nad Prometheus-om koji dozvoljava da postoje nezavisne instance istog bez obzira gde se nalaze.
Naše rešenje se oslanjalo na korišćenje DFS-a koji smo predložili i podrazumevalo je da storage layer ostane apstraktan celom sistemu i da promene na nivou istog nemaju nikakve posledice po konstantan priliv podataka od monitoringa. Thanos je bio defacto rešenje za kompletnu aplikaciju i sva tri okruženja u momentu kada klijent bude odlučio da izmesti monitoring stack van Kubernetes servera.
Rešenje koje je klijent pokušao da koristi za backup se zove Velero. Reč je o zrelom bekap projektu koji ima mogućnost bekapovanja volumena u Kubernetesu, ali mu to nije primarna namena niti zamisao.
Naš predlog je bio nalik developerskom pristupu klijenta. Naime, Velero jeste backup rešenje, ali inicijalno zamišljeno da radi sveobuhvatan bekap Kubernetes klastera kao sistema za orkestraciju kontejnera. Kubernetes se sastoji iz niza komponenti i ne postoji integrisan sistem za bekap koji će dozvoliti da se uradi restore klastera koji je bespovratno oštećen. Velero rešava taj problem tako što sklanja vitalne konfiguracije na izmeštenu i sigurnu bekap lokaciju po izboru. U našem slučaju to je bio object storage koji je klijent već koristio i koji se ne nalazio u istom data centru.
Na istoj liniji backup izazova je bio backup volumena. Tu je na scenu studio Kanister, open-source projekat koji dozvoljava da se definiše API unutar Kubernetesa u vidu resursa koji se poziva i radi bekap na način na koji klijentu treba. Kanister dolazi sa definicijama za bekapovanje baza podataka raznih vrsta. SQL, NoSQL, GraphQL, timeseries, itd. Backypovanje prostog storage-a se definiše kao job, baš kao i restore.
Raditi sa tradicionalnim tehnologijama je veliki izazov u modernom dobu. Cloud-centric IT scena nas sve menja, ali je uvek dobra vežba vratiti se korenima i razmišljati manuelno, komponentu po komponentu. Tu i vidimo kako smo zapravo kao Ops i dalje kompatibilni sa Dev delom, i kako njihov pristup da jedna komponenta rešava jedan problem zapravo decentralizuje procese i čini da sistem koji deluje (nepotrebno) robusno zapravo može da radi izuzetno dobro i da bude veoma otporan na katastrofične scenarije.
U toku projekta smo otkrili nove alate koji su korisni za različite situacije, kao što su Kanister, Reflector, Karpenter i Kyverno,
Naučili smo i da svako distribuirano rešenje nije distribuirano u svakoj situaciji. Nešto mora da bude namenski osmišljeno za on-prem situacije, inače se ponaša kao prosta unija sa resursima koji zavise od toga kada su i kako dodati. Takav skup resursa nije otporan i samim tim nije mnogo efikasan.
Kontaktirajte nas na business@mainstream.eu ili popunite našu kontakt formu.
Partnerstvo između Mainstream-a i HC Center-a predstavlja sinergiju inovativnih cloud rešenja i stručnosti u digitalnoj transformaciji, pružanje naprednih usluga za ubrzanje digitalizacije u Jugoistočnoj Evropi.
Otkrijte kako sprovesti pregled Kubernetes okruženja koji prevazilazi osnovne kontrolne liste. Identifikujte bezbednosne rizike, optimizujte performanse i prioritizujte popravke na osnovu stvarnog uticaja.
Razvoj aplikacija na cloudu omogućava niže troškove, bržu isporuku, veću sigurnost podataka i fleksibilnu skalabilnost, uz pojednostavljeno upravljanje infrastrukturom.
Mainstream je najveći provajder inovativnih cloud rešenja i managed hosting usluga sa mrežom od 10+ data centara u jugoistočnoj Evropi.
Mainstream 2012-2025 Sva prava zadržana.
HC Center i Mainstream su zvanično udružili snage
