Mostanában PaaS tartalmakon dolgoztam, és most kerültem kapcsolatba a Kubernetes-szel, ami hálózati lefedettséget, vagyis a kereszt-host konténerek közötti kommunikációt jelenti. Így megjelentek egy sor nyílt forráskódú komponens, mint például flanell, kalikó, szövés stb. Itt főként Calico és Fannel találhatók.
Flanel-elv
A CoreOS által fejlesztett Flannel projekt valószínűleg a legközvetlenebb és legnépszerűbb CNI plugin. Ez az egyik legérettebb példa a hálózati architektúrára a konténer orkestrációs rendszerekben, és úgy tervezték, hogy jobb konténer- és host-hálózatot tegyen lehetővé. A CNI koncepciójának megjelenésével a Flannel CNI plugin korai bevezetés volt.
A flanel viszonylag egyszerű telepíteni és konfigurálni más opciókhoz képest. Egyetlen bináris FlannelD-ként csomagolva, és sok gyakori Kubernetes klasztertelepítési eszköz, valamint sok Kubernetes disztribúció alapértelmezetten telepítheti a Flannel-t. A Flannel használhatja a Kubernetes klaszter meglévő etcd klaszterét az állapotinformációk tárolására az API segítségével, így nem igényel dedikált adattárolót.
A Flannel konfigurál egy 3. réteg IPv4 fedőhálózatot. Egy nagy belső hálózatot hoz létre, amely a klaszter minden csomópontját lefedi. Ebben a Overlay hálózatban minden csomópontnak van egy alhálózata, amelyet belső IP-címek kijelölésére használnak. Pod konfigurálásakor a Docker híd interfésze minden csomóponton egy címet rendel minden új konténerhez. Ugyanabban a hostban lévő podok Docker hídokkal kommunikálhatnak, míg a különböző hostok kapszulái flanelddel kapszulálják forgalomukat UDP csomagokba, így a megfelelő célállomásra irányíthatók.
A flanelnek többféle háttérrendszere van, amelyeket kapszulázásra és útvonalépítésre lehet használni. Az alapértelmezett és ajánlott megközelítés a VXLAN használata, mert a VXLAN jobban teljesít, és kevesebb kézi beavatkozást igényel.
Calico építészet
A kalikó a következő fontos összetevőket tartalmazza: Felix etcd, BGP Client és BGP Route Reflector. Az alábbiakban az egyes összetevők magyarázatai láthatók.
Felix: Elsősorban az útvonaltervezésért, az ACLS szabálykonfigurációért és a szállításért felelős, minden csomóponton megtalálható.
etcd: A megosztott kulcs-érték tároló, amely elsősorban a hálózati metaadatok konzisztenciájáért felelős, és biztosítja a Calico hálózati állapot pontosságát, megosztható Kubernetes-szel;
A BGPClient (BIRD) elsősorban a Felix által a kernelre írt útvonali információk elosztásáért felelős a jelenlegi Calico hálózatra, hogy biztosítsa a munkaterhelések közötti kommunikáció hatékonyságát.
A BGPRoute Reflector (BIRD) nagy léptékű telepítésekben használatos, elhagyva az összes csomópont összekapcsolásának mesh módját, és egy vagy több BGPRoute Reflector segítségével végzik a központosított útvonalépítést és elosztást.
A kalikóelv
Ahogy a következő ábrán látható, a folyamatot a forráskonténertől a forrás hoszton át ábrázolják, az adatközpont útvonalán keresztül, végül a célállomásig, végül a célkonténerhez rendelve.
Kontraszt
A fenti elvből kimutatható, hogy a flanel a csomagkibontási műveleteket az útvonaltovábbítás alapján végzi, ami CPU számítási erőforrásokat pazarol. Az alábbi diagram összehasonlítja az online elérhető különböző nyílt forráskódú hálózati komponensek teljesítményét. Látható, hogy sávszélesség és hálózati késleltetés tekintetében a Calico és a gazda teljesítménye hasonló.
|
Közzétéve 2020. 11. 09. 11:23:01
|
|
|
|
