TL; DR: Todos los CNI funcionan como deberían, a excepción de Kube-Router y Kube-OVN, Calico, a excepción de la detección automática de MTU, es el mejor.
Artículo-actualización de mis cheques pasados ( и ), en el momento de la prueba estoy usando Kubernetes 1.19 en Ubuntu 18.04 con CNI actualizados a agosto de 2020.
Antes de sumergirnos en las métricas...
¿Qué hay de nuevo desde abril de 2019?
- Puede realizar pruebas en su propio clúster: puede ejecutar pruebas en su propio clúster utilizando nuestra herramienta Punto de referencia de la red Kubernetes:
- Han aparecido nuevos miembros
- de VMware Tanzu
- de alauda.io
- Nuevos escenarios: las comprobaciones actuales ejecutan pruebas de rendimiento de red "Pod-to-Pod" y se ha agregado un nuevo script "Pod-to-Service" que ejecuta pruebas más cercanas a las condiciones del mundo real. En la práctica, su Pod con API funciona con la base como un servicio y no a través de la dirección IP del Pod (por supuesto, verificamos tanto TCP como UDP para ambos escenarios).
- Consumo de recursos: cada prueba ahora tiene su propia comparación de recursos
- Eliminación de pruebas de aplicaciones: ya no realizamos pruebas de HTTP, FTP y SCP debido a que nuestra fructífera colaboración con la comunidad y los mantenedores de CNI ha descubierto una brecha entre los resultados de iperf sobre TCP y los resultados de curl debido a un retraso en el inicio de CNI (los primeros segundos de Pod inicio, lo cual no es típico en condiciones reales).
- Código abierto: todas las fuentes de prueba (scripts, configuraciones yml y datos originales "sin procesar") están disponibles
Protocolo de prueba de referencia
El protocolo se describe detalladamente. Tenga en cuenta que este artículo trata sobre Ubuntu 18.04 con el kernel predeterminado.
Seleccionar un CNI para la evaluación
Esta prueba tiene como objetivo comparar los CNI configurados con un archivo yaml (por lo tanto, se excluyen todos los instalados mediante scripts, como VPP y otros).
Nuestros CNI seleccionados para comparar:
- Antrea v.0.9.1
- Calicó v3.16
- Canal v3.16 (Red Franela + Políticas de Red Calico)
- Cilio 1.8.2
- Franela 0.12.0
- Último enrutador Kube (2020–08–25)
- TejidoNet 2.7.0
Configuración de MTU para CNI
En primer lugar, comprobamos el impacto de la detección automática de MTU en el rendimiento de TCP:
Impacto de MTU en el rendimiento de TCP
Se encuentra una brecha aún mayor cuando se utiliza UDP:
Impacto de MTU en el rendimiento de UDP
Dado el ENORME impacto en el rendimiento revelado en las pruebas, nos gustaría enviar una carta de esperanza a todos los mantenedores de CNI: agreguen la detección automática de MTU a CNI. Salvarás gatitos, unicornios y hasta al más lindo: el pequeño Devop.
Sin embargo, si necesita utilizar CNI sin soporte para la detección automática de MTU, puede configurarlo manualmente para obtener rendimiento. Tenga en cuenta que esto se aplica a Calico, Canal y WeaveNet.
Mi pequeña petición a los CNI acompañantes...
Pruebas CNI: datos sin procesar
En esta sección, compararemos el CNI con la MTU correcta (determinada automáticamente o configurada manualmente). El objetivo principal aquí es mostrar los datos sin procesar en gráficos.
Leyenda de colores:
- gris - muestra (es decir, hierro desnudo)
- verde: ancho de banda superior a 9500 Mbps
- amarillo: ancho de banda superior a 9000 Mbps
- naranja: ancho de banda superior a 8000 Mbps
- rojo: ancho de banda inferior a 8000 Mbps
- azul - neutral (no relacionado con el ancho de banda)
Consumo de recursos sin carga
En primer lugar, verifique el consumo de recursos cuando el clúster está "durmiendo".
Consumo de recursos sin carga
Pod a Pod
Este escenario supone que el Pod del cliente se conecta directamente al Pod del servidor utilizando su dirección IP.
Escenario de cápsula a cápsula
TCP
Resultados de TCP de pod a pod y consumo de recursos correspondiente:
UDP
Resultados de UDP de pod a pod y consumo de recursos correspondiente:
Pod-a-servicio
Esta sección es relevante para casos de uso reales, el Pod del cliente se conecta al Pod del servidor a través del servicio ClusterIP.
Script de pod a servicio
TCP
Resultados TCP de pod a servicio y consumo de recursos correspondiente:
UDP
Resultados UDP de pod a servicio y consumo de recursos correspondiente:
Soporte de políticas de red
De todos los anteriores, el único que no apoya la política es Franela. Todos los demás implementan correctamente las políticas de red, incluidas las entrantes y salientes. ¡Gran trabajo!
Cifrado CNI
Entre los CNI comprobados se encuentran aquellos que pueden cifrar el intercambio de red entre Pods:
- Antrea usando IPsec
- Calico usando protector de alambre
- Cilio usando IPsec
- WeaveNet usando IPsec
Ancho de banda
Como quedan menos CNI, pongamos todos los escenarios en un gráfico:
Consumo de recursos
En esta sección, evaluaremos los recursos utilizados al procesar la comunicación Pod-to-Pod en TCP y UDP. No tiene sentido dibujar un gráfico Pod-to-Service ya que no proporciona información adicional.
Poniendolo todo junto
Intentemos repetir todos los gráficos, aquí introdujimos un poco de subjetividad, reemplazando los valores reales con las palabras "muy rápido", "bajo", etc.
Conclusión y mis conclusiones.
Esto es un poco subjetivo, ya que estoy transmitiendo mi propia interpretación de los resultados.
Me alegro de que hayan aparecido nuevos CNI, Antrea funcionó bien, se implementaron muchas funciones incluso en las primeras versiones: detección automática de MTU, cifrado y fácil instalación.
Si comparamos el rendimiento, todos los CNI funcionan bien, excepto Kube-OVN y Kube-Router. Kube-Router tampoco pudo detectar la MTU, no encontré una manera de configurarla en ninguna parte de la documentación ( una solicitud sobre este tema está abierta).
En términos de consumo de recursos, Cilium todavía usa más RAM que otros, pero el fabricante apunta claramente a clústeres grandes, lo que claramente no es lo mismo que una prueba en un clúster de tres nodos. Kube-OVN también consume muchos recursos de CPU y RAM, pero es un CNI joven basado en Open vSwitch (como Antrea, funciona mejor y consume menos).
Todos, excepto franela, tienen políticas de red. Es muy probable que nunca los apoye, ya que el objetivo es más sencillo que un nabo al vapor: cuanto más ligero, mejor.
Además, entre otras cosas, el rendimiento del cifrado es sorprendente. Calico es uno de los CNI más antiguos, pero el cifrado se añadió hace sólo un par de semanas. Eligieron Wireguard en lugar de IPsec y, en pocas palabras, funciona de manera excelente y sorprendente, eclipsando por completo a otros CNI en esta parte de la prueba. Por supuesto, el consumo de recursos aumenta debido al cifrado, pero el rendimiento logrado vale la pena (Calico mostró una mejora seis veces mayor en la prueba de cifrado en comparación con Cilium, que ocupa el segundo lugar). Además, puede habilitar Wireguard en cualquier momento después de implementar Calico en el clúster, y también puede deshabilitarlo por un corto tiempo o de forma permanente si lo desea. ¡Sin embargo, es increíblemente conveniente! Le recordamos que Calico actualmente no detecta automáticamente MTU (esta función está prevista para versiones futuras), así que asegúrese de configurar la MTU si su red admite Jumbo Frames (MTU 9000).
Entre otras cosas, tenga en cuenta que Cilium puede cifrar el tráfico entre nodos del clúster (y no solo entre Pods), lo que puede ser muy importante para los nodos del clúster públicos.
Como conclusión, sugiero los siguientes casos de uso:
- Necesito CNI para un clúster muy pequeño O no necesito seguridad: trabajar con Franela, el CNI más ligero y estable (también es uno de los más antiguos, según la leyenda fue inventado por Homo Kubernautus u Homo Contaitorus). Quizás también te interese el proyecto más ingenioso , ¡controlar!
- Necesita CNI para un clúster normal: Calicó - tu elección, pero no olvides configurar la MTU si es necesario. Puede jugar fácil y naturalmente con las políticas de red, activar y desactivar el cifrado, etc.
- Necesita CNI para un clúster (muy) a gran escala: Bueno, la prueba no muestra el comportamiento de clústeres grandes, me encantaría realizar pruebas, pero no tenemos cientos de servidores con una conexión de 10 Gbps. Entonces, la mejor opción es ejecutar una prueba modificada en sus nodos, al menos con Calico y Cilium.
Fuente: habr.com