CNI-prestandabedömning för Kubernetes över 10G-nätverk (augusti 2020)

TL; DR: Alla CNI:er fungerar som de ska, med undantag för Kube-Router och Kube-OVN, Calico, med undantag för automatisk MTU-detektering, är bäst.

Artikeluppdatering av mina tidigare kontroller (2018 и 2019), vid testtillfället använder jag Kubernetes 1.19 på Ubuntu 18.04 med uppdaterade CNI:er från och med augusti 2020.

Innan vi dyker in i mått...

Vad är nytt sedan april 2019?

• Kan testa på ditt eget kluster: Du kan köra tester på ditt eget kluster med vårt verktyg Kubernetes Network Benchmark: KNB
• Nya medlemmar har dykt upp
  • En förrätt från VMware Tanzu
  • Kube-OVN från alauda.io
• Nya scenarier: Aktuella kontroller kör "Pod-to-Pod" nätverksprestandatester, och ett nytt "Pod-to-Service"-skript har lagts till som kör tester närmare verkliga förhållanden. I praktiken fungerar din Pod med API med basen som en tjänst, och inte via Pod-ip-adressen (såklart kollar vi både TCP och UDP för båda scenarierna).
• Resursförbrukning: varje test har nu sin egen resursjämförelse
• Ta bort applikationstester: Vi gör inte längre HTTP-, FTP- och SCP-tester eftersom vårt fruktbara samarbete med communityn och CNI-underhållare har upptäckt ett gap mellan iperf-resultat över TCP och curl-resultat på grund av en försening i CNI-starten (de första sekunderna av Pod) start, vilket inte är typiskt i verkliga förhållanden).
• Öppen källkod: alla testkällor (skript, yml-inställningar och ursprungliga "rå" data) är tillgängliga här

Referenstestprotokoll

Protokollet beskrivs i detalj härObservera att den här artikeln handlar om Ubuntu 18.04 med standardkärnan.

Välja en CNI för bedömning

Denna testning syftar till att jämföra CNI:er konfigurerade med en yaml-fil (därför utesluts alla de som installerats av skript, såsom VPP och andra).

Våra utvalda CNI:er för jämförelse:

• Antrea v.0.9.1
• Calico v3.16
• Canal v3.16 (flanellnätverk + Calico-nätverkspolicyer)
• Cilium 1.8.2
• Flanell 0.12.0
• Kube-router senaste (2020–08–25)
• WeaveNet 2.7.0

Konfigurerar MTU för CNI

Först och främst kontrollerar vi effekten av automatisk MTU-detektering på TCP-prestanda:

Inverkan av MTU på TCP-prestanda

Ett ännu större gap hittas när du använder UDP:

Inverkan av MTU på UDP-prestanda

Med tanke på den ENORMA prestandapåverkan som avslöjades i testerna, vill vi skicka ett hoppbrev till alla CNI-underhållare: lägg till automatisk MTU-detektering till CNI. Du kommer att rädda kattungar, enhörningar och till och med den sötaste: den lilla Devop.

Men om du behöver använda CNI utan stöd för automatisk MTU-detektering kan du konfigurera det manuellt för att få prestanda. Observera att detta gäller Calico, Canal och WeaveNet.

Min lilla begäran till de medföljande CNI:erna...

CNI-testning: rådata

I det här avsnittet kommer vi att jämföra CNI med rätt MTU (bestäms automatiskt eller ställs in manuellt). Huvudmålet här är att visa rådata i grafer.

Färgförklaring:

• grått - prov (d.v.s. rent järn)
• grön - bandbredd över 9500 Mbps
• gul - bandbredd över 9000 Mbps
• orange - bandbredd över 8000 Mbps
• röd - bandbredd under 8000 Mbps
• blå - neutral (ej relaterad till bandbredd)

Resursförbrukning utan belastning

Kontrollera först och främst resursförbrukningen när klustret "sover".

Resursförbrukning utan belastning

Pod-to-Pod

Det här scenariot förutsätter att klientpodden ansluter direkt till serverpodden med sin IP-adress.

Pod-to-Pod-scenario

TCP

Pod-to-Pod TCP-resultat och motsvarande resursförbrukning:

UDP

Pod-to-Pod UDP-resultat och motsvarande resursförbrukning:

Pod-to-Service

Det här avsnittet är relevant för verkliga användningsfall, klientpodden ansluter till serverpodden via ClusterIP-tjänsten.

Pod-to-Service-skript

TCP

