Ez az egész olyan távol áll tőlem, mint Makótól Jeruzsálem. De az élet nem habostorta, ha olyat kell tanulni, amihez még érintésem sincs, akkor nem szabad befeszülni – annyira. Szóval van itt ez a konténerizációs téma, amely körül a megoldások, termékek és általában minden egyéb kapcsolódó dolog olyan gyorsan változik, mint Napon a foltok. Anélkül hogy dekódolnám a VMware Tanzu porfólióját, illetve megpróbálkozzak vele, az egyszerűbb oldaláról közelítek.
Vadon Péter kollégám amúgy is írt errről, itt:
vSphere 7 megjelenésével a VMware Cloud Foundation-ben elérhetővé vált a konténerek futtatása kicsit integráltabb módon mint addig bármikor. Sokáig nem váratott magára a lehetőség, hogy már VCF sem kell hozzá, mindenki próbálkozhat aki vSphere 7-en van.
És ez az a pont, ahol három lehetőség van:
- HAproxy
- NSX-T
- AVI LB (Ez jelent meg a vSphere 7.0 U2-vel, amiben az AVI load balancer használható már Basic szinten és így a HA proxy legnagyobb problémája, hogy nem redundnáns, kiküszöbölésre is kerülhet.)
A HAproxy irány nem tud redundáns lenni ezért én nem látom létjogosultságát produktív környezetek esetében. Ebből nem lehet kettő egy telepítésben, tehát ha egy ESXi elköszön, akkor a HA majd elindítja egy másikon, közben pedig semmi sem elérhető a konténerizációban.
Az NSX-T termékkel kiegészítve adja a Tanzu a legmagasabb funkcionalitást, de ennek ára van, hiszen licenszelni kell azt is.
A HAproxy redundanciájának hiányát a VMware azzal küszöbölte ki, hogy a korábbi felvásárlásából az AVI load balancer-t a Tanzu árában foglalva használhatóvá és támogatottá tette. Tehát inkább e kettő utóbbi opció között tudok javasolni implementációkat.
Visszatérve a funkcionalitásra, a legnagyobb feature az NSX-T mellett, hogy csak ezzel lehetséges a vSphere pod képesség, tehát ezzel natívan az ESXi hosztokon futhatnak a konténerek, ezzel vizibilitást, emelt biztonságot és még magasabb teljesítményt lehet elérni. Ez utóbbiból fakad az is, hogy a beépített Harbor registry is csak NSX-T segítségével használható, leginkább azért, mert az is vSphere pod-ként – több pod-ként – fut.
Opció 1 – HAproxy
Kétségtelen, hogy a legegyszerűbben és leggyorsabban a HAproxy opcióval lehet lejutni a kész környezet előllításában.
Szükséges dolgok:
- három ESXi hoszt
- 2 db content library:
– egy a PhotonOS/Kubernetes verziókért
– egy a HAproxy verziókért - Legalább kettő „szegmens” – javasolt a három inkább:
– manamement: Itt hallgat a HA Proxy API-ja.
– workload: a HAproxy control plane itt éri el a supervisor klaszter és a TKG klaszterek szolgáltatásait. Ha nem adunk meg harmadik „szegmenst”, akkor itt lesznek az LB VIP-ek is.
– opcionális (frontend): Innen osztana ki load balancer IP-ket a konténerek számára.
Opció 2 – NSX-T
NSX-T esetén komolyabb előkészületekre van szükség, mert end-to-end nem automatizált a telepítés. Egy VMware Cloud Foundation-ban az és egy fenti HA proxy-s megoldásnál is egy vSphere 7 alaptelepítés elég, hogy a Workload Management-ből telepíthető legyen . NSX-T használatához fel kell telepíteni a három NSX-T Manager/Controller-t, a hosztokra telepíteni az NSX-T-t, EdgeVM(eket) beállítani, Tier 0-t létrehozni. És ekkor lehet csak elkezdeni a vCenter-ből a telepítést.
- Large Edge VM kell
- Edge Cluster – és benne T0
Egy NSX-T hez mi kell hálózati szempontból – ide értve az ESXi által használt hálózatokat is?
- Management VLAN
- vMotion VLAN – ez mondjuk opcionális
- TEP VLAN – ami immáron lehet azonos a hosztok és az Edge-ek számára
- Uplink VLAN(ok)
- és persze két olyan IP tartomány, amelyet sehol máshol nem használunk a tágabb környezeten kívül. Ezeket az NSX-T fogja majd hirdetni.
Ha lehetséges, akkor a vCenter legalább proxy-n keresztül, de férjen hozzá az internethez, mivel szükség van a fentebb is említett content library-re is, amibe a template-ek folyamatosan szinkronizálódnak – periodikusan.
Amennyiben ez készen van, akkor megkísérelhető a telepítés. Tízből, háromszor egyből működik minden, még hibát sem ír. A maradék hét esetből hatszor hibára fut, a maradék egyben pedig kicsit mérgelődik, de végül jól feltelepül.
Opció 3 – AVI
Ez az amit még nem volt időm tesztelni, egy hete jött ki a lehetőség.
Sikeres telepítés után
NSX-T opcióval telepítettem, de jó része az alábbiaknak HAproxy és AVI esetén is hasonló.
Sikeres telepítés után előáll a Supervisor klaszter. Ezt a klasztert három virtuális gép reprezentál és ezek előtt a gépek előtt lesz egy load balancer is. Ezen a load balanced IP-n keresztül érhető el úgy minden, a széles körben ismert kubectl parancssal.
vCenter felületén így néz ki
A Control Plane Node mezőben a Supervisor klaszter VIP címe látható, ide lépünk be majd a kubectl segítségével. Látható még a fenti képen, hogy az vSphere klaszterben 4 darab ESXi hoszt van, illetve a bal oldalon hogy nincs egyetlen namespace sem.
Itt felhívnám a figyelmet a – véleményem szerint téves – elnevezésre, mert a konténerek világában is van namespace fogalom és most itt is, de a kettő teljesen mást, ráadásul nem is kapcsolódót jelent.
Hosts and clusters nézeben látszik a három VM és a Monitoring tab-on pár részlet, mint a futtatott Kubernetes verzió – ami itt 1.19.1 – illetve a nem három, hanem hét node. Bizony, minden egyes ESXi hoszt is egy node, hiszen képes konténerek futtatására.
NSX-T felületén így néz ki
Létrejött pár objektum, Tier-1 gateway-ek, NAT szabályok, DFW szabályok, Virtual Server-ek. Minden amit alább látunk, az módosíthatatlan, csak a Workload management állítgathatja, illetve a kubectl-ből indított akciók változtathatnak. A telepítése az alábbi elemeknek teljesen automatikus.
Alább a NAT, szóval nyilván nem akarunk NAT-olni azon a szegmensen, amelyekben majd a workload-ok lesznek. Aztán SNAT, hogy a kifelé menő kommunikációt majd milyen forrás mögül végezze a rendszer.
Load balancer-ek
Virtual server-ek, melyek közül az alábbit emelném ki. Az itt látható két porton érjük el a supervisor klasztert. Ezeken keresztül dolgoznak a fejlesztők is majd.
Kubectl-ből így néz ki
Az authentikáció a vCenter Server-rel történik, így redundancia szempontjából tehát ez a Tanzu jelenlegi leggyengébb pontja – ez az én véleményem. Tehát mindenki, adminisztrátor, fejlesztő a vCenter Server-ben konfigurált tartományok ellenében történik. Tehát ha a vCenter frissül, újraindul, problémája van, akkor senki sem fog éppen bejelentkezni. Meglévő kapcsolatok nyilvánvalóan nem lesznek érintettek, de azért jó tudni.
Tehát itt alább látszik, hogy milyen kontextus van és megmutatom, hogy milyen node-okat lát. Itt hasonlóan a vCenter irányából látottakhoz, látszik a három supervisor node és a négy ESXi hoszt.
Namespace létrehozása
Itt a VMware terminológia szerinti namespace-ről beszélek. Ez körülbelül egy haladóbb resource pool. Tehát adni kell neki egy nevet – ékeze és speciális karakter ne legyen – méghozzá DNS compliant nevet. Ez a kifejezés midenhol visszaköszön majd, T1-től kezdve szegmensek nevén át a LB-ig.
Alább rögvest a létrehozás után, el is mondja mire jó ez:
- milyen storage policy-vel rendelkező datastore-ok vehetők igénybe majd
- ki és milyen jogosultsággal bírhat
- korlátokat lehet szabni a CPU/RAM és tárolási felhasználásnak
- mindenképpen kell content library – a fentebb beállítottat is lehet használni
Alább bekonfigurálva látszik minden.
Nézzük meg Hosts and cluster nézetben mi történt. Na az látszik, ami előbb is. A bal oldalon megjelent a namespace, a jobb oldalon pedig pont az az ablak ami a workload management-ben is látszott.
NSX-ben látható is az újonnan létrejött T1 gateway.
Új szegmens is létrejött számára, egyelőre nincs benne semmi.
NAT is konfigurálódott
És persze load balancer – egyelőre nulla virtual server-rel.
Jelentkezzünk be kubectl-el. Látszik is a létrehozott „namespace”.
Ezen a ponton már lehetséges vSphere Pod-ok futtatása. Elindítok egy nginx-et, négy példányban.
vCenter-ben már meg is jelenik, azonos névvel – innen már sejthető hogy ezek natív pod-ok. Természetesen egy replica set-be is teszi őket.
NSX-ben létrejön a szükséges virtual server és a cluster IP-n elérhető lesz a TCP/80-on az Nginx.
A vizibilitás magáért beszél.
Íme a weboldal.
Tanzu Kubernetes Guest klaszter
A vSphere Pod több szempontból többet tud, de nem tekinthető upstream K8s-nek. Ha az kell, akkor TKG klaszterekben kell gondolkodni. Ezek virtuális gépek által reprezentáltak és ebből fakadóan a control plane és a worker-ek is méretezhetőek. Ezekben teljesen konform érintetlen Kubernetes fut.
Egy control plane node-ot és három worker-t kértem – kubectl parancssal – és meg is jelennek a vCenter-ben.
Nyilván az ehhez szükséges komponensek NSX-ben is létrejönnek, de talán a legfontosabb, hogy a TKG klaszer control plane-je is kap egy load balanced IP-t.
Ebbe a kontextusba lépve már mást mutat a node-okból.
Az nginx-es példa a TKG klaszterbe történő deployment-je után így néz ki:
vCenter-ben azonban ennek nyoma sincs, hiszen a worker VM-eken belül futnak az nginx konténerek. Itt sérül kicsit a vizibilitás és a biztonság is, hiszen a natív pod esetén annak van egy workload IP-je per pod és nem a teljes worker-nek.
Tehát az alsó négy nginx-kezdetű enitás natív pod – ikonjuk is más – a másodjára elindíott nem natív, hanem TKG klaszterben futó konténerek pedig nem is látszanak. Ez nem jelenti azt, hogy ezeket nem lehet NSX DFW-vel körülzárni, de nem annyira nyilvánvaló mint a natív pod-ok esetén.
Létrejön a virtual server számára.
És természetesen elérhető rajta a TCP 80-on az nginx.
Összefoglaló
Teljesen világos, hogy itt akár több új termék együttes bevezetéséről is lehet szó, tehát nem csak magával a K8s-el kell megismerkedni, hanem akár az NSX és az AVI szépségeivel is. Idejében el kell kezdeni, mert akár Tanzu, HPE Ezmeral, Openshift stb-stb-stb-stb alapon tervezi a konténerek futtatását, alkalmazások fejlesztését körülbelül már most is késő néhány esetben. Nem egy olyan példa van, ahol az alkalmazás fejlesztője így adja át a szoftvert. Tehát nem egy Windows Server-re kell .NET-et tenni aztán a C:\Program Files-be a telepítés célját megadni.
Több hasonló tartalommal készül az 99999 blogja is, érdemes követni azt is – link a képre kattinva.
