Aki követi a munkásságomat tudja, hogy noha aláírom, hogy a Kubernetes tud hasznos lenni, óvatos optimizmussal közelítem meg a kérdést. Azt gondolom, hogy a nagy játékosok kivételével (telekommunkációs cégek, Silicon valley óriások, nagy áruházláncok) a Kubernetes használata sokszor gyakorlati problémákba ütközik, különösen a KKV szektorban.
Természetesen hivatkozhatunk arra, hogy a nagy háromtól (AWS, Google Cloud, Azure) kapunk Kubernetes szolgáltatást úgy, hogy nem kell vele foglalkozni, de ez így ilyen formában nem egészen igaz, hiszen egyrészt fizetnünk kell érte (és a Google pl. most emelt árat) másrészt könnyen lehet, hogy különböző jogi vagy politikai okokból az amerikai felhőszolgáltatók igénybevétele akadályokba ütközik. Így például a mai napig vita folyik arról, hogy a európai GDPR és az amerikai CLOUD Act ütközik-e egymással vagy sem.
Ugyanakkor a saját Kubernetes üzemszerű futtatása minden, csak nem egyszerű. A telepítést még csak-csak megoldják mindenféle eszközök helyettünk (például kubeadm, kubespray, stb), de a problémák megoldása már ránk hárul és nem kevés hozzáértést igényel.
Ez egész egyszerűen a Kubernetes jellegéből és alapötletéből adódik: ne úgy gondoljunk rá mint egy kész termékre, inkább úgy, mint egy csináld magad összeszerelőkészletre. Ezer és egyféle képpen összedughatjuk, és ha nem működik, akkor csak magunkra vethetünk. Ráadásul ha megnézzük a Cloud Native Foundation Landscape térképét elkezd jojózni a szemünk, hogy hány féle megoldásból választhatunk.
Itt jönnek be azok a megoldások amik nem egy legókészletet adnak a kezünkbe, hanem egy konkrét, jól összeépített megoldást biztosítanak. Természetesen itt a testreszabhatóság látja kárát, hiszen egy „opinionated” megoldást kapunk, azaz valaki elképzelését arról, hogy mi a jó.
k3s
Az egyik ilyen megoldás a Rancher háza tájáról érkezik és k3s névre hallgat. A Rancher már régóta biztosít egy jóval vastagabb, erőforrásigényesebb megoldást a Kubernetes futtatására és napi szintű menedzselésére, ám ez 4-5 gép magasságától indul és sok cégnek ez egyfajta infrastrukturális vízfejet jelent, amit nem szándékoznak kifizetni.
Nemrégen azonban kijöttek egy jóval izgalmasabb megoldással, a k3s-sel. Azért k3s, mert a k8s a Kubernetes rendes rövidítése és a 8-ast itt félbe vágták, jelezve, hogy ez fele annyit tud és fele annyi erőforrást eszik.
Mit is csináltak a Rancheres fejlesztők itt? Egyrészt fogták a Kubernetes futtatásához szükséges fél tucat szolgáltatást (controller-manager, apiserver, scheduler, stb.) és összecsomagolták egyetlen futtatható programba, másrészt kidobták a rendes megoldáshoz kapcsolt viszonylag erőforrásigényes etcd adatbázis szervert és betettek a helyére egy sqlite-ot. Ez természetesen a redundancia kárára megy, hiszen az sqlite nem tud adatot szinkron módon replikálni. De ez nem is baj, hiszen a k3s olyan 1-2 szerveres, vagy akár Raspberry Pi setupokhoz van kitalálva, ahol a vezérlést biztosító API rövid idejű kiesése nem okoz helyrehozhatatlan károkat.
Ami még izgalmas, hogy a normális, x509-es tanusítvány-alapú clusterezést kicserélték egy jóval egyszerűbb, token alapú mechanizmusra. Ezzel jelentősen leegyszerűsítették a szerverek összekapcsolását, ami egy szabvány Kubernetesnél mindig gondolkodást igényelt.
A gyakorlat
Nézzük tehát, hogyan is tudunk k3s-t használni a gyakorlatban. Először is szükségünk lesz egy kurrens LTS Ubuntu telepítésre. Természetesen Debian Busteren vagy Alpine Linuxon is el tudjuk indítani, de itt további lépésekre lesz szükség.
A telepítés pedig nem több mint egy egyszerű shell script amit a get.k3s.io címen találunk. A hivatalos doksi a következő parancssort javasolja:
1
curl -sfL https://get.k3s.io | sh -
1
Ezen a ponton nem szeretnénk itéletet mondani a webről letöltött scriptekről, ezt már rábízzuk a mindenkori üzemeltető filozófiájára. A mindenkori rendszerkövetelményeket pedig itt találja a kedves olvasó.
Miután a telepítő scriptet lefuttattuk, hozzávetőlegesen 30 másodperc múlva a kubectl get node parancs vissza fogja adni, hogy van egy kubernetes clusterünk és ebben egy node található. Ezen felül a processlistában ezt fogjuk látni:
1
/usr/local/bin/k3s server _ containerd -c /var/lib/rancher/k3s/agent/… /var/lib/rancher/k3s/data/ca752b211ccbacb1b66… _ /pause _ /coredns -conf /etc/coredns/Corefile /var/lib/rancher/k3s/data/ca752b211ccbacb1b66… _ /pause _ /metrics-server /var/lib/rancher/k3s/data/ca752b211ccbacb1b66… _ /pause _ /traefik –configfile=/config/traefik.toml /var/lib/rancher/k3s/data/ca752b211ccbacb1b66… _ /pause _ local-path-provisioner start –config /etc/config/config.json /var/lib/rancher/k3s/data/ca752b211ccbacb1b66… _ /pause _ /bin/sh /usr/bin/entry _ /bin/sh /usr/bin/entry
1
Tehát szépen elindult a k3s és telepített is az alapvető szolgáltatásokat, a kubectl parancs segítségével pedig máris deployolhatjuk az alkalmazásainkat.
Ha ezen felül kedvünk szottyan clusterezni, olvassuk ki a tokent a /var/lib/rancher/k3s/server/token fájlból, majd a másodlagos gépen vagy gépeken hajtsuk végre a következő parancsot:
1
curl -sfL https://get.k3s.io | K3S_URL=https://ELSODLEGES-SZERVER-IPJE-IDE:6443 K3S_TOKEN=NODE-TOKEN-IDEsh -
1
Ezzel az egyszerű művelettel máris van egy 2-3-4 node-os clusterünk.
Árnyoldalak
A Kubernetes hatalmas előnye nem csak abból származik, hogy tologathatjuk a containereket ide-oda, hanem abból is, hogy beszél a felhőszolgáltatókkal. Így például lehetőségünk van egy adatbázis szerver alatti tárhely (block storage vagy megosztott fájlrendszer) felcsatolására azon a gépen ahol az adatbázis szerver éppen fut.
A Kubernetes azonban nem varázslat és önmaga nem biztosít ilyen tárolási megoldást. Ha nem felhőben futunk és nincs helyi storage, akkor alapértelmezetten csak a gazdagépeken tudunk tárolni adatokat, ezzel a containerünket az adott géphez kötve.
Ez egy kisebb telepítésben még rendben van, de ha kiesésmentes karbantartásokat szeretnénk, akkor bizony-bizony a rendszer korlátaihoz érünk. Ez nem a k3s hibája, egyszerűen a Kubernetes arra épít, hogy egy olyan felhőben futunk, ahol lehetőségünk van a storage felcsatolására.
Szintén kérdéses, hogy a relatíve friss k3s projekt mennyi ideig fog támogatást kapni. Tovább fejlesztik-e, követik-e a Kubernetes őrületes tempóját a 3 havi kiadásokkal, 9 hónapos támogatási ciklusokkal, vagy a projekt hátszél hiányában el fog halni.
Nem kell túltolni
Kelsey Hightower, a Kubernetes és a cloud native egyik ismert szószólója vetette fel Twitteren nemrég, hogy nem toljuk-e túl egy picit ezt a kérdést. Nincs minden alkalmazásnak szüksége ultraelosztott, soha le nem álló redundanciára és dinamikus skálázásra. A személyes tapasztalatom ezen a téren az, hogy a kis- és középméretű projekteknek kisebb gondja is nagyobb mint hogy skálázzon.
Természetesen új és izgalmas az a világ, ahol betoljuk a kódot a gitbe, az automatikusan kiszáguld a felhőbe, automatikusan skálázódik fel-le, és a fejlesztő mindent megkap amire valaha is vágyott anélkül, hogy kellene ezzel foglalkozni, de lássuk be: ennek ára van.
Egy ilyen infrastruktúra iszonyatosan komplex és nem egy olyan Kubernetes debug projektben vettem részt, ahol a felkent Kubernetes szakértők és fejlesztők nem tudták megmondani, hogy mi a baj, majd a végén kiderült, hogy egy banális Linux hibáról van szó.
Azt gondolom, hogy a k3s és a testvérei (microk8s, stb) rengeteg projektnek pont megfelelőek, és némi kézi energiabefektetéssel egy Kubernetes clusterhez jutunk ahol el tudjuk kezdeni deployolni a cuccokat úgy, ahogy a nagyok, és ha tényleg feltaláltuk a következő Facebookot, könnyű lesz migrálni egy teljes méretű, hiperszuper clusterre.