[Videó] Calico: Kubernetes hálózat skálázása 5-től 5000 gépig

HUP

A népszerű hálózati megoldást (ún.: Container Network Interface vagyis CNI plugin) több vezető felhőszolgáltatás is használja alapértelmezettként, így könnyen szembe jöhet velünk a Calico. Hasznos lehet megismerni, hogyan tudjuk az alap telepítés gyengécske skálázódását javítani. Kovács Richárd, az IBM hálózati szakemberének a HWSW free! meetupsorozat 2020. július 23-i, Kubernetes-fókuszú állomásán rögzített előadásában a fenti probléma megoldására mutat működő módszereket. A szakember előadásban az alapok ismertetése után bemutatja, milyen módszerekkel lehet rávenni a Calico-t, hogy nagy fürtök esetén is képes legyen a feladatát érdemben ellátni.

Az érdeklődők a Kubernetesszel a HWSW 2020. szeptember 15-én kezdődő, 8 alkalmas, 24 órás, Kubernetes alapjai című gyakorlatorientált, online képzésén közelebbről is megismerkedhetnek.

( turul16 v | 2020. 08. 22., szo – 08:29 )

Szerkesztve: 2020. 08. 22., szo – 11:43

Miert nem jo siman eBGP -t hasznalni a hostokon es spine/leaf/.. routereken is ?
(FRR stilus)

Hostok tetszoleges subnetet vagy IP-t (akkar anycast ot is) hirdetnek,
egy host kozvetlenul csak a routerrel (multi homing esten 2 routerrel) van kozvetlen kapcsolatban,
Egy leaf/spine router szinten csak port szamu kapcsolatot apol.

IPV6 -eseten a dolog meg konyebb lehet,
Egy host az osszes konteneret betolhatja egyetlen ipv6/64 hiredtmenybe ,
ha meg okosabban van csinalva akkor a leafek is mar hierhikusan kapjak a cim teret ..

Ez ha butan is van csinalva 32k+ hostot siman kene birnia,
okosan csinalva `internet` meret ..
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

tsss! MERT NEM ES KESZ! /s

 

komolyra forditva a dolgot ritka nagy hanyinger az egesz kubernetes, calico, containeredi. szedett vetetten meg van tervezve, a helyett, h mukodnenek a dolgok, inkabb csak docognek, de annyi uj feature kerul bele, hogy senki nem tudja nyomon kovetni. OpenStacknel ugyanez volt az elejen, kellett neki vagy 6 ev amig stabil lett...

Neutron (ill quantum) elso 3 eveben  nem volt kepes >95% feletti siker rata felett,
a szokasos teszt sorozaton vegig meni, a HA -nak nevezett valtozata
tovabbi 1 even at ..

Ahoz kepest manapsag mukodik , ill eleg nagy ecosystemet is tud maga korul ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azért, mert a fenti problematikának ehhez szinte semmi köze nincs.

Eleve ott kezdődik a dolog, hogy overlay.

Skálázhatóság szempontjából a BGP max. peering szám releváns, a vázolt jól ismert megoldások erre nyújtanak gyógyírt.

A valódi probléma pedig nem ez, hanem hogy a fent nevezett megoldások implementálásához egyrészt tervezés (ész), másrést manuális meló szükségeltetik, mert a rendszerben momentán csak egy nagyon basic struktúra, a full-mesh van automatizálva.

'Eleve ott kezdődik a dolog, hogy overlay.'

1. overlay nem kotelezo (az eloadas szerint sem)
2. overlay -t BGP -n keresztul is lehet hirdetni (for ex. EVPN)

Az altalam emlittett megoldasban, szinte csak  ASN kell beloni az eszkozokon, a tobbi
az IPAM -odon mulik ..

 

Ha jol ertem az elsodas szerint is csak ott kell overlay ahol tobb szumbnet talalkozik,
es a fizikai router nem a baratod. Nalam a router a baratod , ezert nem kell beoverlaylni azt,
amire megkerhetem hogy routolja ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Valoban, de nemelyik megengedi, hogy a per node >=pod szamu  cimekre megerkezzen a csomag,
illetve hogy tetszolgesen nagy (ipv4 /8) subneted legyen adatokra amikbol per node ~/24 -ed van ..
Ilyenkor meg BGP -sem kell..

IMHO ec2 -n meg vagy lo"ve,
nem fog routolni hagyni,
nem fogja hagyni hogy ismeretlen cimek keringjenek,
valamilyen overlayes megoldas kellesz.

Valoszinuleg szembe kerulhetsz olyen esettel,
hogy statukus arp bejegyzesek kellenek, vagy hogy port secutity-t kell tiltani,
vagy legallabb hozza kell addnon egy allowed-address-ranget -et a porthoz.

statiskus routot allitani legtobb nem enged,
vagy nem erre valo modon.

gougle cloud enged eleg sok mindent allitani,
de ott meg az MTU -nem tul nagy ,
ec2 -viszont lehet nagyobb MTU `az overlay buntetes` csokentesere.

 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem lettem meggyozve, hogy ebbe az utcaba erdemes bemenni :) On-prem persze mas a helyzet, ott egyaltalan nem kotelezo overlayt hasznalni, ha a gateway device (vagy barmi is legyen a node-ok utan kotve) frissitve van, de ott meg valoszinuleg valami custom CNI-t kell irni. Mondjuk az 3 metodus implementalasat jelenti, szoval nem nagy kaland.

Coding and ADHD should be best friends

FYI, eppen a route reflector auto skalazasan ugykodok.

Proposal: https://github.com/mhmxs/calico-route-reflector-operator-proposal/

POC: https://github.com/mhmxs/calico-route-reflector-operator

Mar implementalom a Calico-s kubernetes controllert (csak az egy masik FW-ot hasznal, mint a POC, es ki szeretnem hasznalni annak az adottsagait)

Barmilyen eszrevetelt, otletet es segitseget szivesen veszek ;)

Coding and ADHD should be best friends

( turul16 v | 2020. 08. 24., h – 10:51 )

Szerkesztve: 2020. 08. 24., h – 14:09

Miert lett bird a preferlat router daemon ?
Van olyan dologa amit a tobbi nem tud ? (pl. frr nem tud ?)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.