Szerző: Gálffy Csaba

2015. július 23. 18:50

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.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak

Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

Nagy pénz, nagy szívás: útravaló csúcstámadó IT-soknak Az informatikai vezetősködés sokak álma, de az árnyoldalaival kevesen vannak tisztában.

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.

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról