kubernetes

Namų serverio konfigūracija keitėsi ne vieną kartą. Įprastini ų programinių servisų serveris buvo paverstas virtualiųjų mašinų serveriu, tuo pačiu pasitobulinant virtualizacijos žinias bei palaipiojant ant vienokių ar kitokių grėblių. Nuo to laiko praėjo daugiau, nei metų, o kompiuterijos srityje tai labai daug - ištisa amžinybė. Per šį laiką serveryje buvo pakeistos net kelios kartos diskinių kaupiklių, daugeliu atveju dėl kaupiklių gedimų. Taip kiekvieną kartą serverio talpykla po truputį augo, senuosius diskus po vieną pakeičiant naujais didesniais kaupikliais. Duomenis visuomet pavyko išsaugoti, nors kartą berods teko atkūrinėti pabirusią failų sistemą ir prisiminti, kad rezervines kopijas galima ne tik kurti, bet ir iš jų atsistatyti duomenis.

Po paskutinės migracijos serveryje buvo likę 3 diskai, kuriuose buvo sukonfigūruoti 3 RAID5 masyvai. Jau tuomet žinojau, kad konfigūracija nėra optimali, bet sistema, kaip ir veikė. Tuo metu visi servisai jau buvo išmigruoti į Docker programinius konteinerius, o virtualios mašinos sustabdytos. Palyginus su virtualiomis mašinomis, Docker konteineriai veikė gerokai sparčiau. Taip yra dėl kelių priežasčių. Pirmiausia, konteinerio procesų virtualizavimui reikia mažiau išteklių, nes programinio konteinerio struktūra yra paprastesnė, nei viso kompiuterio virtualizavimas. Antra, Docker konteineriai tiesiog naudoja serverio failinę sistemą, todėl bendrai paėmus reikia mažiau disko I/O operacijų, kurios trunka labai ilgai (palyginus su CPU skaičiavimo operacijomis).

Taigi laikas ėjo ir vėl ėmė niežėti nagus, nes prieš keletą metų ant technologijų bangos buvęs Docker buvo išstumtas ir dabar naudojamas tik, kaip konteinerių paleidimo technologija bei kūrimo įrankis. O konteinerių infrastruktūros valdymo srityje dabar yra vienvaldis lyderis - Kubernetes. Tuo pat metu pribrendo laikas dar vienai serverio modernizacijai bei Kuberntes klasterio sukūrimui. Tiesa, kol kas klasterio dydį apribotas vienu serveriu, tačiau tai netrukdo naudoti Kubernetes privalumais. Vienas pagrindinių privalumų yra serviso teikimo užtikrinimas, kurį su Docker Compose teko spręsti įvairių Shell scenarijų ir sistemos servisų kokteiliu. Bet apie tai kitą kartą. Vos tik įdiegus Kubernetes ir numigravus pirmuosius Docker Compose servisus į Kubernetes, paaiškėjo, kad serveris ėmė veikti vėžlio greičiu, o sistemos apkrovos lygis nuolat pakildavo virš 4-5.

DNS vardų sistema yra labai svarbi bet kurios kompiuterinių tinklų sistemos dalis, įskaitant ir „Kubernetes“. Vidiniam tinklo adresų valdymui „Kubernetes“ naudoja „CoreDNS“ vardų sistemos serverį, kuris puikiai susitvarko su konteinerių tinklo sistemos ypatumais. Vienas jų - vidinių „Kubernetes“ tarnybų ir konteinerių adresų valdymas. Kiekvienas „Service“ tipo objektas „Kubernetes“ tinkle gauna savo DNS įrašą ir jį galima pasiekit tiek pirmojo lygio vardu: „serviso_vardas“, tiek antrojo: „serviso_vardas.vardu_sritis“, tiek ir „pilnu“ (FQDN vardo gale turi būti taškas) vardu: „serviso_vardas.vardu_sritis.svc.cluster.local“. Taip supaprastinamas „Kubernetes“ pritaikytų programinių sistemų kūrimas, nes pakanka žinoti sukurto serviso vardą ir programa galės naudotis tos tinklo tarnybos paslaugomis, nes „CoreDNS“ pasirūpins IP adreso suradimu ir bus galima užmegzti tinklo ryšį.

