Elengedem a fejlesztők kezét – Namespace as a Service

Tanzu-ról már írtam párszor és az azóta eltelt időben csak egyre jobban megerősödött bennem a szokásos érzés, hogy minél többet tanulok, kísérletezek, annál buttábbnak érzem magam – és sajnos vagyok is. Több ügyfél meg-megkérdezte tőlem mostanság hogy mi az a Tanzu és mit itt a nagy tudomány?

Teljesen igaz a mondás, hogyha nem tudod elmondani egyszerűen, akkor magad sem érted igazán. Szóval általában úgy fejezem ki a mellette szóló érveket és magyarázom a hype-ot, hogy alapvetően egy közös platform a víziója, amelyet a nem konténeres és konténeres alkalmazások használnak, oly módon, hogy a mélyében – amennyi látszik belőle – nem kell megváltoztatni semmit, nem kell túl sok új dolgot megtanulnia senkinek. Arra fejlesztették, hogy VMware admin számára ne legyen túl mély a konténerek adaptációja, a fejlesztők számára meg kis túlzással transzparens legyen mi van alatta.

Természetesen ha a motorháztető alá nézünk, akkor feljsejlik, hogy biztonsági szempontból olyan képességeket tud, amelyeket elég kevesen tud más. Az is kiderülhet, hogy átláthatóság szemponjából a natív Pod-ok futtatása – mikor nincs is worker node OS egy VM formájában – magán az ESXi kiszolgálón elképesztő lehetőségeket ad.

Maga a termék elég gyorsan halad, a vCenter/vSphere frissítésekkel együtt érkeznek az újabbnál újabb image-ek a Tanzu Content Library-jébe. Ezek gyakorta dobnak be olyan funkciókat, amik olyan képességeket tesznek lehetővé, hogy eddig lehetett nélkülük élni, de ezentúl nem.

Jelen bejegyzés arról szól el, hogy a fejlesztők kezét elengedjük, szóval hadd hozzak három példát arra, hogy éppen hol. A zebra előtt vagy a zebra után. Kezdem az utóbbival.

Zebra után

A VMware üzemeltetés feltelepíti a vCenter-t, az ESXi kiszolgálókat, az NSX Data Center-t (aka NSX-T) és végrehajtja a workload management bekapcsolását, melynek végeredménye a Supervisor klaszter és az ESXi kiszolgálók mint worker node-ok.

Létrehozz a VMware terminológia szerinti namespace-t és beállítja a kívánalmaknak megfelelően a:

  • jogosultságokat, hogy a vCenter SSO-n keresztül tudjanak authentikálni a fejlesztők.
  • a felhasználható kapacitást (CPU,RAM és tárterület)
  • a tárterület helyét – melyik datastore-on legyen.
  • a VM class-okat – hogy a VM as a Service és a TKG Guest klaszterek mit használhatnak
  • a releváns content library-t

Szóval a VMware admin meghatározza a namespace minden beállítását, maximális méretét, hogy milyen VM-eket kérhetnek majd benne, illetve megát a nevét. Ha belép rá, akkor a részleteket már látja is.

Ezen a ponton már a vSphere Pod-ok működnek is, de az vanilla K8s kell, akkor ki is görgethet a fent látható méretekből magának egyet/többet.

A kimenet alján látszik is a négy node állapota (1 control és 3 worker-t kértünk)

Az VMware adminisztrátor ebből kb ennyit lát – elég sokat, ami a Tanzu egyik előnye is.

Arra az “1”-re rákattinva kinyílik pár részlet. Alább maga a klaszter neve, verziója, mikor lett létrehozva, hány worker van benne, milyen az állapota és verziója, na meg mi a control plane IP-je.

A “Virtual Machines”-re kattintva látszik a VM class és a konkrét nevük.

Zebra előtt

Minden ami fent látható, de még a namespace-t sem hozza létre a VMware admin, csak egy template-et készít és majd megcsinálják maguknak. Érhetetlen, hogy ez miért klaszter szinten van és nem a workload management rész mögött de mindegy.

Ha átkattinjuk a fentit, akkor egy template létrehozását kell megtennünk. Mennyi CPU/RAM és tárkapacitást kap egy namespace.

Illetve, hogy kinek/kiknek, csoportoknak és felhasználóknak van joga namespace-t létrehozni és abban jogosultsággal bírni.

Sikeres beállítás után meg is jelenik amit beállítottunk és ezen a ponton már dobhatjuk is el a kaszát.

Szóval ha most authenikálunk be a supervisor klaszterbe, akkor egyenesen onnan tudunk létrehozni VMware terminológia szerint namespace-t.

Alább a GUI-n is látszil. Nyilvánvalóan a VMclass-okat és a content library-t is be kell állítani, mert ezeket még sajnos nem lehet kubectl-ből megtenni – egyelőre. Ugyanakkor ha natív vSphere Pod-ban dolgozunk, akkor arra nincs is szükség, azonnal használható ahogy van.

Természetesen VM-eket amelyen nem egy TKG klasztert szolgál hanem akár az alkalmazás olyan részét, amely nem konénerizálható – nem érdemes mindent konténerbe tenni csak azért mert most az a menő.

Korábbi cikkem a VM as a Service-ről.