Kész a Kubernetes, indulhat a konténeres világ
Hatalmasat lökött a konténeres alkalmazásfuttatás és az OpenStack szekerén is a Google. Kifejlesztette a Kubernetes menedzsmentplatformot a konténeres appokhoz, majd azonnal szabadon is engedte. És erre ráhúzva beállt az OpenStack-támogatók sorába. Mi folyik itt?
Három nagy fontos bejelentést tett a héten a Google, legalábbis az automatizált-virtualizált adatközpontokkal foglalkozó szakemberek számára. Az első: elkészült a Kubernetes (ejtsd: kübernetész) 1.0-s kiadása, a Docker konténerformátum alá fejlesztett eddigi legígéretesebb menedzsmentfelület. A második bejelentéssel a Google a fejlesztését gyorsan közkinccsé is tette, a fejlesztést a jövőben egy független iparági testület, a Cloud Native Computing Foundation irányítja majd. A harmadik (időben az első) pedig a Google belépése az OpenStack Foundation támogatói közé – ami egy újabb hatalmas lökést ad majd az SDDC-platformnak. Vegyük sorra ezeket.
Kubernetes 1.0
A Dockerről már többször írtunk, a technológia lehetővé teszi, hogy az alkalmazásokat csinos, hordozható konténerekbe csomagoljuk az összes függőségükkel együtt, és így, ebben a formában futtassuk azokat. A megoldás nyilván szerveroldalon izgalmas, ahol a bevett logika ma az egy alkalmazás - egy VM, sőt, egyes szereplők még tovább mentek, a monolitikus alkalmazást mikroszolgáltatásokra (microservices) bontották és ezeket futtatják dedikált virtuális gépeken. A megközelítés azért jó, mert így az alkalmazások egységként kezelhetőek és menedzselhetőek, a rendszerrel együtt indíthatóak újra, skálázhatóak, a függőségek nem akadnak összes, stb. A hátrány: a sok VM párhuzamos futtatása meglehetősen erőforrásigényes, adott esetben több rendszer (kernel plusz meghajtók plusz extrák) teljesen redundáns futtatására nincs szükség.
A Docker jobb megoldásnak tűnik ugyanerre a problémára. Itt az egységet maga az alkalmazás és a függőségei (könyvtárak, futtatókörnyezetek, stb.) alkotja, ez a csomag pedig az operációs rendszeren fut, normálisan. A konténer azonban minden olyan képességet megörököl, amit a VM+app csomag tudott korábban, az egyetlen megoldásra váró problémának az alkalmazások biztonsága tűnik – míg VM-VM között a kommunikáció kényelmesen szabályozható, a közös gazdarendszeren futó két konténer jelenleg nincs ennyire hermetikusan elzárva egymástól.
De van még egy probléma a Dockerrel, ez pedig a menedzsmentréteg hiánya. A VM-ekhez az elmúlt tíz évben világszínvonalú szoftverkörnyezetek készültek, amelyek több tíz vagy több tízezer VM kezelésére is tökéletesen alkalmasak – indítás-leállítás, migrálás, hálózat és egyéb problémák kezelése ma már megoldottnak számít. A Docker esetében erről szó sincs jelenleg, a konténerformátum mögött nincs skálázódó menedzsment.
Könnyű kitalálni, hogy ez lett a Kubernetes, amellyel a Linuxon futó konténerek egységes rendszerként üzemeltethetőek, mérettől szinte függetlenül. Az egy központra kötött konténerek logikusan rendszerezhetőek, migrálhatóak a csomópontok között, és nyilván fontos szempont az automatikus skálázódás, ha újabb instance-ekre van szükség, akkor újabb konténerek indíthatóak be igény szerint.
Független, nyitott technológia
Az igazi puccsot azonban azzal hajtotta végre a Google, hogy a Kubernetest szabadon engedte és az érett, éles bevetésre is ajánlott verziót független irányítás alá helyezte. Miért puccs ez? Mert ezzel a potenciális felhasználók számára a Google garantálta, hogy a Kubernetes egy platform- és gyártófüggetlen, általánosan használható és általános célú menedzsmentplatform marad. Ez pedig nagyon fontos üzenet a vendor lock-intől rettegő ügyfelek felé. "Ha Kubernetest használsz Google Compute Engine-en, akkor az egész rendszert viheted az Amazonhoz is, vagy bárhová, ahol támogatott a rendszer" - adhatjuk a keresőóriás szájába.
A független Cloud Native Computing Foundation tagjait jelenleg a Google, a Joyent és a Mesosphere adja, a támogatók között pedig megtaláljuk az IBM-et, a Huawei-t, a Ciscót, az Intelt, a VMware-t és számtalam más céget, a projekt fölött pedig a Linux Foundation őrködik. Ez egyelőre elegendőnek látszik, hogy a kritikusokat elhallgattassa - ez tényleg elég nyitott lesz.
Google + OpenStack
A fentiekkel együtt pedig komoly áttörésként értékelhető, hogy a Google is csatlakozott az OpenStack Foundation támogatói köréhez. A keresőóriás az egyik legnagyobb hiányzó volt az OpenStack mögött felsorakozó cégek közül, belépésével alapvetően változik meg a felhős rendszerek dinamikája - persze ez attól függ, hogy a Google tényleg komolyan gondolja-e a kezdeményezés támogatását.
CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.
Hogyan illeszkedik az OpenStack a Docker-Kubernetes világképbe? Leginkább kiegészíti azt, lefelé, a csupasz vas felé. A konténeres alkalmazások alatt ugyanis továbbra is vannak operációs rendszerek (és ezek jellemzően VM-ek), ezeket pedig továbbra is rendszerbe kell szervezni a hálózattal és a tárolókkal (és számtalan más kisebb-nagyobb szolgáltatással), ezt végzi el az OpenStack.
Van már kezdeményezés egyébként az OpenStack-féle menedzsment és a Kubernetes összekapcsolására, hogy a teljes rendszer egyetlen központi szoftverből legyen kezelhető, ennek neve a Magnum. Ez még viszonylag kezdeti fázisban jár, a Google-OpenStack összeborulás nyomán azonban várhatóan lendületet nyer majd a kezdeményezés, logikus következő lépés lesz ugyanis a két menedzsment-réteg összeforrasztása - ilyen vagy olyan formában.