Tačiau prireikus rasti išorinės sistemos IP adresą, pavyzdžiui, konteineriui prireikus atlikti paiešką „Google“ paieškos sistemoje, pasireiškia tinklo vardų radimo subtilybės. Gavęs „google.com“ užklausą, konteineris nieko nežino apie „Google“, nes jo požiūriu tai yra bandymas rasti „google“ „Service“ tipo objekto adresą, „com“ vardų srityje. Tik nepavykus rasti tokio įrašo visuose klasterio „search domains“ domenų aprašuose, ši užklausa bus siunčiama į išorinius DNS vardų serverius, vienas kurių gali būti vietinio tinklo DNS serveris. Ir štai čia vietinio tinklo DNS serveris gali „pakišti kiaulę“, įtraukdamas savo vietinio tinklo domeno, pavyzdžiui, „home.lan“ į „Kubernetes“ „search domains“ sąrašą. Nepavykus rasti „google.com“ „Kubernetes“ tinkle, suformuojama užklausa rasti „google.com.home.lan“ adresą. Savaime suprantama, kad namų tinkle tokio adreso nėra. Tačau užuot atsiuntusi „NXDOMAIN“ atsakymą, nurodantį, kad įrašo rasti nepavyko ir reikia bandyti toliau, t.y. ieškoti tikro išorinio adreso, tinklo maršrutizatoriaus „DNSMasq“ tarnyba kažkodėl gražindavo „NODATA“ atsakymą. Tai sutrikdydavo vardų paieškos bandymų seką, konteineris nebeieškodavo „google.com“ domeno, nuspręsdamas, kad toks vardas neegzistuoja.

Tingintiems skaityti toliau - problemą pavyko išspręsti tinklo maršrutizatoriaus „DNSMasq“ programoje išjungus „Do not cache negative replies, e.g. for non existing domains“ nuostatą. Ją išjungus, „DNSMasq“ ėmė teisingai gražinti NXDOMAIN atsakymą ne tik neegzistuojantis.home.lan adresui, bet ir antro.lygio.home.lan ar google.com.home.lan adresams. Tiesa, gali būti, kad buvo kažkoks laikinas sutrikimas, nes dabar net ir įjungus šią nuostatą, DNS sistema gražina teisingą NXDOMAIN atsakymą. Na, o besidomintys DNS viduriais, gali skaityti toliau.

Migracija iš paprastų konteinerių į „Kubernetes“ buvo pradėta gan seniai ir prieš keletą mėnesių buvo sėkmingai užbaigta, kai į „Kubernetes“ persikėlė paskutinės tarnybos, tokios kaip „Transmission“ ir „Minecraft“. Žinoma, tobulinti dar yra ką - didelė dalis tarnybų naudoja „host network“ tinklo ryšius bei "host path" tipo duomenų saugyklas. Visa tai turės būti pakeista į labiau „Kubernetes“ klasteryje įprastus „Ingress“ ir „Persistent Volume“ išteklius. Tačiau iki šiol visas „Kubernetes“ klasteris buvo sudarytas iš vieno kompiuterio ir tai ėmė kelti savų iššūkių. Pirmiausia, kartais tiesiog jau ėmė  trūkti kompiuterio išteklių. Be to, turint vieną kompiuterį - nelabai yra galimybių išsibandyti apkrovos balansavimo technologijas. Todėl atėjo laikas klasterio plėtrai.

Kadangi elektra šiais laikais yra gan brangus išteklius, net ir turintiems Saulės elektrinę, todėl įprastiniai duomenų centrų serveriai, neretai srebiantys po pusę kilovato ar daugiau, nebuvo svarstomi. Tuo labiau, kad nors kiek ekonomiškesnių serverių kainos yra gerokai aukštesnės, nei norėčiau išleisti namų duomenų centrui, kuris neneša tiesioginių pajamų. Todėl jau kokį pusmetį žiūrinėjau į mažųjų kompiuterių pasiūlą. Galiausiai buvo apsispręsta, kad serverinėje spintoje turės įsikurti 3 mažieji „Lenovo ThinkCentre M93“ kompiuteriai. Šie mažyliai su 8GB RAM, 200GB SSD disku ir i7-4765T procesoriais pastebimai padidins „Kubernetes“ klasterio skaičiavimo pajėgumus, neiškeldami elektros sąnaudų į kosmosą. Kad ir kokia apkrova būtų - jie nepajėgūs naudoti didesnę, nei 65W galią, nes tik tiek gali tiekti jiems elektrą tiekiantys nešiojamųjų kompiuterių maitinimo šaltiniai. Todėl sumoje šie trys kompiuteriai neturėtų naudoti daugiau, nei 220W.

Taigi, po pusdienio darbo, iš kurio didžiąją dalį sugaišau kurdamas USB laikmeną sistemos diegimui (nes iš vienos laikmenos sistema užsispyrusiai nenorėjo krautis), ant stalo sukrauta tapo mano „Kubernetes“ klasterio dalimi. Tiesa, kol kas kompiuteriams dar nėra priskirta jokia rolė, nes įdiegus sistemą, kompiuteriai buvo išjungti ir supakuoti į dėžę. Klasterio plėtimas atidedamas iki kito savaitgalio, nes tvarkingai išvedžioti už kompiuterių matomą kabelių „kūšį“ reikia laiko.

$ kubectl  get nodes
NAME      STATUS   ROLES                  AGE     VERSION
k8s1      Ready    <none>                 119m    v1.23.0
k8s2      Ready    <none>                 9m17s   v1.23.0
k8s3      Ready    <none>                 8m23s   v1.23.0
vm-serv   Ready    control-plane,master   670d    v1.23.0