Darbas su konteineriais turi daug privalumų – jie paleidžiami lengvai ir greitai, juos galima patogiai nusiųsti kam nors kitam ir be didelių problemų paleisti kitame kompiuteryje. Konteinerizacija vis dažniau naudojama ir programuotojų tarpe, o pokalbiuose apie ją neišvengiamai išgirstame „Kubernetes“ raktažodį.

Pasikalbam, kas tos Kubernetes yra, kada jas verta naudoti ir iš kur jos išvis atsirado. O gal tai tik dar viena madinga technologija, kuri greitai pasens?

Vienas konteineris yra gerai. O jeigu turėtume 100 jų?

Įsivaizduokime tokią situaciją – savo projekte pradėjome naudotis konteinerizacija. Kompiuteryje galime lengvai paleisti visą konteinerizuotą aplinką – po vieną front-end‘ui, back-end‘ui, duomenų bazei, na ir kiekvienai papildomai technologijai, kurią naudojame. Paleidome projektą neįrašant jokių naujų programų, nereikėjo medžioti specifines PHP versijos, gaišti laiko įrašinėjant duomenų bazių valdymo sistemą... Ir susimąstome – ar negalėtume to paties padaryti šio projekto staging ar production serveriouse? Tiesiog ten įrašyti Docker, paleisti konteinerius ir valio?

Atsakymas yra „Taip, bet...“. Pradžioje viskas nuostabu – paleidome konteinerius, truputį pakonfigūravome serverį, kad kreipiantis tam tikru domenu atidarytų konteineriuose esantį projektą. Viskas veikia. Bet tada ateina metas naujos projekto versijos deployment‘ui, ir matome, kad su „pliku“ Docker tai nėra taip lengva. Tada pradedame galvoti, kad norime turėti kelis serverius mūsų projektui, kad išvengtume downtime‘o ir kitų potencialių problemų, be to, atsiranda iššūkių sinchronizuojant duomenis ir konfigūracijas tarp kelių serverių. O jeigu mums reikia turėti kažkokią technologiją, kuri bus naudojama visų šių serverių, tai kur ją laikyti – viename iš esamų serverių ar pakelti atskirą? O kas bus, jei reikės serverius migruoti...?

Didėjant konteinerių ir virtualių mašinų kiekiui, didėja tinklo sudėtingumas, kaina ir klaidų tikimybė. Šiems iššūkiams yra sukurta nemažai sprendimų – Rancher, Nomad ar pačių Docker kūrėjų Docker Swarm. Tad kodėl šie pavadinimai daugumos yra žinomi rečiau, o Kubernetes pavadinimas minimas taip dažnai?

Už visko slypi Google

Kaip dažnai pasitaiko, už nereto IT sprendimo kyšo Google ausys. Google jau turėjo savo cluster manager‘į pavadinimu Borg, kurį viduje naudojo dar 10 metų prieš paleidžiant pirmąją Kubernetes versiją. Dauguma pirmųjų Kubernetes kūrėjų buvo žmonės, dirbę su Borg, tad jų pamatą kūrė profesionalai su kone dešimtmečio patirtimi. Ir tai tikrai jaučiasi – kad ir koks klausimas iškyla klasterio konfigūravimo metu, jis tikriausiai jau buvo kažkieno apgalvotas ir būtent jam jau buvo sukurta kokia nors implementaciją.

Prie populiarumo prisideda ir tai, kad Kubernetes yra atviro kodo ir prie jo tobulinimo svariai prisideda bendruomenė, o pačios sistemos valdymą Google perdavė CNFC (Cloud Native Computing Foundation).

Be to, veikia ir „snowball“ efektas. Jei nuspręsime naudoti kokį nors cloud provider‘į, tikėtina, kad jie jau teiks paslaugą Kubernetes klasterių kūrimui ir valdymui. Iškart atkrenta papildoma atsakomybė galvoti, kaip tinkamai paruošti virtualių mašinų sistemą. Tą laiką galime išnaudoti jau paties klasterio konfigūravimui.

