🥇Kubernetes: avatud lähtekood vs kaubanduslik

Tere, minu nimi on Dmitri Krasnov. Olen juba üle viie aasta tegelenud Kubernetes klastrite haldamise ja keerukate mikroteenuste arhitektuuride loomisega. Sel aasta alguses käivitasime Kubernetes klastrihalduse teenuse Containerumi alusel. Kasutades seda võimalust, räägin, mis Kubernetes on ja kuidas integreerimine vendoriga erineb avatud lähtekoodiga lahendusest.

Alustuseks, mis on Kubernetes. See on süsteem, mis haldab konteinerite suurt hulka hoste. Kreeka keeles tõlgituna tähendab see "piloot" või "ruuner". Algusest peale on see välja töötatud Google'i poolt, pärast mida on see tehnoloogilise panusena antud Cloud Native Computing Foundation'ile, rahvusvahelisele mittetulunduslikule organisatsioonile, mis ühendab juhtivaid maailmatasemel arendajaid, lõppkasutajaid ja konteineritehnoloogiate pakkujaid.

Haldada suurt hulka konteinerite

Nüüd vaatame, mis need konteinerid on. Need on rakendused koos nende keskkonnaga – enamasti teekidega, millest sõltub programmi töö. Kõik see on pakkida arhiividesse ja esindada kujul pilti, mida saab käivitada sõltumata operatsioonisüsteemist, testida ja muu hulgas. Kuid probleem on see, et konteinerite haldamine suure hulga hostide peal on väga keeruline. Seetõttu loodi Kubernetes.

Konteineri pilt koosneb rakendusest ja selle sõltuvustest. Rakendus, selle sõltuvused ja operatsioonisüsteemi failisüsteemi pilt asuvad erinevates piltide osades, nn kihtides. Kihti saab taaskasutada erinevate konteinerite jaoks. Näiteks võib kõigi ettevõtte rakenduste jaoks kasutada baasikihti Ubuntu. Konteinerite käivitamisel pole vaja hostis hoida mitmeid koopiaid ühest baasikihist. See võimaldab optimeerida piltide säilitamist ja edastamist.

Kuna me tahame rakendust konteinerist käivitada, ladustatakse vajalikud kihid üksteise peale ja luuakse overlay failisüsteem. Ülemisele kihile kirjutatakse kiht, mis peatamisel kustutatakse. See tagab, et konteineri käivitamisel on rakendusel alati sama keskkond, mida ei saa muuta. See tagab keskkonna taasesitatavuse erinevatel host-operatsioonisüsteemidel. Olenemata sellest, kas tegu on Ubuntu või CentOS'iga, on keskkond alati sama. Lisaks on konteiner isoleeritud hostist Linuxi kerneli sisseehitatud mehhanismide abil. Kasti rakendused ei näe hosti ja naaberkonteinerite faile ega protsesse. Selline rakenduste isoleerimine host-operatsioonisüsteemist annab täiendava turvakihi.

Konteinerite haldamiseks hostil on olemas mitmesuguseid tööriistu. Kõige populaarsem neist on Docker. See võimaldab tagada konteinerite täisläbiviimisprotsessi. Kuid see töötab ainult ühel hostil. Kui on vaja hallata konteinereid mitmel hostil, võib Docker inseneride elu tõeliselt keeruliseks muuta. Seetõttu loodi Kubernetes.

Kubernetes'e nõudlikkus tuleneb võimalusest hallata konteineri gruppe mitmel hostil kui ühiseid üksusi. Süsteemi populaarsus tagab võimaluse luua DevOps või Development Operations, kus Kubernetes't kasutatakse DevOpsi protsesside käivitamiseks.

Joonis 1. Scheem Kubernetes'e tööpõhimõttest

Täielik automatiseerimine

DevOps tähistab põhimõtteliselt arenduse automatiseerimist. Lihtsalt öeldes, kirjutavad arendajad koodi, mis laaditakse reposse. Seejärel võib seda koodi automaatselt kasutada kohe konteineris koos kõigi raamatukogudega, testida ja "välja lasta" järgmistesse etappidesse – Staging, ja seejärel otse ka Productionisse.

