🥇Kubernetes: avatud lähtekoodiga vs. tootja

Tere, mina olen Dmitri Krasnov. Juba üle viie aasta olen tegelenud Kubernetes klastrite haldamise ja keerukate mikroteenuste arhitektuuride ülesehitamisega. Selle aasta alguses käivitasime Kubernetes klastrite haldamise teenuse, mis põhineb Containerumil. Kasutades juhust, räägin natuke, mis täpselt on Kubernetes ja kuidas erineb integratsioon teenusepakkujaga avatud lähtekoodist.

Alustuseks, mis on Kubernetes. See on süsteem konteinerite haldamiseks paljude hostide peal. Kreeka keeles tõlgituna tähendab see "piloot" või "juht". Alguses arendas seda Google, seejärel anti tehnilise panusena üle Cloud Native Computing Foundationile, mis on rahvusvaheline mittekasumitootav organisatsioon, mis ühendab juhtivaid maailmas arendajaid, lõppkasutajaid ja konteineritehnoloogiate tarnijaid.

Konteinereid juhtida

Nüüd vaatame, mis need konteinerid ikkagi on. Need on rakendused koos kogu nende keskkonnaga – peamiselt raamatukogadega, millest rakenduse töö sõltub. Kõik see on pakitud arhiividesse ja esitatud kujul, mida saab käivitada sõltumatult operatsioonisüsteemist, testida ja palju muud. Kuid probleem on selles – paljude hostide peal konteinerite haldamine on väga keeruline. Seetõttu loodi Kubernetes.

Konteineri pilt on rakendus koos selle sõltuvustega. Rakendus, selle sõltuvused ja operatsioonisüsteemi failisüsteemi pilt asuvad erinevates piltides, nn kihtides. Kihti saab taaskasutada erinevate konteinerite jaoks. Näiteks võib kõikide ettevõtte rakenduste puhul kasutada põhikihti Ubuntu. Konteinerite käivitamisel ei ole vaja hostis hoida mitmeid koopiaid ühest ja samast põhikihtidest. See võimaldab optimeerida hoidmist ja piltide tarnimist.

Kui soovime käivitada rakendust konteinerist, paigutatakse vajalikud kihid üksteise peale ja moodustatakse ülekandefailisüsteem. Peale asetatakse kirjutamiskiht, mis eemaldatakse konteineri peatamisel. See tagab, et konteineri käivitamisel on rakendusel alati sama keskkond, mida ei saa muuta. See tagab keskkonna reprodutseeritavuse erinevates hostide operatsioonisüsteemides. Olgu see siis Ubuntu või CentOS – keskkond on alati sama. Lisaks on konteiner isoleeritud hostist Linuxi kärude kaudu. Konteineris olevad rakendused ei näe hosti või naaber konteinerite faile ega protsesse. Selline rakenduste isoleeritus hosti operatsioonisüsteemist pakub lisakihi turvalisust.

Konteinerite haldamiseks hostis on palju tööriistu. Kõige populaarsem neist on Docker. See võimaldab tagada konteinerite täieliku elutsükli. Siiski töötab see ainult ühe hostiga. Kui on vaja haldada konteinerite mitmeid hoste, võib Docker muuta inseneride elu põrguks. Seetõttu loodi Kubernetes.

Kubernetes'e nõudlus tuleneb võimalusest juhtida konteinerigruppide hulki paljude hostide peal kui ühtseid üksusi. Süsteem on populaarne, kuna see võimaldab luua DevOps või arendustegevuse, kus Kubernetesit kasutatakse nende DevOps protsesside käivitamiseks.

Joonis 1. Schemaatiline kujutis Kubernetes'e tööprintsiibist

Täiuslik automatiseerimine

DevOps on põhimõtteliselt arenduse automatiseerimine. Lihtsalt öeldes kirjutavad arendajad koodi, mis laaditakse repole. Seejärel võib kood automaatselt kokku panna konteineriks koos kõigi raamatukogadega, testida ja "üles laadida" järgmisse etappi – Staging, ja seejärel otse Productionisse.

