ProHoster > blog > administratie > CNI-prestatiebeoordeling voor Kubernetes via 10G-netwerk (augustus 2020)
CNI-prestatiebeoordeling voor Kubernetes via 10G-netwerk (augustus 2020)
TL; DR: Alle CNI's werken zoals ze zouden moeten, met uitzondering van Kube-Router en Kube-OVN, Calico is, met uitzondering van automatische MTU-detectie, de beste.
Artikel-update van mijn eerdere controles (2018 и 2019), op het moment van testen gebruik ik Kubernetes 1.19 op Ubuntu 18.04 met bijgewerkte CNI's vanaf augustus 2020.
Voordat we in de statistieken duiken...
Wat is er nieuw sinds april 2019?
Kan testen op uw eigen cluster: Met onze tool kunt u tests uitvoeren op uw eigen cluster Kubernetes-netwerkbenchmark: KNB
Nieuwe scenario's: Bij de huidige controles worden "Pod-to-Pod"-netwerkprestatietests uitgevoerd, en er is een nieuw "Pod-to-Service"-script toegevoegd dat tests uitvoert die dichter bij de werkelijke omstandigheden komen. In de praktijk werkt uw Pod met API met de base as a service, en niet via het Pod ip-adres (uiteraard controleren wij voor beide scenario's zowel TCP als UDP).
Hulpbronnenverbruik: elke test heeft nu zijn eigen hulpbronnenvergelijking
Applicatietests verwijderen: We voeren niet langer HTTP-, FTP- en SCP-tests uit, omdat onze vruchtbare samenwerking met de gemeenschap en CNI-onderhouders een kloof heeft ontdekt tussen iperf-resultaten via TCP en curl-resultaten als gevolg van een vertraging bij het opstarten van CNI (de eerste paar seconden van Pod opstarten, wat niet gebruikelijk is in reële omstandigheden).
Open source: alle testbronnen (scripts, yml-instellingen en originele “ruwe” data) zijn beschikbaar hier
Referentietestprotocol
Het protocol wordt gedetailleerd beschreven hierHoud er rekening mee dat dit artikel gaat over Ubuntu 18.04 met de standaardkernel.
Een CNI selecteren voor beoordeling
Deze tests zijn gericht op het vergelijken van CNI's die zijn geconfigureerd met één yaml-bestand (daarom zijn alle bestanden die door scripts zijn geïnstalleerd, zoals VPP en andere, uitgesloten).
Allereerst controleren we de impact van automatische MTU-detectie op de TCP-prestaties:
Impact van MTU op TCP-prestaties
Er wordt een nog grotere kloof gevonden bij het gebruik van UDP:
Impact van MTU op UDP-prestaties
Gezien de ENORME prestatie-impact die uit de tests naar voren is gekomen, willen we graag een brief van hoop sturen naar alle CNI-onderhouders: voeg alstublieft automatische MTU-detectie toe aan CNI. Je redt kittens, eenhoorns en zelfs de schattigste: de kleine Devop.
Als u CNI echter moet gebruiken zonder ondersteuning voor automatische MTU-detectie, kunt u dit handmatig configureren om prestaties te verkrijgen. Let op: dit geldt voor Calico, Canal en WeaveNet.
Mijn kleine verzoek aan de begeleidende CNI's...
CNI-testen: ruwe gegevens
In deze sectie vergelijken we CNI met de juiste MTU (automatisch bepaald of handmatig ingesteld). Het belangrijkste doel hier is om de onbewerkte gegevens in grafieken weer te geven.
Kleur legende:
grijs - monster (d.w.z. blank ijzer)
groen - bandbreedte boven 9500 Mbps
geel - bandbreedte boven 9000 Mbps
oranje - bandbreedte boven 8000 Mbps
rood - bandbreedte lager dan 8000 Mbps
blauw - neutraal (niet gerelateerd aan bandbreedte)
Onbelast verbruik van hulpbronnen
Controleer allereerst het resourceverbruik wanneer het cluster “slaapt”.
Onbelast verbruik van hulpbronnen
Pod-tot-pod
In dit scenario wordt ervan uitgegaan dat de client-pod rechtstreeks verbinding maakt met de server-pod via zijn IP-adres.
Pod-tot-pod-scenario
TCP
Pod-to-Pod TCP-resultaten en bijbehorend bronnenverbruik:
UDP
Pod-to-Pod UDP-resultaten en bijbehorend bronnenverbruik:
Pod-naar-Service
Deze sectie is relevant voor echte gebruiksscenario's: de client Pod maakt verbinding met de server Pod via de ClusterIP-service.
Pod-to-Service-script
TCP
Pod-to-Service TCP-resultaten en bijbehorend resourceverbruik:
UDP
Pod-to-Service UDP-resultaten en bijbehorend resourceverbruik:
Ondersteuning van netwerkbeleid
Van al het bovenstaande is Flanel de enige die de politiek niet ondersteunt. Alle anderen implementeren het netwerkbeleid correct, inclusief inkomend en uitgaand. Goed werk!
CNI-codering
Onder de gecontroleerde CNI's bevinden zich degenen die de netwerkuitwisseling tussen Pods kunnen coderen:
Antrea gebruikt IPsec
Calico met draadbeschermer
Cilium gebruikt IPsec
WeaveNet gebruikt IPsec
Doorvoer
Omdat er minder CNI's over zijn, zetten we alle scenario's in één grafiek:
Het verbruik van hulpbronnen
In deze sectie evalueren we de bronnen die worden gebruikt bij het verwerken van Pod-to-Pod-communicatie in TCP en UDP. Het heeft geen zin om een Pod-to-Service-grafiek te tekenen, omdat deze geen aanvullende informatie biedt.
Alles op een rij zetten
Laten we proberen alle grafieken te herhalen, we hebben hier een beetje subjectiviteit geïntroduceerd, waarbij we de werkelijke waarden hebben vervangen door de woorden "vwry fast", "low", enz.
Conclusie en mijn conclusies
Dit is een beetje subjectief, aangezien ik mijn eigen interpretatie van de resultaten geef.
Ik ben blij dat er nieuwe CNI's zijn verschenen, Antrea goed presteerde, veel functies waren zelfs in vroege versies geïmplementeerd: automatische MTU-detectie, encryptie en eenvoudige installatie.
Als we de prestaties vergelijken, werken alle CNI's goed, behalve Kube-OVN en Kube-Router. Kube-Router kon de MTU ook niet detecteren, ik heb nergens in de documentatie een manier gevonden om deze te configureren (hier een verzoek over dit onderwerp is open).
Wat betreft het verbruik van hulpbronnen gebruikt Cilium nog steeds meer RAM dan andere, maar de fabrikant mikt duidelijk op grote clusters, wat duidelijk niet hetzelfde is als een test op een cluster met drie knooppunten. Kube-OVN verbruikt ook veel CPU- en RAM-bronnen, maar het is een jonge CNI gebaseerd op Open vSwitch (net als Antrea presteert het beter en verbruikt het minder).
Iedereen behalve Flanel heeft netwerkbeleid. Het is zeer waarschijnlijk dat hij ze nooit zal steunen, aangezien het doel eenvoudiger is dan een gestoomde raap: hoe lichter, hoe beter.
Ook zijn onder andere de encryptieprestaties verbluffend. Calico is een van de oudste CNI's, maar encryptie is pas een paar weken geleden toegevoegd. Ze kozen voor wireguard in plaats van IPsec, en simpel gezegd: het werkt geweldig en verbazingwekkend, en overtreft andere CNI's volledig in dit deel van de tests. Natuurlijk neemt het verbruik van hulpbronnen toe als gevolg van encryptie, maar de bereikte doorvoer is de moeite waard (Calico liet een zesvoudige verbetering zien in de encryptietest vergeleken met Cilium, dat op de tweede plaats staat). Bovendien kunt u wireguard op elk gewenst moment inschakelen nadat u Calico in het cluster heeft geïmplementeerd, en u kunt het ook voor een korte tijd of permanent uitschakelen als u dat wenst. Het is echter ongelooflijk handig! We herinneren u eraan dat Calico momenteel MTU niet automatisch detecteert (deze functie is gepland voor toekomstige versies), dus zorg ervoor dat u de MTU configureert als uw netwerk Jumbo Frames (MTU 9000) ondersteunt.
Houd er onder andere rekening mee dat Cilium verkeer tussen clusterknooppunten (en niet alleen tussen pods) kan coderen, wat erg belangrijk kan zijn voor openbare clusterknooppunten.
Als conclusie stel ik de volgende gebruiksscenario's voor:
CNI nodig voor een heel klein cluster OF ik heb geen beveiliging nodig: werk met Flanel, de lichtste en meest stabiele CNI (hij is ook een van de oudste, volgens de legende is hij uitgevonden door Homo Kubernautus of Homo Contaitorus). Mogelijk bent u ook geïnteresseerd in het meest ingenieuze project k3s, rekening!
CNI nodig voor een regulier cluster: Calico - uw keuze, maar vergeet niet de MTU te configureren indien nodig. U kunt eenvoudig en natuurlijk spelen met netwerkbeleid, encryptie in- en uitschakelen, enz.
CNI nodig voor (zeer) grootschalige cluster: Nou, de test laat niet het gedrag van grote clusters zien, ik zou graag tests uitvoeren, maar we hebben geen honderden servers met een 10Gbps-verbinding. De beste optie is dus om een aangepaste test uit te voeren op uw knooppunten, tenminste met Calico en Cilium.