Ez az én frissítésem , amely immár Kubernetes 1.14-en fut, a 2019 áprilisi legújabb CNI-verzióval.
Először is szeretnék köszönetet mondani a Cilium csapatának: a srácok segítettek ellenőrizni és kijavítani a mérőszámokat figyelő szkripteket.
Mi változott 2018 novembere óta
Íme, mi változott azóta (ha érdekel):
A flanel továbbra is a leggyorsabb és legegyszerűbb CNI interfész, de továbbra sem támogatja a hálózati házirendeket és a titkosítást.
A Romana már nem támogatott, ezért eltávolítottuk a viszonyítási alapból.
A WeaveNet mostantól támogatja az Ingress és Egress hálózati irányelveit! De a termelékenység csökkent.
A Calico alkalmazásban továbbra is manuálisan kell konfigurálnia a maximális csomagméretet (MTU) a legjobb teljesítmény érdekében. A Calico két lehetőséget kínál a CNI telepítésére, így külön ETCD tároló nélkül is megteheti:
- állapot tárolása a Kubernetes API-ban adattárként (fürtméret < 50 csomópont);
- állapot tárolása a Kubernetes API-ban adattárként egy Typha-proxyval, hogy tehermentesítse a K8S API-t (a fürt mérete > 50 csomópont).
Calico bejelentette támogatását az Istio tetején az alkalmazásszintű biztonság érdekében.
A Cilium mostantól támogatja a titkosítást! A Cilium IPSec alagutak segítségével biztosít titkosítást, és alternatívát kínál a titkosított WeaveNet hálózattal szemben. De a WeaveNet gyorsabb, mint a Cilium, engedélyezve a titkosítást.
A beépített ETCD kezelőnek köszönhetően a Cilium könnyebben telepíthető.
A Cilium csapat megpróbált némi súlyt csökkenteni a CNI-ből a memóriafogyasztás és a CPU-költségek csökkentésével, de versenytársai még mindig könnyebbek.
Benchmark kontextus
A benchmark három nem virtualizált Supermicro szerveren fut, 10 Gb-os Supermicro kapcsolóval. A szerverek passzív DAC SFP+ kábeleken keresztül közvetlenül csatlakoznak a switch-hez, és ugyanazon a VLAN-on vannak konfigurálva jumbo keretekkel (MTU 9000).
A Kubernetes 1.14.0 telepítve van az Ubuntu 18.04 LTS-re Docker 18.09.2-vel (az alapértelmezett Docker verzió ebben a kiadásban).
A reprodukálhatóság javítása érdekében úgy döntöttünk, hogy a mestert mindig az első csomóponton konfiguráljuk, a benchmark szerver részét a másodikra, a kliens részét pedig a harmadikra helyezzük. Ehhez a Kubernetes-telepítésekben a NodeSelectort használjuk.
A benchmark eredményeket a következő skálán írjuk le:
CNI kiválasztása benchmarkhoz
Ez csak a CNI-re vonatkozó referenciaérték a szakaszban található listából Tekintse meg a hivatalos Kubernetes dokumentációt. A 9 CNI-ből csak 6-ot veszünk: kizárjuk azokat, amelyek nehezen telepíthetők és/vagy nem működnek konfiguráció nélkül a dokumentáció szerint (Romana, Contiv-VPP és JuniperContrail/TungstenFabric).
Összehasonlítjuk a következő CNI-ket:
- Calico v3.6
- Canal v3.6 (alapvetően Flannel hálózatépítéshez + Calico tűzfalként)
- Cilium 1.4.2
- Flanel 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Telepítés
Minél könnyebben telepíthető a CNI, annál jobb lesz az első benyomásunk. A benchmark összes CNI-je nagyon könnyen telepíthető (egy vagy két paranccsal).
Mint mondtuk, a szerverek és a kapcsolók úgy vannak konfigurálva, hogy a jumbo keretek engedélyezettek (az MTU-t 9000-re állítottuk). Örülnénk, ha a CNI automatikusan meghatározná az MTU-t az adapterek konfigurációja alapján. Ez azonban csak Ciliumnak és Flanelnek sikerült. A többi CNI-nek van kérése a GitHubon az automatikus MTU-felderítés hozzáadására, de ezt manuálisan konfiguráljuk a ConfigMap for Calico, Canal és Kube-router módosításával, vagy egy környezeti változó átadásával a WeaveNet számára.
Mi a probléma a nem megfelelő MTU-val? Ez a diagram bemutatja a különbséget az alapértelmezett MTU-val rendelkező WeaveNet és a jumbo keretek között:
Hogyan befolyásolja az MTU a teljesítményt?
Láttuk, mennyire fontos az MTU a teljesítmény szempontjából, most pedig nézzük meg, hogyan határozzák meg automatikusan a CNI-ink:
A CNI automatikusan felismeri az MTU-t
A grafikon azt mutatja, hogy az optimális teljesítmény érdekében be kell állítania az MTU-t a Calico, a Canal, a Kube-router és a WeaveNet számára. Cilium és Flannel minden beállítás nélkül meg tudta határozni az MTU-t.
biztonság
A CNI biztonságát két szempontból fogjuk összehasonlítani: az átvitt adatok titkosításának képessége és a Kubernetes hálózati házirendek megvalósítása (valódi tesztek, nem dokumentáció alapján).
Csak két CNI titkosítja az adatokat: a Cilium és a WeaveNet. Titkosítás WeaveNet A titkosítási jelszó CNI környezeti változóként történő beállításával engedélyezhető. BAN BEN A WeaveNet bonyolultan írja le, de minden egyszerűen történik. Titkosítás cilium parancsokkal, Kubernetes titkok létrehozásával és a daemonSet módosításával konfigurálható (kicsit bonyolultabb, mint a WeaveNetben, de a Ciliumban lépésről lépésre ).
Ami a hálózati politika végrehajtását illeti, sikerült nekik Calico, Canal, Cilium és WeaveNet, amelyben be- és kilépési szabályokat állíthat be. Mert Kube-router csak az Ingressre vannak szabályok, és Flanel Egyáltalán nincsenek hálózati szabályzatok.
Íme az összesített eredmények:
Biztonsági teljesítmény referenciaértékek eredményei
termelékenység
Ez a referenciaérték az átlagos átviteli sebességet mutatja az egyes tesztek legalább három futtatása során. Teszteljük a TCP és az UDP (iperf3 használatával), a valódi alkalmazások, például a HTTP (Nginx-szel és curl-lel) vagy az FTP (vsftpd-vel és curl-lel) teljesítményét, végül pedig az alkalmazások teljesítményét SCP-alapú titkosítással (kliens és szerver OpenSSH használatával).
Valamennyi tesztnél csupasz fém benchmarkot (zöld vonal) végeztünk, hogy összehasonlítsuk a CNI teljesítményét a natív hálózati teljesítménnyel. Itt ugyanazt a skálát használjuk, de színben:
- Sárga = nagyon jó
- Narancs = jó
- Kék = úgy-úgy
- Piros = rossz
Nem fogadunk el helytelenül konfigurált CNI-ket, és csak a megfelelő MTU-val rendelkező CNI-k eredményeit jelenítjük meg. (Megjegyzés: a Cilium nem számítja ki megfelelően az MTU-t, ha engedélyezi a titkosítást, ezért manuálisan kell csökkentenie az MTU-t 8900-ra az 1.4-es verzióban. A következő, 1.5-ös verzió ezt automatikusan elvégzi.)
Íme az eredmények:
TCP teljesítmény
Minden CNI jól teljesített a TCP benchmarkban. A titkosítással ellátott CNI messze elmarad, mert a titkosítás drága.
UDP teljesítmény
Itt is minden CNI jól megy. A titkosítással ellátott CNI majdnem ugyanazt az eredményt mutatta. A Cilium egy kicsit le van maradva a versenytárstól, de csak 2,3%-a a csupasz fém, tehát nem rossz eredmény. Ne felejtsük el, hogy csak a Cilium és a Flannel határozta meg helyesen az MTU-t, és ezek az eredményeik minden további konfiguráció nélkül.
Mi a helyzet egy valódi alkalmazással? Amint láthatja, a HTTP általános teljesítménye valamivel alacsonyabb, mint a TCP esetében. Még akkor is, ha HTTP-t használ a TCP-vel, az iperf3-at a TCP-benchmarkban konfiguráltuk, hogy elkerüljük a lassú indítást, amely hatással lenne a HTTP-benchmarkra. Itt mindenki jó munkát végzett. A Kube-routernek egyértelmű előnye van, de a WeaveNet nem teljesített jól: körülbelül 20%-kal rosszabb, mint a csupasz fém. A Cilium és a WeaveNet titkosítással nagyon szomorúnak tűnik.
Az FTP, egy másik TCP-alapú protokoll esetén az eredmények eltérőek. A flanel és a Kube-router elvégzi a munkát, de a Calico, a Canal és a Cilium egy kicsit le vannak maradva, és körülbelül 10%-kal lassabbak, mint a csupasz fém. A WeaveNet 17%-kal van lemaradva, de a titkosított WeaveNet 40%-kal előzi meg a titkosított Ciliumot.
Az SCP-vel azonnal láthatjuk, mennyibe kerül nekünk az SSH titkosítás. Szinte minden CNI jól megy, de a WeaveNet ismét lemaradt. A titkosítással ellátott Cilium és WeaveNet várhatóan a legrosszabb a kettős titkosítás (SSH + CNI) miatt.
Íme egy összefoglaló táblázat az eredményekkel:
Erőforrás felhasználás
Most pedig hasonlítsuk össze, hogy a CNI hogyan fogyaszt erőforrásokat nagy terhelés mellett (TCP átvitel során, 10 Gbps). A teljesítménytesztekben a CNI-t a csupasz fémmel (zöld vonal) hasonlítjuk össze. Az erőforrás-felhasználáshoz mutassunk tiszta Kubernetes-t (lila vonal) CNI nélkül, és nézzük meg, mennyi extra erőforrást fogyaszt a CNI.
Kezdjük a memóriával. Itt látható a csomópontok RAM-jának átlagos értéke (a pufferek és a gyorsítótár kivételével) MB-ban az átvitel során.
Memória fogyasztás
A Flanel és a Kube-router kiváló eredményeket mutatott - csak 50 MB. A Calico és a Canal egyaránt 70-et. A WeaveNet egyértelműen többet fogyaszt, mint a többi – 130 MB-ot, a Cilium pedig 400-at.
Most nézzük meg a CPU időfogyasztását. Figyelemre méltó: a diagram nem százalékokat, hanem ppm-et mutat, vagyis a 38 ppm a „csupasz vas” esetében 3,8%. Íme az eredmények:
CPU fogyasztás
A Calico, a Canal, a Flannel és a Kube-router nagyon CPU-hatékony – mindössze 2%-kal több, mint a CNI nélküli Kubernetes. A WeaveNet 5%-kal messze lemarad, ezt követi a Cilium 7%-kal.
Íme egy összefoglaló az erőforrás-felhasználásról:
Eredményei
Táblázat az összes eredménnyel:
Általános benchmark eredmények
Következtetés
Az utolsó részben kifejtem szubjektív véleményemet az eredményekről. Ne feledje, hogy ez a benchmark csak egyetlen kapcsolat átviteli sebességét teszteli egy nagyon kis fürtön (3 csomóponton). Nem vonatkozik nagy klaszterekre (<50 csomópont) vagy párhuzamos kapcsolatokra.
A következő CNI-k használatát javaslom a forgatókönyvtől függően:
- Van a klaszteredben csomópontok kevés erőforrással (több GB RAM, több mag), és nincs szüksége biztonsági funkciókra – válasszon Flanel. Ez az egyik legköltséghatékonyabb CNI. És kompatibilis sokféle architektúrával (amd64, arm, arm64 stb.). Ráadásul ez az egyik a két (a másik a Cilium) CNI közül, amely képes automatikusan meghatározni az MTU-t, így nem kell semmit konfigurálnia. A Kube-router is megfelelő, de nem szabványos, és manuálisan kell konfigurálnia az MTU-t.
- Szükség esetén titkosítja a hálózatot a biztonság kedvéért vedd WeaveNet. Ne felejtse el megadni az MTU méretét, ha jumbo kereteket használ, és engedélyezze a titkosítást jelszó megadásával egy környezeti változón keresztül. De jobb megfeledkezni a teljesítményről – ez a titkosítás ára.
- mert normál használat Azt tanácsolom Karton. Ezt a CNI-t széles körben használják különféle Kubernetes telepítési eszközökben (Kops, Kubespray, Rancher stb.). A WeaveNethez hasonlóan, ügyeljen arra, hogy konfigurálja az MTU-t a ConfigMapben, ha jumbo kereteket használ. Ez egy többfunkciós eszköz, amely hatékony az erőforrás-felhasználás, a teljesítmény és a biztonság szempontjából.
És végül azt tanácsolom, hogy kövesse a fejlődést cilium. Ennek a CNI-nek nagyon aktív csapata van, akik sokat dolgoznak a termékükön (funkciók, erőforrás-megtakarítás, teljesítmény, biztonság, klaszterezés...), és nagyon érdekes terveik vannak.
Vizuális diagram a CNI kiválasztásához
Forrás: will.com