Kubernetes'i ja DevOps'i abil saab seda protsessi automatiseerida, et see toimuks praktiliselt ilma arendajate enda osaluseta. Selle tulemusena kiireneb koostamine suuresti, kuna arendaja ei pea seda oma arvutis tegema – ta kirjutab lihtsalt koodi, pushib selle repole ning käivitub pipeline, mis võib hõlmata koostamise, testimise ja üles laadimise protsessi. Ja see toimub iga commit'i korral, seega toimub testimine pidevalt.

Konteineri kasutamine tagab, et kogu selle programmi keskkond jõuab tootmisse just sellisena, nagu seda testiti. See tähendab, et ei teki probleeme, nagu „testides olid ühed versioonid, tootmises – teised, ja kui installisime, kukkus kõik kokku“. Tänapäeva müügis on mikroteenuste arhitektuuri trend, kus ühe suure rakenduse asemel on sadu väikeseid. Nende käsitsi haldamiseks on vajalik suur töötajaskond. Seetõttu kasutamegi Kuberneteset.

Plussid, plussid, plussid

Kui rääkida Kubernetesest platvormina, siis sellel on olulised eelised mikroteenuste arhitektuuri haldamise kontekstis.

Paljude replikate haldamine. Oluline on konteinerite haldamine paljude hostide vahel. Veelgi tähtsam on paljude rakenduste replikate haldamine konteinerites kui ühtse tervikuna. Tänu sellele ei pea insenerid muretsema iga eraldi konteineri pärast. Kui üks konteiner kokku kukub, märkab Kubernetes seda ja käivitab selle uuesti.
Klastri võrk. Kubernetesel on ka nn klastri võrk oma aadressiruumiga. Selle tõttu on igal podil oma aadress. Pod tähendab klastris minimaalset struktuuriühikut, kus käivitatakse konteinerid. Lisaks on Kubernetesel funktsionaalsus, mis ühendab endas koormuste tasakaalustaja ja teenuste avastamise. See vabastab käsitsi IP-aadresside haldamisest ning usaldab selle ülesande Kubernetesesse. Automaatilised tervisekontrollid aitavad tuvastada probleeme ja suunata liiklust töötavatele podidele.
Konfigureerimise haldamine. Paljude rakenduste haldamisel muutub rakenduste konfiguratsiooni haldamine keeruliseks. Selleks on Kubernetesel spetsiaalsed ConfigMap ressursid. Need võimaldavad keskse hoidla olemasolu seadistuste jaoks ja asetada need rakenduste käivitamisel podidesse. Selline mehhanism garanteerib konfiguratsiooni järjepidevuse, olgu siis kümnes või sajas rakenduse replikas.
Püsivoltid. Konteinerid on oma olemuselt muutumatud ja konteineri peatamisel hävitatakse kõik failisüsteemi salvestatud andmed. Kuid mõned rakendused salvestavad andmeid otse kettale. Selle probleemi lahendamiseks on Kubernetesel kettahaldussüsteem – Püsivoltid. See mehhanism kasutab välist andmesalvestust, suudab edastada konteineritesse püsiva, plokk- või failisalvestuse. See lahendus võimaldab andmeid hoida eraldi töötajatest, päästes need töötajate tõrgete korral.
Koormuse tasakaalustaja. Kuigi Kuberneteses haldame abstraktseid üksuseid nagu Deployment, StatefulSet jne, käivitatakse konteinerid lõpuks tavalistes virtuaalmasinatel või füüsilistes serverites. Need pole ideaalsed ja võivad igal ajal kokku kukkuda. Kubernetes märkab seda ja suunab sisemise liikluse teistesse replikatesse. Kuid mis saab liiklusest, mis tuleb väljastpoolt? Kui liiklus suunatakse lihtsalt ühe töötaja juurde, mis juhtub, kui see kukub? Selles olukorras oleks teenus mitteaktiivne. Selle probleemi lahendamiseks on Kuberneteses teenused nagu Koormuse tasakaalustaja. Need on mõeldud automaatseks välise pilvkoormuse tasakaalustaja seadistamiseks kõigi klastris olevate töötajate jaoks. See väline tasakaalustaja suunab välise liikluse töötajatele ja jälgib nende olekut. Kui üks või mitu töötajat muutuvad mitteaktiivseks, suunatakse liiklus teistele. See võimaldab luua Kubernetese abil kõrgelt kergesti kätkivaid teenuseid.

