No NAT opció – VMware Tanzu

A VMware nem pihen és havi ütemezéssel jelenteti meg a Tanzu-s frissítéseket, amelyek a vCenter Server frissítéseivel érkeznek – supervisor klaszter, spherelet stb – illetve a saját content library-n megjelenő újabb ova-k képében – guest klaszterek esetén. Rengeteg hibajavítás van bennük, de azért akad új képesség is (sajnálatos módon ezekről úgy lehet csak értesülni, hogy explicit ilyen szemüveggel olvassa el a release notes-ot). (link)

Az 2021. október 5-án kiadott frissítésben van pár igen szép újdonság:

Eddig nem lehetett, de ezentúl lehet olyan VM-et is kigurítani a kubectl segítségével, amelybe diszkrét GPU is van. Ennél fontosabb talán az, a supervisor klaszter management oldali lába már lehet DHCP-n is. Egészen eddig a verzióig öt darab IP-re volt szükség, amit a telepítő igazából csak a kezdő IP-vel kért be és emiatt volt az a követelmény, hogy egymást követő öt IP legyen szabadon. Mostantól DHCP-vel is kiváltható ez – fent írja a magyarázat, hogy a gyorsabb POC érdekében, amivel egyet is tudok érteni, ritkán van DHCP egy adatközponti hálózatban.

A supervisor klaszter telepítését követően alig lehetett valamit megváltoztatni, sőt olyan is volt, hogy hiába írta valaki át a vCenter-ben, az nem került érvényre. Ezt most feloldották, bármit át lehet írni, de érdemes figyelni, arra, hogy például az ingress/egress range-hez fel lehet venni újabb tételeket, de törölni nem.

Mint az köztudott, a konténerek volatilis szerzetek. Futnak és ha újraindulnak/leállnak stb, akkor az addig használt tárolójuk nullázódik. A persistent volume ennek kiküszöbölésére van és három modell létezik az elérésük módjára – RWO,ROX és RWX. Az RWX monstantól guest cluster-ek esetén is használható.

No-NAT topológia, jelen cikk témája.

NAT topológia

Először nézzük meg, milyen a NAT-olt – eddig csak ez volt elérhető – topológia.

Egy ilyen telepítéséhez kell pár szegmens, ami a Tanzu-n kívülről is elérhető:

  • management szegmens – erről öt darab egymás követő IP kell vagy DHCP
  • ingress szegmens – attól függően mennyi load balancer VIP lesz
  • egress szegmens – attól függően mennyi namespace lesz

És kettő nem route-olt – ez az NSX sem route-olja – de opcionálisan megváltoztatható és ami hagyható default-on is:

  • namespace CIDR – 10.244.0.0/20
  • services CIDR – 10.96.0.0/23

Az Ingress nevűben lesz az NSX-T LB VIP-je ha „LoadBalancer”-t kérünk. Minden namespace egy IP-t kap az Egress tartományból, amelyből source NAT-olva érhet el mindent, ami a rendszeren kívül van.

Szóval ha egy natív POD-ból vagy TKC-ben futó POD-ból pingelünk egy külső IP-t stb, akkor source NAT-olva lesz, ezért is kell az Egress CIDR. Minden namespace – VMware terminolóiában értve – egyetlen forrás IP mögül kommunikál kifelé. Ez nyilvánvalóan nem tetszett sok ügyfélnek, mert az összes TKC egy namespace-ben ezt az IP-t használta, pedig akár különböző alkalmazások is futnak rajtuk. Nyilván más szervezésben könnyen lehet nem is probléma.

No-NAT topológia

Erről nincs képe a VMware-nek, hiába állítható át maga a kapcsoló, a megjelenített kép nem változik.

Egy No-NAT telepítéshez szintén három szegmens, ami a Tanzu-n kívülről is elérhető:

  • management szegmens
  • ingress szegmens
  • namespace szegmens

És opcionálisan egy, ami megváltoztatható, de hagyható default-on is:

  • services CIDR – 10.96.0.0/23

No NAT esetén ez az Egress rész egyáltalán nem kell, mivel a natív Pod-ok és a TKC node-ok is olyan szegmensen vannak, amely szegmens route-olt. Így nem kell source NAT sem. Tehát a fenti képen a 10.244.0.0/20 helyett tulajdonképpen egy legalább /23-at kell beadnunk, cserébe az Egress CIDR nem kitölthető.

A supervisor cluster telepítésekor kiválasztható egy topológia, amit a későbbiekben a namespace-ek lérehozásakor akár NAT-ra vagy No-NAT-ra is át lehet állítani, viszont maga a supervisor klaszter-en átállítani nem lehet utólag.

Összefoglaló

Kis lépésekben, de kitartóan kerülnek be új funkciók és jó látni olyat is, aminek érelme is van. Nem gondolom, hogy egy már belakott Tanzu-t érdemes lenne átalakítani így, de minden kétséget kizáróan szerintem a No-NAT egy tisztább és átláthatóbb topológiát ad.