Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

TL; DR: Tots els CNI funcionen com haurien de funcionar, a excepció de Kube-Router i Kube-OVN, Calico, amb l'excepció de la detecció automàtica de MTU, és el millor.

Actualització de l'article dels meus controls anteriors (2018 и 2019), en el moment de la prova, estic fent servir Kubernetes 1.19 a Ubuntu 18.04 amb CNI actualitzats a l'agost de 2020.

Abans d'endinsar-nos en mètriques...

Què hi ha de nou des de l'abril de 2019?

  • Pot provar al vostre propi clúster: podeu executar proves al vostre propi clúster mitjançant la nostra eina Punt de referència de la xarxa Kubernetes: knb
  • Han aparegut nous membres
  • Nous escenaris: les comprovacions actuals executen proves de rendiment de la xarxa "Pod-to-Pod" i s'ha afegit un nou script "Pod-to-Service" que executa proves més properes a les condicions del món real. A la pràctica, el vostre Pod amb API funciona amb la base com a servei, i no a través de l'adreça IP del Pod (per descomptat, comprovem TCP i UDP per als dos escenaris).
  • Consum de recursos: ara cada prova té la seva pròpia comparació de recursos
  • Eliminació de proves d'aplicacions: ja no fem proves HTTP, FTP i SCP, ja que la nostra fructífera col·laboració amb la comunitat i els mantenedors de CNI ha descobert una bretxa entre els resultats iperf sobre TCP i els resultats curl a causa d'un retard en l'inici de CNI (els primers segons de Pod). arrencada, que no és habitual en condicions reals).
  • Codi obert: totes les fonts de prova (scripts, configuracions yml i dades "crues" originals) estan disponibles aquí

Protocol de prova de referència

El protocol es descriu detalladament aquíTingueu en compte que aquest article tracta sobre Ubuntu 18.04 amb el nucli predeterminat.

Selecció d'un CNI per a l'avaluació

Aquesta prova té com a objectiu comparar els CNI configurats amb un fitxer yaml (per tant, s'exclouen tots els instal·lats per scripts, com ara VPP i altres).

Els nostres CNI seleccionats per a la comparació:

  • Antrea v.0.9.1
  • Calico v3.16
  • Canal v3.16 (xarxa de franel·la + polítiques de xarxa Calico)
  • Cilium 1.8.2
  • Franela 0.12.0
  • Kube-router més recent (2020-08-25)
  • WeaveNet 2.7.0

Configuració de MTU per a CNI

En primer lloc, comprovem l'impacte de la detecció automàtica de MTU en el rendiment de TCP:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Impacte de la MTU en el rendiment de TCP

Es troba un buit encara més gran quan s'utilitza UDP:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)
Impacte de la MTU en el rendiment UDP

Tenint en compte l'ENORME impacte en el rendiment revelat a les proves, ens agradaria enviar una carta d'esperança a tots els mantenedors de CNI: si us plau, afegiu la detecció automàtica de MTU a CNI. Salvaràs gatets, unicorns i fins i tot el més maco: el petit Devop.

Tanmateix, si necessiteu utilitzar CNI sense suport per a la detecció automàtica de MTU, podeu configurar-lo manualment per obtenir rendiment. Tingueu en compte que això s'aplica a Calico, Canal i WeaveNet.

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)
La meva petita petició als CNIs acompanyants...

CNI Testing: Dades brutes

En aquesta secció, compararem el CNI amb el MTU correcte (determinat automàticament o configurat manualment). L'objectiu principal aquí és mostrar les dades en brut en gràfics.

Llegenda del color:

  • gris - mostra (és a dir, ferro nu)
  • verd: amplada de banda superior a 9500 Mbps
  • groc: ample de banda superior a 9000 Mbps
  • taronja: ample de banda superior a 8000 Mbps
  • vermell: ample de banda inferior a 8000 Mbps
  • blau - neutre (no relacionat amb l'ample de banda)

Consum de recursos sense càrrega

En primer lloc, comproveu el consum de recursos quan el clúster està "dorment".

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)
Consum de recursos sense càrrega

De beina a beina

Aquest escenari suposa que el Pod del client es connecta directament al Pod del servidor mitjançant la seva adreça IP.

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)
Escenari de pod a pod

TCP

Resultats TCP de pod a pod i el consum de recursos corresponent:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

UDP

Resultats d'UDP de pod a pod i el consum de recursos corresponent:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Pod-to-servei

Aquesta secció és rellevant per a casos d'ús real, el client Pod es connecta al servidor Pod mitjançant el servei ClusterIP.

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)
Script de pod a servei

