Kubernetes Network Plugin (CNI) Benchmark-resultater over 10 Gbps netværk (Opdateret: april 2019)

Dette er min opdatering tidligere benchmark, som nu kører på Kubernetes 1.14 med den seneste CNI-version fra april 2019.

Først og fremmest vil jeg gerne takke Cilium-teamet: fyrene hjalp mig med at tjekke og rette scripts til metrikovervågning.

Hvad har ændret sig siden november 2018

Her er, hvad der er ændret siden da (hvis du er interesseret):

Flannel er fortsat den hurtigste og enkleste CNI-grænseflade, men understøtter stadig ikke netværkspolitikker og kryptering.

Romana understøttes ikke længere, så vi har fjernet det fra benchmark.

WeaveNet understøtter nu netværkspolitikker for Ingress og Egress! Men produktiviteten er faldet.

I Calico skal du stadig manuelt konfigurere den maksimale pakkestørrelse (MTU) for den bedste ydeevne. Calico tilbyder to muligheder for at installere CNI, så du kan undvære et separat ETCD-lager:

• lagringstilstand i Kubernetes API som et datalager (klyngestørrelse < 50 noder);
• lagringstilstand i Kubernetes API som et datalager med en Typha-proxy for at lette belastningen på K8S API (klyngestørrelse > 50 noder).

Calico annoncerede support politikker på applikationsniveau oven på Istio for sikkerhed på applikationsniveau.

Cilium understøtter nu kryptering! Cilium giver kryptering med IPSec-tunneler og tilbyder et alternativ til det krypterede WeaveNet-netværk. Men WeaveNet er hurtigere end Cilium med kryptering aktiveret.

Cilium er nu nemmere at implementere takket være den indbyggede ETCD-operatør.

Cilium-teamet har forsøgt at reducere vægten fra deres CNI ved at reducere hukommelsesforbrug og CPU-omkostninger, men deres konkurrenter er stadig lettere.

Benchmark kontekst

Benchmark køres på tre ikke-virtualiserede Supermicro-servere med en 10 Gb Supermicro-switch. Serverne er forbundet direkte til switchen via passive DAC SFP+ kabler og er konfigureret på samme VLAN med jumborammer (MTU 9000).

Kubernetes 1.14.0 installeret på Ubuntu 18.04 LTS med Docker 18.09.2 (standard Docker-versionen i denne udgivelse).

For at forbedre reproducerbarheden besluttede vi altid at konfigurere masteren på den første node, placere serverdelen af ​​benchmark på den anden server og klientdelen på den tredje. For at gøre dette bruger vi NodeSelector i Kubernetes-implementeringer.

Vi vil beskrive benchmark-resultaterne på følgende skala:

Valg af en CNI for et benchmark

Dette er kun et benchmark for CNI fra listen i afsnittet om at skabe én masterklynge med kubeadm Se den officielle Kubernetes-dokumentation. Af de 9 CNI'er tager vi kun 6: vi udelukker dem, der er svære at installere og/eller ikke fungerer uden konfiguration i henhold til dokumentationen (Romana, Contiv-VPP og JuniperContrail/TungstenFabric).

Vi vil sammenligne følgende CNI'er:

• Calico v3.6
• Canal v3.6 (i det væsentlige Flannel til netværk + Calico som firewall)
• Cilium 1.4.2
• Flanell 0.11.0
• Kube-router 0.2.5
• WeaveNet 2.5.1

Installation

Jo nemmere CNI er at installere, jo bedre vil vores første indtryk være. Alle CNI'er fra benchmark er meget nemme at installere (med en eller to kommandoer).

Som vi sagde, er serverne og switchen konfigureret med jumbo-rammer aktiveret (vi indstiller MTU til 9000). Vi ville være glade, hvis CNI automatisk bestemte MTU'en baseret på adapternes konfiguration. Det lykkedes dog kun Cilium og Flannel. Resten af ​​CNI'erne har anmodninger på GitHub om at tilføje automatisk MTU-opdagelse, men vi vil konfigurere det manuelt ved at ændre ConfigMap for Calico, Canal og Kube-router eller sende en miljøvariabel til WeaveNet.

