Kubernetes Operátorok! Munkára fel!
Egy jó ideje már nem csak a dokkmunkások, hanem mi is, IT területen dolgozók, konténerekkel foglalatoskodunk. Ebből nem igen lehet kimaradni. A konténerizáció így vagy úgy, de mindenkit érint és utolér, legyen Dev, DevOps, vagy Sysadmin.
Ha erről a témáról beszélünk, nehéz nem megemlíteni két nevet: a Dockert és Kubernetest.
Egy jó ideje a csapból is Docker folyik. De tényleg 2013-ban kezdődött minden a Dockerrel? Az operációsrendszer szintű virtualizáció története egy kicsivel régebbre nyúlik vissza. A Docker fiatal korában még a jóval előbb, 2008-ban debütáló LXC (LinuX Containers) alapjain működött. Én magam a 2000-es évek közepén OpenVZ konténereket használtam a munkám során. A kezdetek pedig a 70-es évek végére tehetők, a chroot megjelenésére, legalábbis ami a Unix rendszert illeti. Ezzel mindjárt 40 évet ugrottunk vissza az időben. Számtalan olyan megoldás létezett és létezik, mint a Docker. Akkor miért pont a Docker lett a „befutó”?
Azt hiszem ennek egyik, ha nem a legnagyobb oka a Dockerhez köthető sztenderdizáció az operációsrendszer szintű virtualizáció területén. (Talán itt meg kellene említenem az ebben szerepet játszó szervezetek, cégek neveit, de ez itt nem a reklám helye, a Docker Inc. reklámozása a név miatt így is elkerülhetetlen.) A Dockert megelőzően minden fejlesztő vagy fejlesztői csoport egymástól függetlenül, saját elgondolások alapján fejlesztett. Nem igazán voltak ezen a területen szabványok, mindenki által megszívlelt interfész specifikációk.
A Docker (konténerformátum, futtatói környezet és ami még hozzá tartozik) meghatározó jelentőséggel bír, de mi a szerepe és helye ma? Ez hamarosan kiderül…
Ideje továbblépnünk, mert ha egy komoly rendszert akarunk építeni, akkor még szükség van valamire, ami igazgatja a konténereket; skálázza azokat, terheléselosztást valósít meg köztük és ezt ráadásul egy rakat számítógépen egyszerre, összehangoltan teszi. És „ő” az orkesztrátor, és ha úgy mondjuk „az orkesztrátor”, akkor az a Kubernetes.
Igen, természetesen léteznek más megvalósítások is, például a Docker sajátja a Docker Swarm vagy az Apache Mesos, de az ezek között zajló verseny pár éve már eldőlt, és egyértelműen a Kubernetes lett a befutó. A Kubernetes, aminek eredeti neve Seven of Nine (a Borg neve a Star Trek televíziós sorozatból) és amit 2014 nyarán nyílt forráskódúvá tett a Goggle, és átadta a Cloud Native Computing Foundation gondozásába.
Tehát, a Kubernetes menedzseli a klasztert; ő hozza meg a döntéseket, tartja fenn a kívánt állapotokat, automatikusan skáláz, és ennek megfelelően utasítja a Dockert, aki pedig szorgosan végrehajtja a feladatokat; indítja vagy épp leállítja a konténereket.
Aki már dolgozott Kubernetessel, az tudja, hogy rengeteg lehetőség, funkció van benne. Viszont egy olyan környezetben, ahol tiszavirág életű konténerek segítségével valósítunk meg mindent, nem könnyű olyan stateful alkalmazásokat kezelni, mint például egy adatbázis. Az ilyen alkalmazásokat gyakran a Kubernetes klaszteren kívül kezeltük a közelmúltig.
Ezen szösszenetnyi bevezető után jutottunk el a címben szereplő témánkhoz: Kubernetes Operátorok. Itt persze nem a Kubernetest kezelő személyzetről szeretnék értekezni, hanem a Kubernetes új lehetőségéről, amit Kubernetes Operators névvel illettek. Nem véletlen az elnevezés, hiszen a kezelőszemélyzet (operátorok) munkáját nagyban könnyítő és egyszerűsítő vagy inkább kiváltó lehetőségről, „bővítményről” van szó.
Maradva az eredeti példánál, az adatbázisnál, a megfelelő Kubernetes operátort használva, egy adatbázis klaszter létrehozása, működtetése, skálázása vagy frissítése már nem a kezelőszemélyzet fáradságos feladata lesz a Kubernetesben.
A Kubernetes ígérete az automatizálás és a Kubernetes Operátorok segítségével ez valósul meg egy új, sokkal magasabb szinten, mint eddig.
Úgy gondolom, hogy a konténerizáció a legdinamikusabban fejlődő és legizgalmasabb dolog jelenleg az IT területén belül. Érdemes belekeveredni!
A részleteket megismerheted és a gyakorlati tudást megszerezheted a Training360 kapcsolódó tanfolyamain!