TL; DR: Alle CNI'er fungerer som de skal, med undtagelse af Kube-Router og Kube-OVN, Calico, med undtagelse af automatisk MTU-detektion, er den bedste.
Artikelopdatering af mine tidligere kontroller ( и ), på testtidspunktet bruger jeg Kubernetes 1.19 på Ubuntu 18.04 med opdaterede CNI'er fra august 2020.
Før vi dykker ned i metrics...
Hvad er nyt siden april 2019?
- Kan teste på din egen klynge: Du kan køre test på din egen klynge ved hjælp af vores værktøj Kubernetes Network Benchmark:
- Nye medlemmer er dukket op
- fra VMware Tanzu
- fra alauda.io
- Nye scenarier: Aktuelle kontroller kører "Pod-to-Pod" netværksydelsestests, og der er tilføjet et nyt "Pod-to-Service" script, der kører test tættere på de virkelige forhold. I praksis fungerer din Pod med API med basen som en service, og ikke gennem Pod-ip-adressen (selvfølgelig tjekker vi både TCP og UDP for begge scenarier).
- Ressourceforbrug: hver test har nu sin egen ressourcesammenligning
- Fjernelse af applikationstests: Vi laver ikke længere HTTP-, FTP- og SCP-tests, da vores frugtbare samarbejde med fællesskabet og CNI-vedligeholdere har afsløret en kløft mellem iperf-resultater over TCP og curl-resultater på grund af en forsinkelse i CNI-opstart (de første par sekunder af Pod) opstart, hvilket ikke er typisk under virkelige forhold).
- Open source: alle testkilder (scripts, yml-indstillinger og originale "rå" data) er tilgængelige
Referencetestprotokol
Protokollen er beskrevet i detaljer Bemærk venligst, at denne artikel handler om Ubuntu 18.04 med standardkernen.
Valg af en CNI til vurdering
Denne test er rettet mod at sammenligne CNI'er konfigureret med én yaml-fil (derfor er alle dem, der er installeret af scripts, såsom VPP og andre, udelukket).
Vores udvalgte CNI'er til sammenligning:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (Flannel-netværk + Calico-netværkspolitikker)
- Cilium 1.8.2
- Flanell 0.12.0
- Seneste Kube-router (2020–08–25)
- WeaveNet 2.7.0
Konfiguration af MTU til CNI
Først og fremmest kontrollerer vi virkningen af automatisk MTU-detektion på TCP-ydelse:
Indvirkning af MTU på TCP-ydelse
Et endnu større hul findes, når du bruger UDP:
Indvirkning af MTU på UDP-ydelse
I betragtning af den KÆMPE præstationspåvirkning afsløret i testene, vil vi gerne sende et håb til alle CNI-vedligeholdere: Tilføj venligst automatisk MTU-detektion til CNI. Du vil redde killinger, enhjørninger og endda den sødeste: den lille Devop.
Men hvis du skal bruge CNI uden understøttelse af automatisk MTU-detektion, kan du konfigurere det manuelt for at få ydeevne. Bemærk venligst, at dette gælder for Calico, Canal og WeaveNet.
Min lille anmodning til de medfølgende CNI'er...
CNI-test: rådata
I dette afsnit vil vi sammenligne CNI med den korrekte MTU (bestemt automatisk eller indstillet manuelt). Hovedmålet her er at vise de rå data i grafer.
Farveforklaring:
- grå - prøve (dvs. bart jern)
- grøn - båndbredde over 9500 Mbps
- gul - båndbredde over 9000 Mbps
- orange - båndbredde over 8000 Mbps
- rød - båndbredde under 8000 Mbps
- blå - neutral (ikke relateret til båndbredde)
Ressourceforbrug uden belastning
Først og fremmest skal du tjekke ressourceforbruget, når klyngen "sover".
Ressourceforbrug uden belastning
Pod-to-Pod
Dette scenarie antager, at klient-Pod'en opretter forbindelse direkte til server-Pod'en ved hjælp af dens IP-adresse.
Pod-til-Pod-scenarie
TCP
Pod-to-Pod TCP-resultater og tilsvarende ressourceforbrug:
UDP
Pod-to-Pod UDP-resultater og tilsvarende ressourceforbrug:
Pod-to-Service
Dette afsnit er relevant for reelle brugssager, klient-Pod'en forbinder til server-Pod'en via ClusterIP-tjenesten.
Pod-to-Service Script
TCP
Pod-to-Service TCP-resultater og tilsvarende ressourceforbrug:
UDP
Pod-to-Service UDP-resultater og tilsvarende ressourceforbrug:
Netværkspolitikstøtte
Blandt alle ovenstående er den eneste, der ikke støtter politik, Flannel. Alle andre implementerer netværkspolitikker korrekt, inklusive indgående og udgående. Godt arbejde!
CNI-kryptering
Blandt de kontrollerede CNI'er er der dem, der kan kryptere netværksudveksling mellem Pods:
- Antrea bruger IPsec
- Calico ved hjælp af wireguard
- Cilium ved hjælp af IPsec
- WeaveNet ved hjælp af IPsec
gennemløb
Da der er færre CNI'er tilbage, lad os sætte alle scenarierne i én graf:
Ressourceforbrug
I dette afsnit vil vi evaluere de ressourcer, der bruges ved behandling af Pod-to-Pod-kommunikation i TCP og UDP. Det nytter ikke at tegne en Pod-to-Service-graf, da den ikke giver yderligere information.
Samler det hele
Lad os prøve at gentage alle graferne, vi introducerede lidt subjektivitet her, og erstattede de faktiske værdier med ordene "vwry fast", "low" osv.
Konklusion og mine konklusioner
Dette er lidt subjektivt, da jeg formidler min egen fortolkning af resultaterne.
Jeg er glad for, at nye CNI'er dukkede op, Antrea klarede sig godt, mange funktioner blev implementeret selv i tidlige versioner: automatisk MTU-detektion, kryptering og nem installation.
Hvis vi sammenligner ydeevne, fungerer alle CNI'er godt, undtagen Kube-OVN og Kube-Router. Kube-Router var heller ikke i stand til at detektere MTU'en, jeg fandt ikke en måde at konfigurere den nogen steder i dokumentationen ( en anmodning om dette emne er åben).
Med hensyn til ressourceforbrug bruger Cilium stadig mere RAM end andre, men producenten retter sig klart efter store klynger, hvilket tydeligvis ikke er det samme som en test på en tre-node klynge. Kube-OVN bruger også mange CPU- og RAM-ressourcer, men det er en ung CNI baseret på Open vSwitch (som Antrea fungerer den bedre og med mindre forbrug).
Alle undtagen Flannel har netværkspolitikker. Det er meget sandsynligt, at han aldrig vil støtte dem, da målet er enklere end en dampet majroe: jo lettere, jo bedre.
Også blandt andet krypteringsydelsen er fantastisk. Calico er en af de ældste CNI'er, men kryptering blev først tilføjet for et par uger siden. De valgte wireguard i stedet for IPsec, og kort sagt fungerer det fantastisk og fantastisk, og overskygger fuldstændigt andre CNI'er i denne del af testen. Naturligvis stiger ressourceforbruget på grund af kryptering, men den opnåede gennemstrømning er det værd (Calico viste en seksdobling i krypteringstesten sammenlignet med Cilium, som ligger på andenpladsen). Desuden kan du aktivere wireguard til enhver tid, efter du har installeret Calico til klyngen, og du kan også deaktivere den i kort tid eller permanent, hvis du ønsker det. Det er dog utroligt praktisk! Vi minder dig om, at Calico i øjeblikket ikke automatisk registrerer MTU (denne funktion er planlagt til fremtidige versioner), så sørg for at konfigurere MTU'en, hvis dit netværk understøtter Jumbo Frames (MTU 9000).
Bemærk blandt andet, at Cilium kan kryptere trafik mellem cluster noder (og ikke kun mellem Pods), hvilket kan være meget vigtigt for offentlige cluster noder.
Som konklusion foreslår jeg følgende use cases:
- Har brug for CNI til en meget lille klynge ELLER jeg har ikke brug for sikkerhed: arbejde med flannel, den letteste og mest stabile CNI (han er også en af de ældste, ifølge legenden blev han opfundet af Homo Kubernautus eller Homo Contaitorus). Du kan også være interesseret i det mest geniale projekt , kontrollere!
- Har brug for CNI til en almindelig klynge: Calico - dit valg, men glem ikke at konfigurere MTU'en, hvis det er nødvendigt. Du kan nemt og naturligt lege med netværkspolitikker, slå kryptering til og fra osv.
- Brug for CNI til (meget) storskala klynge: Nå, testen viser ikke opførsel af store klynger, jeg ville være glad for at udføre test, men vi har ikke hundredvis af servere med en 10 Gbps forbindelse. Så den bedste mulighed er at køre en modificeret test på dine noder, i det mindste med Calico og Cilium.
Kilde: www.habr.com