VMware-el is foglalkozó, vintage rendszereket tervező és építő szakemberként elsősorban a vSphere, NSX vonalon mozgok. De mivel a VMware olyan sok termékkel rendelkezik és ezek között olyan egymással együttműködő megoldásokat hív életre, tanulni kell szinte minden hónapban valami újat. Így volt ez az NSX-V, majd az NSX-T termékkel is. Inkább a hálózatos/tűzfalas világba csúszik, nem annyira a szerver/tárolós körbe.
Így van/volt ez a Tanzu-val is, amiről már itt nálam is igen sokszor olvashattatok. Szóval bár maga a Tanzu nem igényel NSX-T telepítést, hiszen működik HAproxy-val is és AVI load balancer-rel is, de igazán az NSX-T-vel tudja a legtöbb dolgot. Ezért gondoltam, hogy ha az NSX-T már nem okoz akkora meglepetést, akkor a Tanzu-t is biztos megtanulom.
Mikor valamilyen VMware termék bevezetéséről van szó egy ügyfélnél, én szeretem őket a VVD – VMware Validated Design – irányba tolni ha az architektúráról van szó. Nem vakon elfogadni, de alapként tekinve rá, ahonnan indulhatunk. Mármint a VMware Cloud Foundation is a VVD-re épül és a VMware nem találna ki olyan kialakítást, ami nem hozza azt amit elvárunk tőle. Ennek ellenére mondjuk vannak olyan ügyfelek, akik nem értik meg, hogy valamit technikailag lehetetlen megcsinálni vagy ha mégis, akkor nem érdemes. A VCF amúgy legjobb vívmánya az a bill of material, ami minden esetben azon komponensek verziójának listája, amik a VCF-et magát alkotják.
Például a 4.2.1 BOM így néz ki:
Mikor valamit építek, akkor ezeket a verziókat használom, hiszen a VMware ezeket validálja, ezek együttműködése garantált.
Na de térjünk vissza a Tanzu-ra. Ha nincs VMware Cloud Foundation, akkor a Tanzu telepítésének megkezdése előtt a következő feladatokat kell végrehajtani:
- vSphere ESXi-k telepítése és konfigurációja
- vCenter Server telepítése és konfigurációja
- Klaszterbe rendezés, HA és DRS bekapcsolása, content library létrehozása, datastore tag
- NSX Manager-ek telepítése
- Edge VM-ek telepítése
- NSX telepítése a hosztokra
- Tier 0 létrehozása
- Routing beállítása
Ha ez mind sikeresen megvalósult, akkor irány a Workload Management és meg lehet kísérelni a supervisor klaszter telepítését. Alább már írtam róla.
A sikeres telepítés után máris használható a rendszer és telepíthető a kívánt namespace-be egy vagy több Tanzu Kubernetes Cluster. Illetve csak szeretnénk, mivel ez bizony megváltozott. Szóval Cormac Hogan és kismillió másik blogon is látható how-to bejegyzésekben, Raymond de Jong Youtube videóiban mind úgy van leírva, hogy kellett eddig.
Első pofon
De most másképp kell már. Miután megjelent a kubectl-ből kigörgethető normál virtuális gépek készíthetősége a VM Service, úgy tűnik azt KÖTELEZŐ bekapcsolni, különben a TKG cluster sem telepíthető. A hibaüzenet igazán félrevezető mert a VIP címről magyaráz, de valójában ezt kell megtenni.
A dokumentáció nem verziózott, szóval naponta érdemes átolvasni az “release noets” részt vagy RSS-t beállítani rá.
Szóval fentebb a kijelölt rész értelmében érdemes eljárni. A dokumentációban részletesebben le is van írva, hogy mostantól be kell kapcsolnia a VM Service-t, tekinve hogy “virtual machine class”-okat adunk a namespace-hez.
Ez volt az első bukkanó, mert eddig nem kellett és most rá kellett döbbenni, hogy már kell. Örülnék ha a dokumentáció neve mondjuk nem “vSphere with Tanzu” lenne, hanem megjelenne benne valami verziószám, amivel kötni lehet az ESXi és vCenter verziókhoz közvetlenül.
A második pofon
Az ha valami már müködik, az nem jelenti azt, hogy a következő verzióban is működni fog. Történt ez így pontosan az NSX-T 3.1.2-es verziójával – bizony ott fent a VCF BOM-ban az van. Történetesen, a supervisor klaszter telepítését követően a létrejövő NSX Load Balancer, ami a 443-at és 6443-at biztosítja a három supervisor node között szét, na az nem működik.
Ezért jött ki alig két héttel a 3.1.2 után a 3.1.2.1 verzió és bár a release note-ban picit félrebeszélés van, ezzel megjavul minden. Mármint ezzel a verzióval, frissen telepített NSX esetén a Tanzu Supervisor klaszter előtti load balancer tökéletesen működik.
Tanulság
Számomra az, hogy mostantól nem veszem készpénznek a VMware Cloud Foundation BOM-ját, főleg, hogy mivel az NSX-T verziójából jött új, továbbá mikor ilyen negyedik oktetet is tartalmazó verzió jön ki, akkor annak általában valami katasztrofális okat van.
Az is tanulság, hogy az legújabb nem a legjobb, illetve nem minden esetben. Szintén megfogadom, hogy hetente kétszer átolvasom a Tanzu dokumentációját, hogy detektáljam a változásokat benne.
A Tanzu olyan gyorsan fejlődik, hogy ilyenek előfordulnak, főleg hogy itt a vSphere, vCenter és NSX-T is a csomagjában van, hiszen ezek nélkül nem működik – mármint a vSphere with Tanu/Kubernetes on vSphere nem. Ettől még nem rossz termék, kiemelten azért nem, mert nincs még egy ilyen integrált megoldás ameny a VMware vásárlókhoz ilyen közel áll és ennyire sok szolgáltatást ad, nem csak magának a konténereknek, hanem az NSX és vSphere révén bármilyen VM alapú workload számára is.
Szóval mivel nagy az iram, becsúszhat ilyen hiba, de ezért is fontos a proof of concept, illetve ha már megépült, akkor a friss verziók előzetes tesztelése egy erre hivatott környezetben.
