A Dockert, mint konténeres technológiát ma már nem nagyon kell bemutatni senkinek. Néhány szót azért érdemes róla ejteni, hogy azok is képbe kerüljenek, akik esetleg még nem találkoztak vele. Ha a Dockert már kellően kiveséztük, rátérhetünk a Kubernetesre is. Megnézzük, hogy mi áll a nemi betegségre utaló név mögött, miért érdemes használni, mit ad nekünk pluszba, amit a Docker önmagában nem tud.

Amiket érinteni szeretnék a cikk során:

• Mi az a Docker
• Milyen problémák merülnek fel a Dockerrel kapcsolatban
• Mi az a Kubernetes, mit ad nekünk az orchestration?

Felületesen a Dockerről

A Docker nem más, mint egy szoftvertechnológia, amely operációs rendszer szintű virtualizációt biztosít számunkra. Ez nagyon tudományosan hangzik, azonban egyszerű megérteni az alábbi ábra segítségével:

 

A konténerek és a virtuális gépek hasonló erőforrás izolációs és allokációs előnyökkel járnak, de funkcionálisan kicsit különböznek. Az ábrán jól látható, hogy a fizikai szerverre telepített ‘Host OS’ mind a két megoldás esetében megtalálható, azonban a fölötte lévő réteg már különbözik. Amíg a virtuális gépeknél egy ‘Hypervisor’ segít a virtualizációban, addig a konténerek esetében ‘Host OS’ és a kernel maga segít elszeparálni egymástól környezeteinket. A konténerek nagy előnye, hogy a virtuális gépekkel ellentétben, nincs minden konténerben külön virtualizálva a teljes operációs rendszer, csak a ‘Host OS’-től eltérő komponensek (binárisok, könyvtárak, stb.). Ezzel jelentős erőforrást takaríthatunk meg magunknak. Kevesebb felesleges tárhely és memória felhasználás amely az operációs rendszereket szolgálja ki. Minek legyen 3x telepítve egy operációs rendszer, ha azok sokszor teljesen azonosak? Szeparálhatjuk egymástól az operációs rendszeren futó alkalmazásokat is, így megspórolva 2 réteget, magát a ‘Hypervisort’ és a ‘Guest OS’-t, amely a virtuális gépek esetében szükséges.

A konténerek nagy előnye, hogy platformokon átívelően rendkívül könnyen hordozhatók. Egyformán futnak Linuxos és Windowsos környezetben, de a bare-metal és a cloud sem okoz problémát. Végre mindenki teljesen egyforma környezeten dolgozhat anélkül, hogy izzadni kellene érte.

Ahhoz, hogy egy működő konténert kapjunk, először is definiálnunk kell azt, hogy mit szeretnénk a konténerben látni. Szükségünk van egy leírófájlra, ami Docker esetében a Dockerfile. Ez a fájl írja le azt, hogy mi kerüljön majd bele a Docker image-be buildet követően.

Egy rendkívül egyszerű Apache Tomcat Dockerfile: https://medium.com/media/f38ea4c2b24a63d7f393c2b0552b777a

Ezt a Dockerfile-t aztán tárolhatjuk lokálisan gépünkön, valamilyen SCM rendszerben, pl. GitHubon vagy feltölthetjük a Docker Hub-ra, ami egy publikus registry (tároló, ha úgy tetszik), ahonnan aztán mindenki számára elérhetővé válik.
Ha készen vagyunk a Dockerfile írásával, jöhet a build, amikor is a fájlból egy image készül. Ebből az image-ből tudjuk majd elindítani a számunkra szükséges konténereket.

Ez mind szép és jó, de van itt egy kis probléma… Ha valaki már túljutott a fenti dolgokon és szeretné production környezetében is élvezni a konténerek előnyét, biztosan belebotlott néhány problémába…

Docker hiányosságai — miért van szükségünk konténer orchestration megoldásra?

Amikor elkezdünk fejleszteni egy terméket, legtöbb esetben felépítünk egy fejlesztői, valamint QA környezetet tesztelési céllal. Ezen környezetek futhatnak egyetlen node-on is, de a production más tészta. Biztosítanunk kell jó néhány dolgot, amelyet DEV és QA környezetben nem feltétlen szükséges (de jó ha van).

Nem árt, ha a környezetünk hibatűrő és igény szerint skálázható. Az sem árt, ha a változások visszavonhatók, esetleg downtime nélkül. Az is jó, ha a környezetben futó elemek képesek egymást felderíteni és tudnak egymással kommunikálni. A konténer orchestration ezekre a dolgokra kínál megoldást egybe csomagolva. Ilyen orchestration eszköz a Kubernetes is, amely jelenleg a piac legnépszerűbb szereplője.

Kubernetes — production-re kész konténer orchestration

A Kubernetes egy open-source megoldás konténereink automata deploymentjéhez, skálázáshoz és menedzseléshez.
A Google által indított projekt mögött 15+ év tapasztalat van csak a Google oldaláról és egyik hatalmas előnye a közösség, amely segíti és támogatja a projektet. Jelenleg a Cloud Native Computing Foundation (CNCF) alá tartozik, ők fogják össze a munkálatokat.

Kubernetes által az alábbi előnyökhöz juthatunk kevés befektetett energiával:

• A konténereket futtató hostok clusterként kezelhetők
• Konténereink központilag, tetszőleges hostokon tudjuk szétszórni
• Különböző hostokon futó konténerek összekapcsolhatók, egyben tarthatók
• Állandó erőforrás felügyelet és optimalizálást biztosít a konténerek skálázásával és áthelyezésével
• Alkalmazásainkat automatikusan, leállás nélkül terjeszthetjük, frissíthetjük
• Végrehajtott frissítések és terjesztések visszavonhatók
• Magas rendelkezésre állás a cluster által

A fenti előnyök mellett azonban van még egy fontos dolog, ami sokak számára döntő érv lehet a bevezetésnél. Ha úgy döntünk, hogy egy cloud providernél építünk környezetet és nincs platform független megoldásunk a terheléselosztásra valamint a skálázásra, akkor kénytelenek vagyunk a cloud provider által biztosított PaaS/SaaS megoldásokat használni. Ezzel azonban megkockáztathatunk egy esetleges röghözkötést, amikor is már hiába lenne kifzetődő másik szolgáltatást választani, a szükséges migrációs terhek már értelmetlenné tennék az egészet. Kubernetes segítségével konténereink skálázása és terheléselosztása platformfüggetlen maradhat.

Amennyiben szeretnél többet megtudni a Kubernetesről, javaslom a hivatalos dokumentációt, amely szépen leír mindent, amire szükség lehet. Ha pedig tetszett a bejegyzés, nézz vissza később is, szó lesz még a Kubernetes architektúráról, kiegészítőkről és a Helm-ről.