TL; DR: Todos os CNI funcionan como deberían, a excepción de Kube-Router e Kube-OVN, Calico, coa excepción da detección automática de MTU, é o mellor.
Actualización do artigo das miñas comprobacións anteriores ( и ), no momento da proba estou a usar Kubernetes 1.19 en Ubuntu 18.04 con CNI actualizado para agosto de 2020.
Antes de mergullarnos nas métricas...
Que novidades hai desde abril de 2019?
- Pode probar no seu propio clúster: pode realizar probas no seu propio clúster mediante a nosa ferramenta Kubernetes Network Benchmark:
- Apareceron novos membros
- de VMware Tanzu
- de alauda.io
- Novos escenarios: as comprobacións actuais executan probas de rendemento da rede "Pod-to-Pod" e engadiuse un novo script "Pod-to-Service" que executa probas máis próximas ás condicións do mundo real. Na práctica, o teu Pod con API funciona coa base como servizo, e non a través do enderezo IP do Pod (por suposto que comprobamos tanto TCP como UDP para ambos os escenarios).
- Consumo de recursos: cada proba ten agora a súa propia comparación de recursos
- Eliminación das probas de aplicacións: xa non facemos probas HTTP, FTP e SCP xa que a nosa fructífera colaboración coa comunidade e os mantedores de CNI descubriu unha brecha entre os resultados de iperf sobre TCP e os resultados de curl debido a un atraso no inicio de CNI (os primeiros segundos de Pod arranque, que non é típico en condicións reais).
- Código aberto: todas as fontes de proba (scripts, configuracións yml e datos orixinais "en bruto") están dispoñibles
Protocolo de proba de referencia
O protocolo descríbese en detalle , teña en conta que este artigo está dedicado a Ubuntu 18.04 co núcleo predeterminado.
Selección dun CNI para Avaliación
Esta proba ten como obxectivo comparar os CNI configurados cun ficheiro yaml (polo tanto, todos os instalados mediante scripts, como VPP e outros, quedan excluídos).
Os nosos CNI seleccionados para comparar:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (rede de franela + políticas de rede Calico)
- Cilio 1.8.2
- Franela 0.12.0
- Kube-router máis recente (2020-08-25)
- WeaveNet 2.7.0
Configuración de MTU para CNI
En primeiro lugar, comprobamos o impacto da detección automática de MTU no rendemento do TCP:
Impacto da MTU no rendemento do TCP
Atópase unha brecha aínda maior cando se usa UDP:
Impacto da MTU no rendemento UDP
Dado o ENORME impacto no rendemento revelado nas probas, gustaríanos enviar unha carta de esperanza a todos os mantedores de CNI: engade a detección automática de MTU a CNI. Salvarás gatiños, unicornios e ata o máis lindo: o pequeno Devop.
Non obstante, se precisas usar CNI sen compatibilidade coa detección automática de MTU, podes configuralo manualmente para obter rendemento. Teña en conta que isto aplícase a Calico, Canal e WeaveNet.
A miña pequena petición aos CNIs acompañantes...
CNI Testing: Raw Data
Nesta sección, compararemos o CNI co MTU correcto (determinado automaticamente ou configurado manualmente). O obxectivo principal aquí é mostrar os datos brutos en gráficos.
Lenda da cor:
- gris - mostra (é dicir, ferro nu)
- verde: ancho de banda superior a 9500 Mbps
- amarelo: ancho de banda superior a 9000 Mbps
- laranxa: ancho de banda superior a 8000 Mbps
- vermello: ancho de banda inferior a 8000 Mbps
- azul - neutro (non relacionado co ancho de banda)
Consumo de recursos sen carga
En primeiro lugar, comprobe o consumo de recursos cando o clúster está "durmindo".
Consumo de recursos sen carga
De vaina a vaina
Este escenario supón que o Pod cliente se conecta directamente ao Pod do servidor mediante o seu enderezo IP.
Escenario de pod a pod
TCP
Resultados TCP de pod a pod e consumo de recursos correspondente:
UDP
Resultados UDP de pod a pod e consumo de recursos correspondente:
Pod-to-Service
Esta sección é relevante para casos de uso reais, o Pod cliente conéctase ao Pod do servidor a través do servizo ClusterIP.
Script de pod a servizo
TCP
Resultados TCP de pod-to-service e consumo de recursos correspondente:
UDP
Resultados de Pod-to-Service UDP e consumo de recursos correspondente:
Apoio ás políticas de rede
Entre todo o anterior, o único que non apoia a política é a Franela. Todos os demais implementan correctamente as políticas de rede, incluídas as de entrada e de saída. Gran traballo!
Cifrado CNI
Entre os CNI marcados hai aqueles que poden cifrar o intercambio de rede entre Pods:
- Antrea usando IPsec
- Calico con axuda wireguard
- Cilium usando IPsec
- WeaveNet usando IPsec
Ancho de banda
Xa que quedan menos CNIs, poñamos todos os escenarios nun só gráfico:
Consumo de recursos
Nesta sección, avaliaremos os recursos empregados ao procesar a comunicación Pod-to-Pod en TCP e UDP. Non ten sentido debuxar un gráfico Pod-to-Service xa que non proporciona información adicional.
Xuntando todo
Tentemos repetir todos os gráficos, introducimos aquí un pouco de subxectividade, substituíndo os valores reais polas palabras "vwry fast", "low", etc.
Conclusión e as miñas conclusións
Isto é un pouco subxectivo, xa que estou a transmitir a miña propia interpretación dos resultados.
Alégrome de que aparecesen novos CNI, Antrea funcionou ben, implementáronse moitas funcións incluso nas primeiras versións: detección automática de MTU, cifrado e fácil instalación.
Se comparamos o rendemento, todos os CNI funcionan ben, excepto Kube-OVN e Kube-Router. Kube-Router tampouco puido detectar o MTU, non atopei unha forma de configuralo en ningún lugar da documentación ( está aberta unha solicitude sobre este tema).
En canto ao consumo de recursos, Cilium aínda usa máis memoria RAM que outros, pero o fabricante está claramente dirixido a grandes clústeres, o que claramente non é o mesmo que unha proba nun clúster de tres nodos. Kube-OVN tamén consome moitos recursos de CPU e RAM, pero é un CNI novo baseado en Open vSwitch (como Antrea, funciona mellor e consome menos).
Todos, excepto Flannel, teñen políticas de rede. É moi probable que nunca os apoie, xa que o obxectivo é máis sinxelo que un grelo ao vapor: canto máis lixeiro, mellor.
Ademais, o rendemento do cifrado é impresionante. Calico é un dos CNI máis antigos, pero o cifrado engadiuse hai só un par de semanas. Escolleron wireguard en lugar de IPsec, e dito de xeito sinxelo, todo funciona de forma brillante e sorprendente, desprazando por completo a outros CNI nesta parte da proba. Por suposto, o consumo de recursos aumenta debido ao cifrado, pero o rendemento acadado paga a pena (Calico demostrou unha vantaxe séxtuple sobre Cilium, que quedou en segundo lugar, na proba de cifrado). Ademais, podes activar wireguard En calquera momento despois de despregar Calico nun clúster, tamén podes desactivalo temporal ou permanentemente se o desexas. Isto é incriblemente cómodo, pero! Lembrámosche que Calico actualmente non detecta automaticamente a MTU (esta función está prevista para versións futuras), polo que asegúrate de configurar a MTU se a túa rede admite tramas xigantes (MTU 9000).
Entre outras cousas, teña en conta que Cilium pode cifrar o tráfico entre nodos do clúster (e non só entre Pods), o que pode ser moi importante para os nodos do clúster público.
Como conclusión, propoño os seguintes casos de uso:
- Necesito CNI para un clúster moi pequeno OU non necesito seguridade: traballar con Flanela, o CNI máis lixeiro e estable (tamén é un dos máis antigos, segundo a lenda foi inventado polo Homo Kubernautus ou Homo Contaitorus). Tamén che pode interesar o proxecto máis enxeñoso , comproba!
- Necesita CNI para un clúster normal: chita - a túa elección, pero non esquezas configurar a MTU se é necesario. Podes xogar de xeito sinxelo e natural coas políticas de rede, activar e desactivar o cifrado, etc.
- Necesita CNI para cluster (moi) grande: Ben, a proba non mostra o comportamento dos grandes clústeres, estaría encantado de realizar probas, pero non temos centos de servidores cunha conexión de 10 Gbps. Polo tanto, a mellor opción é realizar unha proba modificada nos teus nodos, polo menos con Calico e Cilium.
Fonte: www.habr.com