TCP

Resultats TCP de pod-to-service i consum de recursos corresponent:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

UDP

Resultats d'UDP de pod-to-service i consum de recursos corresponent:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Suport a les polítiques de xarxa

Entre tot l'anterior, l'únic que no dóna suport a la política és la franela. Tots els altres implementen correctament les polítiques de xarxa, incloses les entrades i sortides. Bona feina!

Xifratge CNI

Entre els CNI comprovats hi ha els que poden xifrar l'intercanvi de xarxa entre Pods:

  • Antrea utilitzant IPsec
  • Calicó utilitzant cable de protecció
  • Cilium utilitzant IPsec
  • WeaveNet utilitzant IPsec

Ample de banda

Com que queden menys CNI, posem tots els escenaris en un gràfic:

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Consum de recursos

En aquesta secció, avaluarem els recursos utilitzats per processar la comunicació Pod-to-Pod en TCP i UDP. No serveix de res dibuixar un gràfic Pod-to-Service, ja que no proporciona informació addicional.

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Ajuntant-ho tot

Intentem repetir tots els gràfics, hem introduït una mica de subjectivitat aquí, substituint els valors reals per les paraules "vwry fast", "low", etc.

Avaluació del rendiment de CNI per a Kubernetes a través de la xarxa 10G (agost de 2020)

Conclusió i les meves conclusions

Això és una mica subjectiu, ja que estic transmetent la meva pròpia interpretació dels resultats.

M'alegro que hagin aparegut nous CNI, Antrea va funcionar bé, s'han implementat moltes funcions fins i tot en les primeres versions: detecció automàtica de MTU, xifratge i fàcil instal·lació.

Si comparem el rendiment, tots els CNI funcionen bé, excepte Kube-OVN i Kube-Router. Kube-Router tampoc no va poder detectar el MTU, no vaig trobar la manera de configurar-lo enlloc de la documentació (aquí una sol·licitud sobre aquest tema està oberta).

Pel que fa al consum de recursos, Cilium encara utilitza més memòria RAM que altres, però el fabricant s'orienta clarament a grans clústers, cosa que no és clarament el mateix que una prova en un clúster de tres nodes. Kube-OVN també consumeix molts recursos de CPU i RAM, però és un CNI jove basat en Open vSwitch (com Antrea, funciona millor i amb menys consum).

Tothom, excepte Flannel, té polítiques de xarxa. És molt probable que mai els doni suport, ja que l'objectiu és més senzill que un nap al vapor: com més lleuger, millor.

A més, entre altres coses, el rendiment del xifratge és sorprenent. Calico és un dels CNI més antics, però el xifratge només es va afegir fa un parell de setmanes. Van triar wireguard en lloc d'IPsec i, simplement, funciona genial i sorprenent, eclipsant completament altres CNI en aquesta part de la prova. Per descomptat, el consum de recursos augmenta a causa del xifratge, però el rendiment aconseguit val la pena (Calico va mostrar una millora de sis vegades en la prova de xifratge en comparació amb Cilium, que ocupa el segon lloc). A més, podeu activar Wireguard en qualsevol moment després de desplegar Calico al clúster, i també podeu desactivar-lo durant un temps curt o permanentment si ho voleu. És increïblement convenient, però! Us recordem que Calico actualment no detecta automàticament MTU (aquesta característica està prevista per a futures versions), així que assegureu-vos de configurar la MTU si la vostra xarxa admet Jumbo Frames (MTU 9000).

Entre altres coses, tingueu en compte que Cilium pot xifrar el trànsit entre nodes de clúster (i no només entre pods), cosa que pot ser molt important per als nodes de clúster públics.

Com a conclusió, suggereixo els següents casos d'ús:

  • Necessito CNI per a un clúster molt petit O no necessito seguretat: treballar amb Flanel, el CNI més lleuger i estable (també és un dels més antics, segons la llegenda va ser inventat per Homo Kubernautus o Homo Contaitorus). També us pot interessar el projecte més enginyós k3, comproveu!
  • Necessites CNI per a un clúster normal: Calic - la vostra elecció, però no us oblideu de configurar la MTU si cal. Podeu jugar de manera fàcil i natural amb polítiques de xarxa, activar i desactivar l'encriptació, etc.
  • Necessita CNI per a clúster (molt) gran escala: Bé, la prova no mostra el comportament dels grans clústers, m'agradaria fer proves, però no tenim centenars de servidors amb una connexió de 10 Gbps. Per tant, la millor opció és executar una prova modificada als vostres nodes, almenys amb Calico i Cilium.

Font: www.habr.com

Afegeix comentari