Pod-to-Service TCP-resultat och motsvarande resursförbrukning:

UDP

Pod-to-Service UDP-resultat och motsvarande resursförbrukning:

Nätverkspolicystöd

Bland alla ovanstående är den enda som inte stödjer politik Flanell. Alla andra implementerar nätverkspolicyer korrekt, inklusive inkommande och utgående. Bra jobbat!

CNI-kryptering

Bland de kontrollerade CNI:erna finns de som kan kryptera nätverksutbyte mellan Pods:

• Antrea använder IPsec
• Calico som använder wireguard
• Cilium använder IPsec
• WeaveNet använder IPsec

Bandbredd

Eftersom det finns färre CNI kvar, låt oss lägga alla scenarier i en graf:

Resursförbrukning

I det här avsnittet kommer vi att utvärdera resurserna som används vid bearbetning av Pod-to-Pod-kommunikation i TCP och UDP. Det är ingen idé att rita en Pod-to-Service-graf eftersom den inte ger ytterligare information.

Få alltid att falla på plats

Låt oss försöka upprepa alla grafer, vi introducerade lite subjektivitet här, och ersatte de faktiska värdena med orden "vwry fast", "low" etc.

Slutsats och mina slutsatser

Detta är lite subjektivt, eftersom jag förmedlar min egen tolkning av resultaten.

Jag är glad att nya CNI:er dök upp, Antrea presterade bra, många funktioner implementerades även i tidiga versioner: automatisk MTU-detektering, kryptering och enkel installation.

Om vi ​​jämför prestanda fungerar alla CNI:er bra, förutom Kube-OVN och Kube-Router. Kube-Router kunde inte heller upptäcka MTU, jag hittade inte ett sätt att konfigurera den någonstans i dokumentationen (här en begäran om detta ämne är öppen).

När det gäller resursförbrukning använder Cilium fortfarande mer RAM än andra, men tillverkaren riktar sig helt klart till stora kluster, vilket uppenbarligen inte är detsamma som ett test på ett trenodskluster. Kube-OVN förbrukar också mycket CPU- och RAM-resurser, men det är en ung CNI baserad på Open vSwitch (liksom Antrea presterar den bättre och förbrukar mindre).

Alla utom Flannel har nätverkspolicyer. Det är mycket troligt att han aldrig kommer att stödja dem, eftersom målet är enklare än en ångad kålrot: ju lättare, desto bättre.

Dessutom är bland annat krypteringsprestandan fantastisk. Calico är en av de äldsta CNI:erna, men kryptering lades till för ett par veckor sedan. De valde wireguard istället för IPsec, och enkelt uttryckt, det fungerar utmärkt och fantastiskt, och överskuggar helt andra CNI:er i den här delen av testningen. Naturligtvis ökar resursåtgången på grund av kryptering, men den uppnådda genomströmningen är värd det (Calico visade en sexfaldig förbättring i krypteringstestet jämfört med Cilium, som kommer på andra plats). Dessutom kan du aktivera wireguard när som helst efter att du har distribuerat Calico till klustret, och du kan också inaktivera det för en kort tid eller permanent om du vill. Men det är otroligt bekvämt! Vi påminner dig om att Calico för närvarande inte automatiskt upptäcker MTU (denna funktion är planerad för framtida versioner), så se till att konfigurera MTU om ditt nätverk stöder Jumbo Frames (MTU 9000).

Notera bland annat att Cilium kan kryptera trafik mellan klusternoder (och inte bara mellan Pods), vilket kan vara mycket viktigt för publika klusternoder.

Som en slutsats föreslår jag följande användningsfall:

• Behöver CNI för ett mycket litet kluster ELLER jag behöver ingen säkerhet: arbeta med Flanell, den lättaste och mest stabila CNI (han är också en av de äldsta, enligt legenden uppfanns han av Homo Kubernautus eller Homo Contaitorus). Du kanske också är intresserad av det mest geniala projektet K3S, kolla upp!
• Behöver CNI för ett vanligt kluster: Kalikå - ditt val, men glöm inte att konfigurera MTU vid behov. Du kan enkelt och naturligt spela med nätverkspolicyer, slå på och av kryptering, etc.
• Behöver CNI för (mycket) storskaligt kluster: Tja, testet visar inte beteendet hos stora kluster, jag skulle gärna göra tester, men vi har inte hundratals servrar med en 10Gbps-anslutning. Så det bästa alternativet är att köra ett modifierat test på dina noder, åtminstone med Calico och Cilium.

Källa: will.com