A Tanzu dokumentációjában nagyon jól össze van szedve minden, amit a telepítés igényelhet. Elsősorban az infrastruktúrával szemben olyan módon, hogy milyen méretben és számban szükséges a telepítés megkezdése előtt kialakítani a Tanzu-nak szolgáltatást adó rendszereket.
Az kiegészítő rendszerekkel kapcsolatos igények – ESXi,vCenter,NSX és Edge VM-ek
- az NSX Manager/Controller appliance-ok javasoltan ne fussanak egy fizikai hoszton, de kettő se fusson egy fizikai hoszton.
- a Supervisor cluster – fentebb Kubernetes control plane – is három VM-et fog feltelepíteni és ott szintén a redundancia miatt kell három hoszt. Ezek a VM-ek amúgy nem is mozgathatók, szóval az nem járható út, hogy három ESXi-vel feltesszük és kiveszünk egy hosztot úgy, hogy megmarad a három supervisor VM.
Az Edge VM természetesen kettőzve szerepel, hiszen a benne létrehozandó T0 és T1 entitásoknak csak így lehet hibatűrést biztosítani. A mérete az Edge VM-eknek mindenképpen Large legyen, ennek praktikus oka az, hogy a konténerizáció nagyban használ load balancer-eket – és NAT-ot it – amelyek igen nagy számban jöhetnek létre, ha kiterjedten kezdi valaki belakni a Tanzu-t. Egy namespace létrehozása egy small load balancer létrehozását jelenti. Egy két large Edge VM-ből álló Edge Cluster így 40 darab namespace kiszolgálására képes. (Skálázni több módon lehetséges).
A hálózattal kapcsolatos igények
Az NSX működéséhez szükséges pontokat itt nem tárgyalom, de a működő overlay igényli a legalább 1600 byte-os MTU-t, legalább egy VLAN-t amiben az overlay forgalom történhet, egy uplink VLAN-t amiben az T0 tranizt valósul meg a következő hop-pal.
Ezen felül pár dolog kell és nem szabad elfelejteni, hogy ezek nélkül lehet nem települ fel a Tanzu vagy ha mégis, akkor lehet nem működik 100%-on:
- 5 darab IP a management hálózaton. Ezen a hálózaton lesznek a Supervisor VM-ek, ezen keresztül beszélnek a vCenter, NSX és ESXi célpontokkal.
Arról megoszlanak a források, hogy igazából ez routed vagy switched legyen, azaz a supervisor management szegmens azonos legyen-e az ESXi-k, vCenter és NSX Manager-ek által használt szegmenssel. A DHCP nem követelmény – nem értem miért van itt. Azért kell öt ilyen IP, mert egyet-egyet birtokolni fog a három Supervisor VM, aztán lesz egy közös VIP cím és a frissítések idejére is kell egy, mikor egy frissebb verziójú supervisor VM belép a klaszterbe majd a régi kikapcsol és letörlődik. Mindezt mint rolling upgrade viszi véghez.
- Management network subnnet. Na itt kezd kicsit kavarodni Tehát itt már arról van szó hogy azonos szegmensre kerül az ESXi vmkernel-e, a vCenter, az NSX Manager (3x) és a Supervisor klaszter management-je is. Innen fakad az, hogy inkább tényleg legyen azonos szegmensen – mondjuk kipróbáltam és működik úgy is ha külön szegmensen vannak.
- Uplink IP(k) hogy a T0 tudjuk kifelé és a világ befelé kommunikálni. Ez a tranzit hálózat. Az elsőt nem is tárgyalom, felejtsük is el. A második lényegében két VLAN-t jelentene, amiben BGP-n beszélünk a next hop eszközzel, Edge VM-enként – illetve az abban realizált T0 uplink interfészenként. Lehetséges statikusan is route-olni, abban az esetben tényleg elég egy VLAN, abban lesz a Edge VM-ekben a T0-nak egy-egy IP-je és egy közös IP-je, amire a next hop eszközről mutatni kell statikus route-tal.
- vSphere Pod CIDR range ami egyben majd a TKG guest cluster-ek által is használt lesz. Alapértelmezetten 10.96.0.0/23
- Kubernetes services CIDR range. Alapértelmezetten 10.244.0.0/20
Fontos hogy ez az utóbbi kettő, lehet a default érték, mivel ezek belső hálózati szegmensek, ezeket nem szükséges kintről befelé route-olni.
- Ingress CIDR. Azaz itt jönnek létre azok a Virtual Server-ek az Load Balancer-en, amelyeken keresztül a külvilág eléri a konténerben futtatott alkalmazásokat. /27 minimum
- Egress CIDR. Innen kap egy IP-t minden namespace, amiről NAT-on keresztül a konténerek beszélhetnek a nagyvilág szolgáltatásihoz. /27 minimum
Az utóbbiról beszéljünk kicsit részletesebben, mert fel kell mérni ez mit jelent. Ezt egy példán keresztül mutatom be. Először nézzük meg vCenter oldaláról.
Nézzük meg NSX oldalról hogy néz ki. Van négy load balancer, egy a Supervisor Cluster-nek, egy a Harbor-nak, egy a newman-ns namespace-nek és egy – elosztott – a nem publikált/belső szolgáltatásoknak.
A newman-ns végű load balancer-t megvizsgálva van elég sok virtual server, hiszen az ingress range-ből ide jönnek létre az entitások, mikor valamit ebből a namespace-ből a külvilág felé publikálunk. Példaként a fenti 10.4.5.3 az itt szerepel.
Ez az ingress range können érthető. De tegyünk fel ebbe a fenti guest klaszterbe egy busybox-ot. A shell-jén vizsgálva ez látszik.
Ha erről pingelünk kifelé, mondjuk a 8.8.8.8-at és közben nézzük az Edge VM uplink-jén a forgalmat, akkor látszik hogy itt valami NAT van – nyilván az lesz 😀
Szóval azt látjuk, hogy kifelé a 10.4.6.3-ról megy ki az echo request. Ez pontosan az egress range tartománya. NSX-oldalán itt érhető tetten. Itt van az első két rule, amiben azt van beállítva hogy belül ne legyen NAT és mikor a services CIDR range-hez fordul egy pod, akkor se legyen fordítás.
Ezért nagyon fontos az, hogy ebből a Tanzu szemszögéből egress range-ből engedélyezzünk minden olyat célt, IP-t, protokollt, amit használni fog egy adott namespace-be kerülő alkalmazás, mivel egyéb esetben nem fog működni. Mármint valószínű hogy a konténerek elindulnak, de valójában nem nagyon fog működni semmi sem.
Összefoglaló
Nem kér sok felkészülést egy Tanzu telepítést, de a hálózati rétegben bizony megkövetel olyat, amit ténylegesen be kell állítani a működés megértésének fényében. Ezt az egress range-ből kinyitom a tűzfalat – amennyiben van közben tűzfal – elkerülni nem nagyon lehet, egyszerűen meg kell tenni. Nyilván idegen, de valaha a virtalizáció is az volt.