TL; DR: Minden CNI úgy működik, ahogy kell, a Kube-Router és a Kube-OVN kivételével a Calico, az automatikus MTU felismerés kivételével, a legjobb.
Korábbi ellenőrzéseim cikkfrissítése ( и ), a tesztelés idején Kubernetes 1.19-et használok Ubuntu 18.04-en, 2020 augusztusától frissített CNI-kkel.
Mielőtt belevágnánk a mérőszámokba...
Mi újság 2019 áprilisa óta?
- Tesztelhet saját fürtjén: Eszközünk segítségével teszteket futtathat saját fürtjén Kubernetes Network Benchmark:
- Új tagok jelentek meg
- a VMware Tanzutól
- from alauda.io
- Új forgatókönyvek: A jelenlegi ellenőrzések "Pod-to-Pod" hálózati teljesítményteszteket futtatnak, és egy új "Pod-to-Service" szkript került hozzáadásra, amely a valós körülményekhez közelebbi teszteket futtat. A gyakorlatban a Pod with API szolgáltatásként működik az alappal, és nem a Pod IP-címén keresztül (természetesen mindkét forgatókönyvnél ellenőrizzük a TCP-t és az UDP-t is).
- Erőforrás-felhasználás: minden tesztnek megvan a saját erőforrás-összehasonlítása
- Alkalmazástesztek eltávolítása: A továbbiakban nem végzünk HTTP-, FTP- és SCP-teszteket, mivel a közösséggel és a CNI-karbantartókkal folytatott gyümölcsöző együttműködésünk során a CNI-indítás késése miatt (a Pod első néhány másodpercében) hiányt fedeztünk fel a TCP feletti iperf-eredmények és a curl-eredmények között. indítás, ami valós körülmények között nem jellemző).
- Nyílt forráskód: minden tesztforrás (szkriptek, yml beállítások és eredeti „nyers” adatok) elérhető
Referencia vizsgálati protokoll
A protokollt részletesen ismertetjük Felhívjuk figyelmét, hogy ez a cikk az Ubuntu 18.04-ről szól, az alapértelmezett kernellel.
CNI kiválasztása értékelésre
Ennek a tesztelésnek az a célja, hogy összehasonlítsa az egyetlen yaml-fájllal konfigurált CNI-ket (ezért a szkriptek, például a VPP és mások által telepítettek mindegyike kizárt).
Összehasonlításra kiválasztott CNI-ink:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Flannel hálózat + Calico hálózati szabályzatok)
- Cilium 1.8.2
- Flanel 0.12.0
- Kube-router legújabb (2020-08-25)
- WeaveNet 2.7.0
MTU konfigurálása CNI-hez
Először is ellenőrizzük az automatikus MTU-érzékelés hatását a TCP teljesítményére:
Az MTU hatása a TCP teljesítményére
Még nagyobb hiányosság tapasztalható UDP használatakor:
Az MTU hatása az UDP teljesítményére
Tekintettel a tesztek során feltárt HATALMAS teljesítményre, szeretnénk egy reménylevelet küldeni minden CNI-karbantartónak: kérjük, adják hozzá az automatikus MTU-detektálást a CNI-hez. Megmentheted a cicákat, egyszarvúkat és még a legaranyosabbat is: a kis Devopot.
Ha azonban a CNI-t az automatikus MTU-felismerés támogatása nélkül kell használnia, manuálisan konfigurálhatja a teljesítmény elérése érdekében. Kérjük, vegye figyelembe, hogy ez a Calico, a Canal és a WeaveNet hálózatokra vonatkozik.
Kis kérésem a kísérő CNI-knek...
CNI-tesztelés: nyers adatok
Ebben a részben összehasonlítjuk a CNI-t a megfelelő MTU-val (automatikusan meghatározva vagy manuálisan beállítva). A fő cél itt a nyers adatok grafikonon történő megjelenítése.
Színes jelmagyarázat:
- szürke - minta (azaz csupasz vas)
- zöld - 9500 Mbps feletti sávszélesség
- sárga - 9000 Mbps feletti sávszélesség
- narancssárga - 8000 Mbps feletti sávszélesség
- piros - 8000 Mbps alatti sávszélesség
- kék - semleges (nem kapcsolódik a sávszélességhez)
Üresjárati erőforrás-felhasználás
Először is ellenőrizze az erőforrás-felhasználást, amikor a fürt „alszik”.
Üresjárati erőforrás-felhasználás
Pod-to-Pod
Ez a forgatókönyv feltételezi, hogy a kliens Pod közvetlenül csatlakozik a szerver Pod-hoz az IP-címe használatával.
Pod-to-Pod forgatókönyv
TCP
Pod-to-Pod TCP eredmények és a megfelelő erőforrás-felhasználás:
UDP
Pod-to-Pod UDP eredmények és a megfelelő erőforrás-felhasználás:
Pod-to-Service
Ez a szakasz valós felhasználási esetekre vonatkozik, a kliens Pod a ClusterIP szolgáltatáson keresztül csatlakozik a szerver Podhoz.
Pod-to-Service Script
TCP
Pod-to-Service TCP eredmények és a megfelelő erőforrás-felhasználás:
UDP
Pod-to-Service UDP eredmények és a megfelelő erőforrás-felhasználás:
Hálózati politika támogatása
A fentiek közül az egyetlen, aki nem támogatja a politikát, az Flanel. Az összes többi helyesen hajtja végre a hálózati házirendeket, beleértve a bejövő és a kimenő adatokat is. Nagyszerű munka!
CNI titkosítás
Az ellenőrzött CNI-k között vannak olyanok, amelyek képesek titkosítani a Pod-ok közötti hálózati cserét:
- Antrea IPsec használatával
- Calico vezetékvédő segítségével
- Cilium IPsec használatával
- WeaveNet IPsec használatával
kapacitás
Mivel kevesebb CNI maradt, helyezzük az összes forgatókönyvet egyetlen grafikonba:
Erőforrás felhasználás
Ebben a részben a Pod-Pod kommunikáció TCP-ben és UDP-ben történő feldolgozásához használt erőforrásokat értékeljük. Nincs értelme Pod-to-Service gráfot rajzolni, mivel az nem ad további információkat.
Az egészet összerakva
Próbáljuk meg ismételni az összes grafikont, itt bevezettünk egy kis szubjektivitást, a tényleges értékeket a „vwry fast”, „low” stb. szavakkal helyettesítve.
Következtetés és következtetéseim
Ez egy kicsit szubjektív, mivel én az eredmények saját értelmezését közvetítem.
Örülök, hogy megjelentek az új CNI-k, az Antrea jól teljesített, számos funkciót már a korai verziókban is megvalósítottak: automatikus MTU-felismerés, titkosítás és egyszerű telepítés.
Ha összehasonlítjuk a teljesítményt, akkor minden CNI jól működik, kivéve a Kube-OVN-t és a Kube-Routert. A Kube-Router sem tudta észlelni az MTU-t, a dokumentációban sehol nem találtam módot a beállítására ( ebben a témában nyitott kérés).
Az erőforrás-felhasználást tekintve a Cilium továbbra is több RAM-ot használ, mint mások, de a gyártó egyértelműen a nagy klasztereket célozza meg, ami nyilvánvalóan nem ugyanaz, mint egy három csomópontos klaszteren végzett teszt. A Kube-OVN szintén sok CPU- és RAM-erőforrást fogyaszt, de ez egy fiatal CNI, amely Open vSwitch-re épül (az Antreához hasonlóan jobban teljesít és kevesebbet fogyaszt).
A Flanel kivételével mindenkinek van hálózati szabályzata. Nagyon valószínű, hogy soha nem fogja támogatni őket, hiszen a cél egyszerűbb, mint egy párolt fehérrépa: minél könnyebb, annál jobb.
Többek között a titkosítási teljesítmény is lenyűgöző. A Calico az egyik legrégebbi CNI, de a titkosítást csak néhány hete adták hozzá. Az IPsec helyett a vezetékvédőt választották, és egyszerűen fogalmazva, nagyszerűen és csodálatosan működik, teljesen elhomályosítva a többi CNI-t a tesztelés ezen részében. Természetesen a titkosítás miatt nő az erőforrás-felhasználás, de az elért áteresztőképesség megéri (a Calico hatszoros javulást mutatott a titkosítási tesztben a második helyen álló Ciliumhoz képest). Ezenkívül bármikor engedélyezheti a vezetékvédőt, miután telepítette a Calico-t a fürtre, és rövid időre vagy véglegesen is letilthatja, ha szeretné. Pedig hihetetlenül kényelmes! Emlékeztetjük, hogy a Calico jelenleg nem észleli automatikusan az MTU-t (ezt a funkciót a jövőbeli verziókban tervezik), ezért feltétlenül konfigurálja az MTU-t, ha hálózata támogatja a Jumbo Frames (MTU 9000) funkciót.
Többek között vegye figyelembe, hogy a Cilium képes titkosítani a forgalmat a fürtcsomópontok között (és nem csak a Pod-ok között), ami nagyon fontos lehet a nyilvános fürtcsomópontok számára.
Következtetésként a következő felhasználási eseteket javaslom:
- CNI kell egy nagyon kis fürthöz, VAGY nincs szükségem biztonságra: dolgozik vele Flanel, a legkönnyebb és legstabilabb CNI (ő is az egyik legrégebbi, a legenda szerint Homo Kubernautus vagy Homo Contaitorus találta fel). Önt is érdekelheti a legzseniálisabb projekt , jelölje be!
- CNI kell egy normál fürthöz: Karton - az Ön választása, de ne felejtse el beállítani az MTU-t, ha szükséges. Könnyen és természetesen játszhat a hálózati házirendekkel, be- és kikapcsolhatja a titkosítást stb.
- CNI-re van szükség a (nagyon) nagyméretű klaszterhez: Nos, a teszt nem mutatja a nagy klaszterek viselkedését, szívesen végeznék teszteket, de nincs több száz szerverünk 10 Gbps kapcsolattal. Tehát a legjobb megoldás egy módosított teszt futtatása a csomópontokon, legalább a Calico és a Cilium segítségével.
Forrás: will.com