Kubernetesest ilmneb parim just mikroteenuste arhitektuuride rakendamise korral. Süsteemi juurutamine klassikaliseks arhitektuuriks on võimalik, kuid mõtetu. Kui rakendus ei saa toimida mitmes replikas, siis mis mõte on – kas Kuberneteses või mitte?

Avatud lähtekoodiga Kubernetes

Avatud lähtekoodiga Kubernetes on suurepärane asi: paigaldad ja see töötab. Seda saab käivitada oma füüsilistel servade, oma infrastruktuuri peale, seadistades meistrid ja töötajad, kellel toodetakse kõik rakendused. Ja mis kõige tähtsam – kõik on tasuta. Siiski on nüansse.

Esiteks – nõudlikkus teadmiste ja kogemuste osas administraatoritest ja inseneridest, kes seda kõike juurutavad ja toetavad. Kuna klient saab klastris täielikku tegutsemisvabadust, kannab ta vastutust klastrite töökindluse eest. Ja siin on kõik väga lihtne purustada.
Teiseks – integratsioonide puudumine. Kui käivitada Kubernetes ilma mõne populaarse virtualiseerimistehnoloogiata, siis ei saa kõiki programmi eeliseid, näiteks Püsivoltide ja koormuse tasakaalustajate teenuste kasutamist.

Joonis 2. K8s arhitektuur

Kubernetes tarnija

Pilveteenuse pakkujaga integreerimine avab kaks võimalust:

Esiteks, inimene saab lihtsalt vajutada nuppu "loo klaster" ja saada juba seadistatud ja tööks valmis klaster.
Teiseks, tarnija loob klastrit ja seadistab integreerimise pilve.

Kuidas see meil toimub. Insener, kes klastrit käivitab, ütleb, kui palju tal on vaja töötlejaid ja milliste parameetritega (näiteks 5 töötlejat, igaühel 10 CPU, 16 GB RAM-i ja ütlemegi 100 GB ketast). Pärast seda saab ta juurdepääsu juba moodustatud klastrile. Sellega, et töötlejad, millel koormus käivitatakse, antakse täielikult kliendile, kuid kogu haldamise tasandi jääb tarnija vastutusalasse (kui teenus pakutakse hallatud teenusena).

Siiski, sellisel skeemil on oma puudused. Kuna haldamise tasand jääb tarnijale, ei anna tarnija kliendile täielikku juurdepääsu, mis vähendab paindlikkust Kubernetesega töötamisel. Mõnikord juhtub, et klient tahab Kubernetesega liita mingi spetsiifilise funktsionaalsuse, näiteks autentimise läbi LDAP, kuid haldamise tasandi konfiguratsioon ei luba seda teha.

Joonis 3. Näide pilveteenuse pakkuja Kubernetes klastrist

Mida valida: avatud kood või tarnija lahendus

Nii et, avatud koodiga Kubernetes või tarnija lahendus? Kui võtta avatud koodiga Kubernetes, siis kasutaja teeb sellega, mida tahab. Kuid on oht endale kahjustada. Tarnija lahendusega on see keerulisem, sest ettevõtte jaoks on kõik läbimõeldud ja seadistatud. Kõige suurem avatud koodiga Kubernetes'e puudus on nõudmine spetsialistidele. Tarnija lahenduse korral vabastatakse ettevõte sellest peavalust, kuid tal tuleb otsustada: maksta oma spetsialistidele või tarnijale.

Noh, plussid on ilmsed, miinused on samuti tuntud. Üks asi jääb muutumatuks: Kubernetes lahendab hulga probleeme, automatiseerides paljude konteinerite haldamist. Millise valida, avatud koodiga või tarnija lahendus, on igaühe enda otsustada.