Hvad er problemet med forkert MTU? Dette diagram viser forskellen mellem WeaveNet med standard MTU og jumborammer aktiveret:

Hvordan påvirker MTU gennemløbet?

Vi har set, hvor vigtig MTU er for ydeevne, lad os nu se, hvordan vores CNI'er automatisk bestemmer det:

CNI registrerer automatisk MTU

Grafen viser, at du skal konfigurere MTU'en til Calico, Canal, Kube-router og WeaveNet for optimal ydeevne. Cilium og Flannel var i stand til korrekt at bestemme MTU'en selv uden nogen indstillinger.

Безопасность

Vi vil sammenligne CNI-sikkerhed i to aspekter: evnen til at kryptere transmitterede data og implementeringen af ​​Kubernetes-netværkspolitikker (baseret på reelle tests, ikke dokumentation).

Kun to CNI'er krypterer data: Cilium og WeaveNet. Kryptering WeaveNet aktiveret ved at indstille krypteringsadgangskoden som en CNI-miljøvariabel. I dokumentation WeaveNet beskriver det på en kompliceret måde, men alt er gjort enkelt. Kryptering cilium konfigureret af kommandoer, ved at skabe Kubernetes-hemmeligheder og gennem ændring af daemonSet (lidt mere kompliceret end i WeaveNet, men Cilium har trin-for-trin Kørselsvejledning).

Hvad angår implementeringen af ​​netværkspolitikken, er det lykkedes Calico, Canal, Cilium og WeaveNet, hvor du kan konfigurere regler for indgang og udgang. Til Kube-router der er kun regler for Ingress, og flannel Der er ingen netværkspolitikker overhovedet.

Her er de samlede resultater:

Sikkerhedspræstation benchmark resultater

Ydelse

Dette benchmark viser den gennemsnitlige gennemstrømning over mindst tre kørsler af hver test. Vi tester ydeevnen af ​​TCP og UDP (ved hjælp af iperf3), rigtige applikationer som HTTP (med Nginx og curl) eller FTP (med vsftpd og curl) og endelig applikationsydelse ved hjælp af SCP-baseret kryptering (ved hjælp af klient og server OpenSSH).

For alle tests udførte vi et benchmark for bart metal (grøn linje) for at sammenligne CNI-ydeevne med native netværksydelse. Her bruger vi samme skala, men i farver:

• Gul = meget god
• Orange = godt
• Blå = halvdårlig
• Rød = dårlig

Vi tager ikke forkert konfigurerede CNI'er og viser kun resultater for CNI'er med den korrekte MTU. (Bemærk: Cilium beregner ikke MTU'en korrekt, hvis du aktiverer kryptering, så du bliver nødt til manuelt at reducere MTU'en til 8900 i version 1.4. Den næste version, 1.5, gør dette automatisk.)

Her er resultaterne:

TCP ydeevne

Alle CNI'er klarede sig godt i TCP-benchmark. CNI med kryptering halter langt bagefter, fordi kryptering er dyrt.

UDP ydeevne

Også her har alle CNI'er det godt. CNI med kryptering viste næsten det samme resultat. Cilium er lidt efter konkurrenterne, men det er kun 2,3% af bart metal, så det er ikke et dårligt resultat. Glem ikke, at kun Cilium og Flannel bestemte MTU'en korrekt selv, og disse er deres resultater uden yderligere konfiguration.

Hvad med en rigtig applikation? Som du kan se, er den samlede ydeevne for HTTP lidt lavere end for TCP. Selvom du bruger HTTP med TCP, konfigurerede vi iperf3 i TCP-benchmark for at undgå en langsom start, der ville påvirke HTTP-benchmark. Alle gjorde et godt stykke arbejde her. Kube-router har en klar fordel, men WeaveNet klarede sig ikke godt: omkring 20 % dårligere end bart metal. Cilium og WeaveNet med kryptering ser virkelig triste ud.

