Det här är min uppdatering , som nu körs på Kubernetes 1.14 med den senaste CNI-versionen från april 2019.
Först och främst vill jag tacka Cilium-teamet: killarna hjälpte mig att kontrollera och korrigera skripten för övervakning av mätvärden.
Vad har förändrats sedan november 2018
Här är vad som har förändrats sedan dess (om du är intresserad):
Flannel är fortfarande det snabbaste och enklaste CNI-gränssnittet, men stöder fortfarande inte nätverkspolicyer och kryptering.
Romana stöds inte längre, så vi har tagit bort det från riktmärket.
WeaveNet stöder nu nätverkspolicyer för Ingress och Egress! Men produktiviteten har minskat.
I Calico behöver du fortfarande manuellt konfigurera den maximala paketstorleken (MTU) för bästa prestanda. Calico erbjuder två alternativ för att installera CNI, så du kan klara dig utan ett separat ETCD-förråd:
- lagringstillstånd i Kubernetes API som ett datalager (klusterstorlek < 50 noder);
- lagringstillstånd i Kubernetes API som ett datalager med en Typha-proxy för att lätta på belastningen på K8S API (klusterstorlek > 50 noder).
Calico meddelade stöd ovanpå Istio för säkerhet på applikationsnivå.
Cilium stöder nu kryptering! Cilium tillhandahåller kryptering med IPSec-tunnlar och erbjuder ett alternativ till det krypterade WeaveNet-nätverket. Men WeaveNet är snabbare än Cilium med kryptering aktiverad.
Cilium är nu lättare att distribuera tack vare den inbyggda ETCD-operatören.
Cilium-teamet har försökt minska vikten från sin CNI genom att minska minnesförbrukningen och CPU-kostnaderna, men dess konkurrenter är fortfarande lättare.
Benchmark sammanhang
Benchmark körs på tre icke-virtualiserade Supermicro-servrar med en 10 Gb Supermicro-switch. Servrarna ansluts direkt till switchen via passiva DAC SFP+-kablar och är konfigurerade på samma VLAN med jumboramar (MTU 9000).
Kubernetes 1.14.0 installerad på Ubuntu 18.04 LTS med Docker 18.09.2 (standardversionen av Docker i den här utgåvan).
För att förbättra reproducerbarheten bestämde vi oss för att alltid konfigurera mastern på den första noden, placera serverdelen av riktmärket på den andra servern och klientdelen på den tredje. För att göra detta använder vi NodeSelector i Kubernetes-distributioner.
Vi kommer att beskriva benchmarkresultaten på följande skala:
Välja en CNI för ett riktmärke
Detta är endast ett riktmärke för CNI från listan i avsnittet Se den officiella Kubernetes-dokumentationen. Av de 9 CNI:erna tar vi endast 6: vi kommer att utesluta de som är svåra att installera och/eller inte fungerar utan konfiguration enligt dokumentationen (Romana, Contiv-VPP och JuniperContrail/TungstenFabric).
Vi kommer att jämföra följande CNI:
- Calico v3.6
- Canal v3.6 (i huvudsak Flannel för nätverk + Calico som brandvägg)
- Cilium 1.4.2
- Flanell 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Installation
Ju enklare CNI är att installera, desto bättre blir vårt första intryck. Alla CNI från benchmark är mycket enkla att installera (med ett eller två kommandon).
Som vi sa är servrarna och switchen konfigurerade med jumboramar aktiverade (vi ställer in MTU till 9000). Vi skulle vara glada om CNI automatiskt bestämde MTU baserat på adaptrarnas konfiguration. Det var dock bara Cilium och Flannel som klarade detta. Resten av CNI:erna har förfrågningar på GitHub om att lägga till automatisk MTU-upptäckt, men vi kommer att konfigurera det manuellt genom att ändra ConfigMap för Calico, Canal och Kube-router, eller skicka en miljövariabel för WeaveNet.
Vad är problemet med felaktig MTU? Det här diagrammet visar skillnaden mellan WeaveNet med standard MTU och jumboramar aktiverade:
Hur påverkar MTU genomströmningen?
Vi har sett hur viktig MTU är för prestanda, låt oss nu se hur våra CNI:er automatiskt bestämmer det:
CNI upptäcker automatiskt MTU
Grafen visar att du behöver konfigurera MTU:n för Calico, Canal, Kube-router och WeaveNet för optimal prestanda. Cilium och Flannel kunde korrekt bestämma MTU själva utan några inställningar.
Безопасность
Vi kommer att jämföra CNI-säkerhet i två aspekter: förmågan att kryptera överförd data och implementeringen av Kubernetes nätverkspolicyer (baserat på verkliga tester, inte dokumentation).
Endast två CNI:er krypterar data: Cilium och WeaveNet. Kryptering WeaveNet aktiveras genom att ställa in krypteringslösenordet som en CNI-miljövariabel. I WeaveNet beskriver det på ett komplicerat sätt, men allt är enkelt gjort. Kryptering cilium konfigureras av kommandon, genom att skapa Kubernetes-hemligheter och genom modifiering av daemonSet (lite mer komplicerat än i WeaveNet, men Cilium har steg-för-steg ).
När det gäller implementeringen av nätverkspolicy har de lyckats Calico, Canal, Cilium och WeaveNet, där du kan konfigurera Ingress- och Egress-regler. För Kube-router det finns regler endast för Ingress, och Flanell Det finns inga nätverkspolicyer alls.
Här är de totala resultaten:
Säkerhetsprestanda benchmark-resultat
Производительность
Detta riktmärke visar den genomsnittliga genomströmningen under minst tre körningar av varje test. Vi testar prestandan för TCP och UDP (med iperf3), riktiga applikationer som HTTP (med Nginx och curl) eller FTP (med vsftpd och curl) och slutligen applikationsprestanda med SCP-baserad kryptering (med klient och server OpenSSH).
För alla tester utförde vi ett benchmark för ren metall (grön linje) för att jämföra CNI-prestanda med inbyggt nätverksprestanda. Här använder vi samma skala, men i färg:
- Gul = mycket bra
- Orange = bra
- Blått = så som så
- Rött = dåligt
Vi tar inte felaktigt konfigurerade CNI:er och visar endast resultat för CNI:er med rätt MTU. (Obs: Cilium beräknar inte MTU korrekt om du aktiverar kryptering, så du måste manuellt reducera MTU till 8900 i version 1.4. Nästa version, 1.5, gör detta automatiskt.)
Här är resultaten:
TCP-prestanda
Alla CNI presterade bra i TCP-riktmärket. CNI med kryptering ligger långt efter eftersom kryptering är dyrt.
UDP-prestanda
Även här går det bra för alla CNI. CNI med kryptering visade nästan samma resultat. Cilium ligger lite efter konkurrenterna, men det är bara 2,3 % av ren metall, så det är inget dåligt resultat. Glöm inte att endast Cilium och Flannel bestämt MTU korrekt själva, och detta är deras resultat utan någon ytterligare konfiguration.
Vad sägs om en riktig applikation? Som du kan se är den totala prestandan för HTTP något lägre än för TCP. Även om du använder HTTP med TCP, konfigurerade vi iperf3 i TCP-riktmärket för att undvika en långsam start som skulle påverka HTTP-riktmärket. Alla gjorde ett bra jobb här. Kube-routern har en klar fördel, men WeaveNet presterade inte bra: cirka 20 % sämre än ren metall. Cilium och WeaveNet med kryptering ser riktigt tråkiga ut.
Med FTP, ett annat TCP-baserat protokoll, varierar resultaten. Flanell och Kube-router gör jobbet, men Calico, Canal och Cilium ligger lite efter och är cirka 10 % långsammare än ren metall. WeaveNet ligger efter med hela 17 %, men krypterade WeaveNet ligger 40 % före krypterade Cilium.
Med SCP kan vi direkt se hur mycket SSH-kryptering kostar oss. Nästan alla CNI:er går bra, men WeaveNet släpar efter igen. Cilium och WeaveNet med kryptering förväntas vara värst på grund av dubbelkryptering (SSH + CNI).
Här är en sammanfattningstabell med resultaten:
Resursförbrukning
Låt oss nu jämföra hur CNI förbrukar resurser under tung belastning (under TCP-överföring, 10 Gbps). I prestandatester jämför vi CNI med ren metall (grön linje). För resursförbrukning, låt oss visa rena Kubernetes (lila linje) utan CNI och se hur många extra resurser CNI förbrukar.
Låt oss börja med minnet. Här är medelvärdet för nodernas RAM (exklusive buffertar och cache) i MB under överföring.
Minnesförbrukning
Flannel och Kube-router visade utmärkta resultat - endast 50 MB. Calico och Canal har vardera 70. WeaveNet förbrukar helt klart mer än de andra – 130 MB, och Cilium använder så mycket som 400.
Låt oss nu kontrollera CPU-tidsförbrukningen. Anmärkningsvärd: diagrammet visar inte procentsatser, men ppm, det vill säga 38 ppm för "bart järn" är 3,8%. Här är resultaten:
CPU-förbrukning
Calico, Canal, Flannel och Kube-router är mycket CPU-effektiva - bara 2% mer än Kubernetes utan CNI. WeaveNet ligger långt efter med 5% extra, följt av Cilium med 7%.
Här är en sammanfattning av resursförbrukning:
Resultat av
Tabell med alla resultat:
Allmänna benchmarkresultat
Slutsats
I den sista delen kommer jag att uttrycka min subjektiva åsikt om resultaten. Kom ihåg att detta riktmärke endast testar genomströmningen av en enda anslutning på ett mycket litet kluster (3 noder). Det gäller inte stora kluster (<50 noder) eller parallella anslutningar.
Jag rekommenderar att du använder följande CNI beroende på scenariot:
- Har du i ditt kluster noder med få resurser (flera GB RAM, flera kärnor) och du behöver inga säkerhetsfunktioner - välj Flanell. Detta är en av de mest kostnadseffektiva CNI:erna. Och den är kompatibel med en mängd olika arkitekturer (amd64, arm, arm64, etc.). Dessutom är detta en av två (den andra är Cilium) CNI som automatiskt kan bestämma MTU, så du behöver inte konfigurera någonting. Kube-routern är också lämplig, men den är inte som standard och du måste konfigurera MTU:n manuellt.
- Om det behövs kryptera nätverket för säkerhets skull, ta WeaveNet. Glöm inte att ange MTU-storleken om du använder jumboramar och aktivera kryptering genom att ange ett lösenord via en miljövariabel. Men det är bättre att glömma prestanda - det är kostnaden för kryptering.
- för normal användning ge råd Kalikå. Denna CNI används ofta i olika Kubernetes-distributionsverktyg (Kops, Kubespray, Rancher, etc.). Som med WeaveNet, se till att konfigurera MTU i ConfigMap om du använder jumboramar. Det är ett multifunktionellt verktyg som är effektivt när det gäller resursförbrukning, prestanda och säkerhet.
Och slutligen råder jag dig att följa utvecklingen cilium. Denna CNI har ett mycket aktivt team som arbetar mycket med sin produkt (funktioner, resursbesparingar, prestanda, säkerhet, klustring...) och de har mycket intressanta planer.
Visuellt diagram för CNI-val
Källa: will.com