Kai už technologijos slypi tokia ilga istorija, sunku teigti, kad tai tik trumpalaikis trend‘as. Netgi atvirkščiai – per 7 metus nuo pirmosios versijos išleidimo Kubernetes tik populiarėjo. Daug sunkiau yra įsivaizduoti, kas galėtų jas nukonkuruoti.

Praktinis pavyzdys

Tiek tos istorijos, bet reikia ir pakalbėti, kaip Kubernetes naudojamos praktikoje. Turėti konteinerius be Kubernetes yra kaip turėti augalų sėklas be daržo. Žinoma, galima tas sėklas mesti bet kur, ir gali būt kad jos užaugs sveikos be didesnės priežiūros. Bet vieną dieną gali nutikti nelaimė ir ateiti stiprus lietus, kuris visus šiuos augalus suniokos, ir jų jau niekaip neatstatysim. Būtent taip ir atsitiktų, jei paleistume vieną vargšą konteinerį į produkciją, ir tikėtumės, kad jis atlaikys įvairius nenumatytus veiksnius, pavyzdžiui, padidėjusį lankytojų srautą.

Tokiai situacijai tiktų Kubernetes „Deployment“ tipo resursas, kurio aprašymo pavyzdžių apstu Kubernetes dokumentacijoje. Kad turėti tris konteinerio replikas, užtenka prirašyti konfigūraciniame faile eilutę „replicas: 3“. Visą kitą „Deployment“ resursas jau padaro už jus! Naujo konteinerio paleidimo metu pamatysite, kad Kubernetes kuria naują pod‘ą (resurso tipą, kuriame gyvuoja konteineris) šalia senojo veikančio pod‘o, ir pradeda naudoti naująjį tik tada, jeigu jis sėkmingai pasileido. Jei naujas konteineris negali pasileisti, klasterio viduje pamatysite du pod‘us – senajį, kuris toliau veikia, ir naująjį, kuris negalėjo pasileisti.

Šitaip mes net galime patikrinti, kokias klaidas išmetė neveikiantis pod‘as, kad sužinotume, ką reikia taisyti. O jeigu kas nors įvyks „po kapotu“, tikėtina kad jūs apie tai niekad ir nežinosit, kadangi Kubernetes automatiškai viską perdarys, kad programa toliau veiktų su likusiais veikiančias ar naujai priskirtais node‘ais.

Lengva išmokti, sunku įvaldyti

Tiesa, ne viskas čia taip paprasta. Dažnai gilinantis į Kubernetes komponentus, pasijaučiu lyg žiūrėčiau į mechaninio laikrodžio vidų – tiek daug detalių, ir visos svarbios ir turi savo paskirtį.

Nors ir pradėti naudotis technologija yra gana paprasta, neapsigaukite – čia visada yra kažko naujo išmokti. Jeigu rimtai žiūrite į Kubernetes naudojimą savo produkcinėms aplinkoms, pagalvokite ir apie tai, kas bus atsakingas už jų priežiūrą.

Tai ar man reikia projektuose pradėti naudoti Kubernetes?

Norint suprasti, ar verta naudoti Kubernetes, pirmiausia reikia įvertinti, ar konkrečiam tikslui pasiekti būtinos šios technologijos siūlomos galimybės. Jeigu jūsų programa monolitinės architektūros, tiesiog sukišus ją į konteinerį ir paleidus Kubernetese, vargu ar gausite naudos. Tačiau Kubernetes puikiai pritampa prie mikroservisų architektūros programų.

Pastebiu, kad programuotojai dažnai pasimeta, ar Kubernetes atneš privalumų lokaliam naudojimui projektams su Docker. Dažniausiai – ne, tai veikiau bus „overkill“. Žinoma, „bendram išprusimui“ raginu pasidomėti, kaip realiai veikia tie klasteriai. Tam galite atsisiųsti Minikube, o tada pabandykite sukonfigūruoti klasterį kokiame AWS‘e. 

Jeigu esate IT architektas, įvertinkite, ar Kubernetes tiks su dabartine programų architektūra bei įmonės kultūra – įvertinkite, ar pas jus jau yra puoselėjama DevOps kultūra, ar visgi žengiate per platų pirmą žingsnį.