Dette er min oppdatering , som nå kjører på Kubernetes 1.14 med den nyeste CNI-versjonen fra april 2019.
Først av alt vil jeg takke Cilium-teamet: gutta hjalp meg med å sjekke og korrigere metrikkovervåkingsskriptene.
Hva har endret seg siden november 2018
Her er hva som har endret seg siden den gang (hvis du er interessert):
Flannel er fortsatt det raskeste og enkleste CNI-grensesnittet, men støtter fortsatt ikke nettverkspolicyer og kryptering.
Romana støttes ikke lenger, så vi har fjernet det fra referansen.
WeaveNet støtter nå nettverkspolicyer for Ingress og Egress! Men produktiviteten har gått ned.
I Calico må du fortsatt konfigurere maksimal pakkestørrelse (MTU) manuelt for best ytelse. Calico tilbyr to alternativer for å installere CNI, slik at du kan klare deg uten 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 å avlaste K8S API (klyngestørrelse > 50 noder).
Calico annonserte støtte på toppen av Istio for sikkerhet på applikasjonsnivå.
Cilium støtter nå kryptering! Cilium gir kryptering med IPSec-tunneler og tilbyr et alternativ til det krypterte WeaveNet-nettverket. Men WeaveNet er raskere enn Cilium med kryptering aktivert.
Cilium er nå enklere å distribuere takket være den innebygde ETCD-operatøren.
Cilium-teamet har prøvd å redusere vekten fra CNI ved å redusere minneforbruk og CPU-kostnader, men konkurrentene er fortsatt lettere.
Referansekontekst
Benchmark kjøres på tre ikke-virtualiserte Supermicro-servere med en 10 Gb Supermicro-svitsj. Serverne kobles direkte til switchen via passive DAC SFP+ kabler og er konfigurert på samme VLAN med jumborammer (MTU 9000).
Kubernetes 1.14.0 installert på Ubuntu 18.04 LTS med Docker 18.09.2 (standard Docker-versjonen i denne utgivelsen).
For å forbedre reproduserbarheten bestemte vi oss for å alltid konfigurere masteren på den første noden, plassere serverdelen av benchmarken på den andre serveren og klientdelen på den tredje. For å gjøre dette bruker vi NodeSelector i Kubernetes-distribusjoner.
Vi vil beskrive referanseresultatene på følgende skala:
Velge en CNI for en benchmark
Dette er en benchmark kun for CNI fra listen i seksjonen Se den offisielle Kubernetes-dokumentasjonen. Av de 9 CNI-ene tar vi bare 6: vi vil ekskludere de som er vanskelige å installere og/eller ikke fungerer uten konfigurasjon i henhold til dokumentasjonen (Romana, Contiv-VPP og JuniperContrail/TungstenFabric).
Vi vil sammenligne følgende CNI-er:
- Calico v3.6
- Canal v3.6 (i hovedsak Flannel for nettverk + Calico som brannmur)
- Cilium 1.4.2
- Flanell 0.11.0
- Kube-ruter 0.2.5
- WeaveNet 2.5.1
Installasjon
Jo enklere CNI er å installere, desto bedre blir førsteinntrykket vårt. Alle CNI-er fra benchmark er veldig enkle å installere (med en eller to kommandoer).
Som vi sa, er serverne og bryteren konfigurert med jumborammer aktivert (vi setter MTU til 9000). Vi ville vært glade hvis CNI automatisk bestemte MTUen basert på adapterenes konfigurasjon. Det var imidlertid bare Cilium og Flannel som klarte dette. Resten av CNI-ene har forespørsler på GitHub om å legge til automatisk MTU-oppdagelse, men vi vil konfigurere det manuelt ved å endre ConfigMap for Calico, Canal og Kube-ruter, eller sende en miljøvariabel for WeaveNet.
Hva er problemet med feil MTU? Dette diagrammet viser forskjellen mellom WeaveNet med standard MTU og jumborammer aktivert:
Hvordan påvirker MTU gjennomstrømningen?
Vi har sett hvor viktig MTU er for ytelse, la oss nå se hvordan våre CNI-er automatisk bestemmer det:
CNI oppdager automatisk MTU
Grafen viser at du må konfigurere MTU for Calico, Canal, Kube-ruter og WeaveNet for optimal ytelse. Cilium og Flannel var i stand til å bestemme MTU riktig selv uten noen innstillinger.
Безопасность
Vi vil sammenligne CNI-sikkerhet i to aspekter: evnen til å kryptere overførte data og implementering av Kubernetes nettverkspolicyer (basert på reelle tester, ikke dokumentasjon).
Bare to CNI-er krypterer data: Cilium og WeaveNet. Kryptering WeaveNet aktivert ved å angi krypteringspassordet som en CNI-miljøvariabel. I WeaveNet beskriver det på en komplisert måte, men alt er enkelt gjort. Kryptering cilium konfigurert av kommandoer, ved å lage Kubernetes-hemmeligheter, og gjennom modifikasjon av daemonSet (litt mer komplisert enn i WeaveNet, men Cilium har steg-for-steg ).
Når det gjelder implementeringen av nettverkspolitikken, har de lyktes Calico, Canal, Cilium og WeaveNet, der du kan konfigurere regler for inngang og utgang. Til Kube-ruter det er kun regler for Ingress, og Flanell Det er ingen nettverkspolicyer i det hele tatt.
Her er de samlede resultatene:
Resultater for sikkerhetsytelse
Производительность
Denne referansen viser gjennomsnittlig gjennomstrømning over minst tre kjøringer av hver test. Vi tester ytelsen til TCP og UDP (ved hjelp av iperf3), ekte applikasjoner som HTTP (med Nginx og curl) eller FTP (med vsftpd og curl) og til slutt applikasjonsytelse ved bruk av SCP-basert kryptering (ved hjelp av klient og server OpenSSH).
For alle testene utførte vi en benchmark for bare metall (grønn linje) for å sammenligne CNI-ytelse med innebygd nettverksytelse. Her bruker vi samme skala, men i farger:
- Gul = veldig bra
- Oransje = bra
- Blå = så som så
- Rød = dårlig
Vi tar ikke feilkonfigurerte CNI-er og viser kun resultater for CNI-er med riktig MTU. (Merk: Cilium beregner ikke MTU riktig hvis du aktiverer kryptering, så du må manuelt redusere MTU til 8900 i versjon 1.4. Den neste versjonen, 1.5, gjør dette automatisk.)
Her er resultatene:
TCP-ytelse
Alle CNI-er gjorde det bra i TCP-referansen. CNI med kryptering henger langt etter fordi kryptering er dyrt.
UDP-ytelse
Også her går det bra med alle CNI. CNI med kryptering viste nesten samme resultat. Cilium er litt bak konkurrentene, men det er bare 2,3 % av bart metall, så det er ikke et dårlig resultat. Ikke glem at bare Cilium og Flannel bestemte MTUen riktig selv, og dette er resultatene deres uten noen ekstra konfigurasjon.
Hva med en ekte applikasjon? Som du kan se, er den generelle ytelsen for HTTP litt lavere enn for TCP. Selv om du bruker HTTP med TCP, konfigurerte vi iperf3 i TCP-referansen for å unngå en treg start som ville påvirke HTTP-referansen. Alle gjorde en god jobb her. Kube-ruteren har en klar fordel, men WeaveNet presterte ikke bra: omtrent 20 % dårligere enn bart metall. Cilium og WeaveNet med kryptering ser veldig triste ut.
Med FTP, en annen TCP-basert protokoll, varierer resultatene. Flanell og Kube-ruter gjør jobben, men Calico, Canal og Cilium ligger litt bak og er omtrent 10 % tregere enn bart metall. WeaveNet ligger bak med hele 17 %, men kryptert WeaveNet ligger 40 % foran kryptert Cilium.
Med SCP kan vi umiddelbart se hvor mye SSH-kryptering koster oss. Nesten alle CNI-er gjør det bra, men WeaveNet henger etter igjen. Cilium og WeaveNet med kryptering er forventet verst på grunn av dobbel kryptering (SSH + CNI).
Her er en oppsummeringstabell med resultatene:
Ressursforbruk
La oss nå sammenligne hvordan CNI bruker ressurser under store belastninger (under TCP-overføring, 10 Gbps). I ytelsestester sammenligner vi CNI med bart metall (grønn linje). For ressursforbruk, la oss vise rene Kubernetes (lilla linje) uten CNI og se hvor mange ekstra ressurser CNI bruker.
La oss starte med hukommelsen. Her er gjennomsnittsverdien for nodens RAM (eksklusive buffere og cache) i MB under overføring.
Minneforbruk
Flannel og Kube-ruter viste utmerkede resultater - bare 50 MB. Calico og Canal har hver 70. WeaveNet bruker klart mer enn de andre – 130 MB, og Cilium bruker hele 400.
La oss nå sjekke CPU-tidsforbruket. Bemerkelsesverdig: diagrammet viser ikke prosenter, men ppm, det vil si at 38 ppm for "bart jern" er 3,8 %. Her er resultatene:
CPU-forbruk
Calico, Canal, Flannel og Kube-ruter er svært CPU-effektive - bare 2 % mer enn Kubernetes uten CNI. WeaveNet henger langt etter med 5 % ekstra, etterfulgt av Cilium på 7 %.
Her er en oppsummering av ressursforbruket:
Resultater av
Tabell med alle resultater:
Generelle referanseresultater
Konklusjon
I den siste delen vil jeg uttrykke min subjektive mening om resultatene. Husk at denne referansen kun tester gjennomstrømningen til en enkelt tilkobling på en veldig liten klynge (3 noder). Den gjelder ikke for store klynger (<50 noder) eller parallelle forbindelser.
Jeg anbefaler å bruke følgende CNI-er avhengig av scenariet:
- Har du i klyngen din noder med få ressurser (flere GB RAM, flere kjerner) og du trenger ikke sikkerhetsfunksjoner - velg Flanell. Dette er en av de mest kostnadseffektive CNI-ene. Og den er kompatibel med et bredt utvalg av arkitekturer (amd64, arm, arm64, etc.). I tillegg er dette en av to (den andre er Cilium) CNI som automatisk kan bestemme MTU, slik at du ikke trenger å konfigurere noe. Kube-ruteren er også egnet, men den er ikke som standard, og du må konfigurere MTU manuelt.
- Om nødvendig kryptere nettverket for sikkerhets skyld, ta WeaveNet. Ikke glem å spesifisere MTU-størrelsen hvis du bruker jumborammer, og aktiver kryptering ved å spesifisere et passord via en miljøvariabel. Men det er bedre å glemme ytelsen - det er kostnadene for kryptering.
- For normal bruk Jeg råder Calico. Denne CNI er mye brukt i ulike Kubernetes-distribusjonsverktøy (Kops, Kubespray, Rancher, etc.). Som med WeaveNet, sørg for å konfigurere MTU i ConfigMap hvis du bruker jumborammer. Det er et multifunksjonelt verktøy som er effektivt med tanke på ressursforbruk, ytelse og sikkerhet.
Og til slutt råder jeg deg til å følge utviklingen cilium. Denne CNI har et veldig aktivt team som jobber mye med produktet deres (funksjoner, ressursbesparelser, ytelse, sikkerhet, klynging...) og de har veldig interessante planer.
Visuelt diagram for CNI-valg
Kilde: www.habr.com