Koos Kubernetes, DevOps võimaldab automatiseerida selle protsessi, et see toimuks peaaegu ilma arendajate vahelesegamiseta. Selle tõttu kiireneb kogumine oluliselt, kuna arendajal ei pea olema vajadust seda oma arvutis teha — ta kirjutab lihtsalt koodi, laadib koodi hoidlasse ja seejärel käivitatakse pipeline, mis võib sisaldada kogumise, testimise ja juurutamise protsessi. Ja see toimub iga commit'i korral, seega testimine toimub pidevalt.

Samas võimaldab konteinerite kasutamine olla kindel, et kogu selle programmi keskkond siseneb production'isse just sellises vormis, nagu seda on testitud. See tähendab, et ei tekki probleeme, nagu "testimise ajal olid ühed versioonid, production'is – teised, ja kui need peal, siis kõik purunes." Kuna tänapäeval on meil trend mikroteenuste arhitektuurile, kus ühe hiigelrakenduse asemel on kahesaja väikese rakenduse seas, vajaks nende käsitsi haldamiseks tohutut töötajate arvu. Seepärast kasutamegi Kubernetes't.

Plussid, plussid, plussid

Kui rääkida Kubernetes'e plussidest platvormina, siis tal on märkimisväärsed eelised mikroteenuste arhitektuuri haldamise seisukohalt.

Paljude replikate haldamine. Oluline on konteinerite haldamine paljude hostide peal. Ja mis veelgi olulisem — rakenduste mitme replikate haldamine konteinerites kui ühtse üksusena. Tänu sellele ei pea insenerid hoolima iga üksiku konteineri käimisest. Kui üks konteiner kukub, näeb Kubernetes seda ja käivitab selle uuesti.
Klastri võrk. Kubernetesel on samuti nii öeldud klastrivõrk oma aadressiruumi. Tänu sellele on igal pod'il oma aadress. Pod on klastris minimaalne struktuuriüksus, kus konteinerid käivitatakse. Lisaks on Kubernetesel funktsioon, mis ühendab endas koormuse jaotaja ja teenuse avastamise. See võimaldab vabastada IP-aadresside käsitsi haldamise ülesande Kubernetes'i õlgadele. Ja automaatsed tervise kontrollid aitavad probleemide avastamisel ning suunavad liikluse toimivatele pod'idele.
Konfiguratsioonide haldamine. Suure hulga rakenduste haldamisel muutub rakenduse konfiguratsiooni haldamine keeruliseks. Selleks on Kuberneteses olemas spetsiaalsed ConfigMap ressursid. Need võimaldavad keskse hoidla kaudu konfiguratsioonide salvestamist ja nende sisestamist podsides rakenduste käivitamisel. Selline mehhanism tagab konfiguratsiooni järjepidevuse, olgu need siis kümme või sada rakenduse koopiat.
Püsiv maht. Konteinerid on oma olemuselt muutumatud ning konteineri peatamisel hävitatakse kõik failisüsteemi salvestatud andmed. Kuid mõned rakendused salvestavad andmeid otse ketastele. Selle probleemi lahendamiseks on Kuberneteses võimalus haldada ketta salvestust — Püsivad mahud. See mehhanism kasutab väliseid andmesalvestusi, võib edastada konteineritesse püsivat, plokki- või failipõhist salvestust. Selline lahendus võimaldab andmeid hoida eraldi töötlusmasinatest, mis päästab need nende rikke korral.
Koormuse tasakaalustaja. Kuigi Kuberneteses hallatakse mehaanilisi üksusi, nagu Deployment, StatefulSet jne, käivituvad konteinerid lõppkokkuvõttes tavapärastes virtuaalmasinaid või füüsilistes serverites. Need pole ideaalsed ja võivad igal hetkel ebaõnnestuda. Kubernetes märkab seda ja suunab sisetrafiku teistele koopiatele. Aga mis juhtub välise liiklusega? Kui suunata liiklus lihtsalt ühe töötaja poole, siis mis juhtub, kui see kukub? Teenus muutub ju kättesaamatuks. Selle probleemi lahendamiseks on Kuberneteses saadaval Load Balancer tüüpi teenused. Need on mõeldud välise pilve tasakaalustaja automaatseks konfigureerimiseks kõikidele töötajatele klastris. See väline tasakaalustaja suunab välise liikluse töötajatele ning jälgib nende seisundit. Kui üks või mitu töötajat muutuvad kättesaamatuks, suunatakse liiklus teistele. See võimaldab luua kõrge kättesaadavusega teenuseid Kubernetesega.

