CNI-ytelsesvurdering for Kubernetes over 10G-nettverk (august 2020)
TL; DR: Alle CNI-er fungerer som de skal, med unntak av Kube-Router og Kube-OVN, Calico, med unntak av automatisk MTU-deteksjon, er best.
Artikkeloppdatering av mine tidligere sjekker (2018 и 2019), på testtidspunktet bruker jeg Kubernetes 1.19 på Ubuntu 18.04 med oppdaterte CNI-er fra august 2020.
Før vi dykker inn i beregninger...
Hva er nytt siden april 2019?
Kan teste på din egen klynge: Du kan kjøre tester på din egen klynge ved hjelp av vårt verktøy Kubernetes Network Benchmark: knb
Nye scenarier: Gjeldende sjekker kjører "Pod-to-Pod" nettverksytelsestester, og et nytt "Pod-to-Service"-skript er lagt til som kjører tester nærmere virkelige forhold. I praksis fungerer din Pod med API med basen som en tjeneste, og ikke gjennom Pod-ip-adressen (selvfølgelig sjekker vi både TCP og UDP for begge scenariene).
Ressursforbruk: hver test har nå sin egen ressurssammenligning
Fjerning av applikasjonstester: Vi utfører ikke lenger HTTP-, FTP- og SCP-tester ettersom vårt fruktbare samarbeid med fellesskapet og CNI-vedlikeholdere har oppdaget et gap mellom iperf-resultater over TCP og curl-resultater på grunn av en forsinkelse i CNI-oppstart (de første sekundene av Pod) oppstart, som ikke er typisk under reelle forhold).
Åpen kildekode: alle testkilder (skript, yml-innstillinger og originale "rå" data) er tilgjengelige her
Referansetestprotokoll
Protokollen er beskrevet i detalj herVær oppmerksom på at denne artikkelen handler om Ubuntu 18.04 med standardkjernen.
Velge en CNI for vurdering
Denne testingen er rettet mot å sammenligne CNI-er konfigurert med én yaml-fil (derfor er alle de som er installert av skript, som VPP og andre, ekskludert).
Først av alt sjekker vi effekten av automatisk MTU-deteksjon på TCP-ytelsen:
Innvirkning av MTU på TCP-ytelse
Et enda større gap er funnet når du bruker UDP:
Innvirkning av MTU på UDP-ytelse
Gitt den ENORME ytelseseffekten som ble avslørt i testene, ønsker vi å sende et håpsbrev til alle CNI-vedlikeholdere: vennligst legg til automatisk MTU-deteksjon til CNI. Du vil redde kattunger, enhjørninger og til og med den søteste: den lille Devop.
Men hvis du trenger å bruke CNI uten støtte for automatisk MTU-deteksjon, kan du konfigurere den manuelt for å få ytelse. Vær oppmerksom på at dette gjelder Calico, Canal og WeaveNet.
Min lille forespørsel til de medfølgende CNI-ene...
CNI-testing: rådata
I denne delen vil vi sammenligne CNI med riktig MTU (bestemmes automatisk eller stilles inn manuelt). Hovedmålet her er å vise rådataene i grafer.
Fargeforklaring:
grå - prøve (dvs. bart jern)
grønn - båndbredde over 9500 Mbps
gul - båndbredde over 9000 Mbps
oransje - båndbredde over 8000 Mbps
rød - båndbredde under 8000 Mbps
blå - nøytral (ikke relatert til båndbredde)
Ressursforbruk uten belastning
Først av alt, sjekk ressursforbruket når klyngen "sover".
Ressursforbruk uten belastning
Pod-to-Pod
Dette scenariet forutsetter at klient-pod-en kobler seg direkte til server-pod ved hjelp av sin IP-adresse.
Pod-til-Pod-scenario
TCP
Pod-to-Pod TCP-resultater og tilsvarende ressursforbruk:
UDP
Pod-to-Pod UDP-resultater og tilsvarende ressursforbruk:
Pod-to-Service
Denne delen er relevant for reelle brukstilfeller, klient-pod kobles til server-pod via ClusterIP-tjenesten.
Pod-to-Service-skript
TCP
Pod-to-Service TCP-resultater og tilsvarende ressursforbruk:
UDP
Pod-to-Service UDP-resultater og tilsvarende ressursforbruk:
Nettverkspolitisk støtte
Blant alle de ovennevnte er den eneste som ikke støtter politikk Flannel. Alle andre implementerer nettverkspolicyer på riktig måte, inkludert inngående og utgående. Flott jobb!
CNI-kryptering
Blant de sjekkede CNI-ene er det de som kan kryptere nettverksutveksling mellom Pods:
Antrea bruker IPsec
Calico som bruker wireguard
Cilium bruker IPsec
WeaveNet bruker IPsec
båndbredde
Siden det er færre CNI-er igjen, la oss sette alle scenariene i én graf:
Ressursforbruk
I denne delen vil vi evaluere ressursene som brukes ved behandling av Pod-to-Pod-kommunikasjon i TCP og UDP. Det er ingen vits i å tegne en Pod-to-Service-graf siden den ikke gir ytterligere informasjon.
Sette alt sammen
La oss prøve å gjenta alle grafene, vi introduserte litt subjektivitet her, og erstattet de faktiske verdiene med ordene "vwry fast", "low", etc.
Konklusjon og mine konklusjoner
Dette er litt subjektivt, siden jeg formidler min egen tolkning av resultatene.
Jeg er glad for at nye CNI-er dukket opp, Antrea presterte bra, mange funksjoner ble implementert selv i tidlige versjoner: automatisk MTU-deteksjon, kryptering og enkel installasjon.
Hvis vi sammenligner ytelse, fungerer alle CNI-er bra, bortsett fra Kube-OVN og Kube-Router. Kube-Router var heller ikke i stand til å oppdage MTU, jeg fant ikke en måte å konfigurere den på noe sted i dokumentasjonen (her en forespørsel om dette emnet er åpen).
Når det gjelder ressursforbruk bruker Cilium fortsatt mer RAM enn andre, men produsenten sikter tydeligvis mot store klynger, noe som tydeligvis ikke er det samme som en test på en tre-node klynge. Kube-OVN bruker også mye CPU- og RAM-ressurser, men det er en ung CNI basert på Open vSwitch (som Antrea, den yter bedre og bruker mindre).
Alle unntatt Flannel har nettverkspolicyer. Det er svært sannsynlig at han aldri vil støtte dem, siden målet er enklere enn en dampet kålrot: jo lettere, jo bedre.
Også blant annet er krypteringsytelsen fantastisk. Calico er en av de eldste CNI-ene, men kryptering ble lagt til for bare et par uker siden. De valgte wireguard i stedet for IPsec, og enkelt sagt, det fungerer bra og fantastisk, og overskygger fullstendig andre CNI-er i denne delen av testingen. Naturligvis øker ressursforbruket på grunn av kryptering, men gjennomstrømningen som oppnås er verdt det (Calico viste en seksdobling i krypteringstesten sammenlignet med Cilium, som ligger på andreplass). Dessuten kan du aktivere wireguard når som helst etter at du har distribuert Calico til klyngen, og du kan også deaktivere den for en kort stund eller permanent hvis du ønsker det. Men det er utrolig praktisk! Vi minner deg om at Calico for øyeblikket ikke automatisk oppdager MTU (denne funksjonen er planlagt for fremtidige versjoner), så sørg for å konfigurere MTU hvis nettverket ditt støtter Jumbo Frames (MTU 9000).
Merk blant annet at Cilium kan kryptere trafikk mellom klyngenoder (og ikke bare mellom Pods), noe som kan være svært viktig for offentlige klyngenoder.
Som en konklusjon foreslår jeg følgende brukstilfeller:
Trenger CNI for en veldig liten klynge ELLER jeg trenger ikke sikkerhet: jobbe med Flanell, den letteste og mest stabile CNI (han er også en av de eldste, ifølge legenden ble han oppfunnet av Homo Kubernautus eller Homo Contaitorus). Du kan også være interessert i det mest geniale prosjektet k3s, Sjekk!
Trenger CNI for en vanlig klynge: Calico - ditt valg, men ikke glem å konfigurere MTU om nødvendig. Du kan enkelt og naturlig leke med nettverkspolicyer, slå kryptering av og på osv.
Trenger CNI for (veldig) storskala klynge: Vel, testen viser ikke oppførselen til store klynger, jeg vil gjerne utføre tester, men vi har ikke hundrevis av servere med en 10Gbps-tilkobling. Så det beste alternativet er å kjøre en modifisert test på nodene dine, i det minste med Calico og Cilium.