Med FTP, en anden TCP-baseret protokol, varierer resultaterne. Flannel og Kube-router gør jobbet, men Calico, Canal og Cilium er lidt bagud og er omkring 10 % langsommere end bart metal. WeaveNet er bagud med hele 17 %, men krypteret WeaveNet er 40 % foran krypteret Cilium.

Med SCP kan vi med det samme se, hvor meget SSH-kryptering koster os. Næsten alle CNI'er klarer sig godt, men WeaveNet halter igen. Cilium og WeaveNet med kryptering er forventeligt de værste på grund af dobbeltkryptering (SSH + CNI).

Her er en oversigtstabel med resultaterne:

Ressourceforbrug

Lad os nu sammenligne, hvordan CNI bruger ressourcer under store belastninger (under TCP-overførsel, 10 Gbps). I præstationstests sammenligner vi CNI med bart metal (grøn linje). For ressourceforbrug, lad os vise rene Kubernetes (lilla linje) uden CNI og se, hvor mange ekstra ressourcer CNI bruger.

Lad os starte med hukommelsen. Her er gennemsnitsværdien for nodernes RAM (eksklusive buffere og cache) i MB under overførsel.

Hukommelsesforbrug

Flannel og Kube-router viste fremragende resultater - kun 50 MB. Calico og Canal har hver 70. WeaveNet bruger klart mere end de andre - 130 MB, og Cilium bruger hele 400.
Lad os nu tjekke CPU-tidsforbruget. Bemærkelsesværdigt: diagrammet viser ikke procenter, men ppm, det vil sige 38 ppm for "bart jern" er 3,8%. Her er resultaterne:

CPU forbrug

Calico, Canal, Flannel og Kube-router er meget CPU-effektive - kun 2% mere end Kubernetes uden CNI. WeaveNet halter langt bagud med 5% ekstra, efterfulgt af Cilium på 7%.

Her er en oversigt over ressourceforbrug:

Resultaterne af

Tabel med alle resultater:

Generelle benchmark resultater

Konklusion

I den sidste del vil jeg udtrykke min subjektive mening om resultaterne. Husk, at dette benchmark kun tester gennemløbet af en enkelt forbindelse på en meget lille klynge (3 noder). Det gælder ikke for store klynger (<50 noder) eller parallelle forbindelser.

Jeg anbefaler at bruge følgende CNI'er afhængigt af scenariet:

• Har du i din klynge noder med få ressourcer (flere GB RAM, flere kerner), og du behøver ikke sikkerhedsfunktioner - vælg flannel. Dette er en af ​​de mest omkostningseffektive CNI'er. Og den er kompatibel med en bred vifte af arkitekturer (amd64, arm, arm64 osv.). Derudover er dette en af ​​to (den anden er Cilium) CNI, der automatisk kan bestemme MTU'en, så du ikke behøver at konfigurere noget. Kube-router er også velegnet, men den er ikke som standard, og du skal manuelt konfigurere MTU'en.
• Om nødvendigt kryptere netværket for en sikkerheds skyld, tag WeaveNet. Glem ikke at angive MTU-størrelsen, hvis du bruger jumborammer, og aktiver kryptering ved at angive en adgangskode via en miljøvariabel. Men det er bedre at glemme alt om ydeevne - det er prisen på kryptering.
• for normal brug rådgive Calico. Denne CNI er meget brugt i forskellige Kubernetes-implementeringsværktøjer (Kops, Kubespray, Rancher osv.). Som med WeaveNet skal du sørge for at konfigurere MTU'en i ConfigMap, hvis du bruger jumborammer. Det er et multifunktionelt værktøj, der er effektivt i forhold til ressourceforbrug, ydeevne og sikkerhed.

Og endelig råder jeg dig til at følge udviklingen cilium. Denne CNI har et meget aktivt team, der arbejder meget på deres produkt (funktioner, ressourcebesparelser, ydeevne, sikkerhed, klyngedannelse...), og de har meget interessante planer.

Visuelt diagram for CNI-valg

Kilde: www.habr.com