Kubernetes näitab end parimal moel mikroteenuste arhitektuuride käivitamisel. Süsteemi rakendamine klassikalisse arhitektuuri on võimalik, kuid mõttetu. Kui rakendus ei saa töötada mitmes koopias, siis mis mõtet on – kas Kuberneteses või mitte?

Avatud lähtekoodiga Kubernetes

Avohanked Kubernetes on suurepärane: paigaldad ja see töötab. Sa saad seda käivitada oma füüsilistel serveritel, oma infrastruktuuris, paigaldada master ja worker'id, kus kõik rakendused käivitatakse. Ja kõige parem — kõik see on tasuta. Kuid on mõned nüansid.

Esimene nüanss on administraatorite ja inseneride teadmiste ja kogemuste nõudlikkus, kes neid kõik tootavad ja haldavad. Kuna klient saab klastris täieliku vabaduse, vastutab ta klastri töökindluse eest ise. Siin on kõik väga lihtsalt purunev.
Teine nüanss on integratsioonide puudumine. Kui käivitada Kubernetes, ilma et oleks mingit populaarset virtualiseerimisplatvormi, ei saa sa kõiki programmi eeliseid. Nagu näiteks Persistent Volumes'i ja Load balancer'i teenuste kasutamine.

Joonis 2. k8s arhitektuur

Kubernetes tarnijalt

Integratsioon pilveteenuse pakkujaga annab kaks võimalust:

Esiteks, inimene saab lihtsalt vajutada nuppu "loo klaster" ja saada juba seadistatud ja tööks valmis klastri.
Teiseks, tarnija paigaldab klastrit ja seadistab integratsiooni pilvega.

Kuidas see meil toimub. Insener, kes klastrit käivitab, näitab, kui palju tal vaja worker'eid on ja milliste parameetritega (näiteks, 5 worker'it, igaühel 10 CPU, 16 GB RAM-i ja ütleme 100 GB ketast). Pärast seda saab ta juurdepääsu juba loodud klastrile. Samal ajal kuuluvad koormust käivitavad worker'id täielikult kliendile, kuid kogu haldustasand jääb tarnija vastutusalasse (juhul, kui teenust pakutakse haldetud teenuse mudelina).

Siiski, sellisel lähenemisel on oma puudused. Kuna haldustasand jääb tarnijale, ei anna tarnija kliendile täielikku ligipääsu, mis vähendab Kubernetesega töötamise paindlikkust. Mõnikord juhtub, et klient soovib Kubernetesega integreerida mingi spetsiifilise funktsionaalsuse, näiteks LDAP kaudu autentimine, kuid haldustasandi konfiguratsioon ei luba seda.

Joonis 3. Näide Kubernetes klastrist pilveteenuse pakkujalt

Mida valida: avatud lähtekood või tarnija lahendus

Nii, avatud lähtekoodiga Kubernetes või kaubanduslik? Kui valida avatud lähtekoodiga Kubernetes, siis kasutaja saab teha sellega, mida soovib. Kuid on suur risk endale jalga tulistada. Kaubanduslikus versioonis on see keerulisem, kuna kõik on ettevõttes põhjalikult läbimõeldud ja seadistatud. Avatud lähtekoodiga Kubernetes'e suurimaks puuduseks on nõudmised spetsialistidele. Kaubanduslikus versioonis on ettevõte sellest peavalust vabastatud, kuid peab otsustama, kas maksta oma spetsialistidele või kaubanduslikule pakkujale.

Noh, plusse on veel, miinuseid teatakse ka. Üks asi jääb muutumatuks: Kubernetes lahendab hulga probleeme, automatiseerides mitme konteineri haldamist. Millise valida, avatud lähtekoodiga või kaubanduslik, otsustab igaüks ise.