Esta es una actualización de mi punto de referencia anterior , que ahora se ejecuta en Kubernetes 1.14 con la versión actual de CNI para abril de 2019.
En primer lugar, quiero agradecer al equipo de Cilium: los muchachos me ayudaron a verificar y corregir los scripts de monitoreo métrico.
Lo que ha cambiado desde noviembre de 2018
Esto es lo que ha cambiado desde entonces (si está interesado):
Flannel sigue siendo la interfaz más rápida y fácil de CNI, pero aún no es compatible con las políticas de red y el cifrado.
Romana ya no es compatible, por lo que lo eliminamos del punto de referencia.
¡WeaveNet ahora admite políticas de red para Ingress y Egress! Pero la productividad ha disminuido.
En Calico, aún necesita configurar manualmente el tamaño máximo de paquete (MTU) para un mejor rendimiento. Calico ofrece dos opciones de instalación CNI, por lo que puede prescindir de un repositorio ETCD separado:
- almacenamiento de estado en la API de Kubernetes como un almacén de datos (tamaño de clúster <50 nodos);
- almacenamiento de estado en la API de Kubernetes como un almacén de datos con el proxy Typha para aliviar la carga de la API K8S (tamaño del clúster> 50 nodos).
Calico anuncia soporte de políticas de nivel de aplicación sobre Istio para seguridad de nivel de aplicación.
¡Cilium ahora admite cifrado! Cilium proporciona cifrado con túneles IPSec y ofrece una alternativa a la red cifrada WeaveNet. Pero WeaveNet es más rápido que Cilium con cifrado habilitado.
Cilium ahora es más fácil de implementar, gracias al operador ETCD incorporado.
El equipo de Cilium trató de mantener el peso de su CNI, reduciendo el consumo de memoria y los costos de CPU, pero los competidores aún son más ligeros.
Contexto de referencia
El punto de referencia se ejecuta en tres servidores Supermicro no virtualizados con un conmutador Supermicro de 10 Gb. Los servidores se conectan directamente al conmutador mediante cables pasivos DAC SFP + y se configuran en la misma VLAN con tramas gigantes (MTU 9000).
Kubernetes 1.14.0 está instalado en Ubuntu 18.04 LTS con Docker 18.09.2 (la versión predeterminada de Docker en esta versión).
Para mejorar la reproducibilidad, decidimos configurar siempre el maestro en el primer nodo, colocar la parte del servidor del punto de referencia en el segundo servidor y la parte del cliente en el tercero. Para esto, utilizamos NodeSelector en las implementaciones de Kubernetes.
Los resultados de referencia se describirán en tal escala:
Elegir CNI para el punto de referencia
Este es un punto de referencia solo para CNI de la lista en la sección sobre la creación de un clúster maestro con kubeadm en la documentación oficial de Kubernetes. De CNI 9 tomamos solo 6: excluimos aquellos que son difíciles de instalar y / o no funcionan sin la configuración de la documentación (Romana, Contiv-VPP y JuniperContrail / TungstenFabric).
Compararemos los siguientes CNI:
- Calico v3.6
- Canal v3.6 (esencialmente una franela para redes + Calico como firewall)
- Cilium 1.4.2
- Franela 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Instalación
Cuanto más fácil sea instalar CNI, mejor será nuestra primera impresión. Todo el CNI del benchmark es muy simple de instalar (con uno o dos equipos).
Como dijimos, el servidor y el conmutador están configurados con tramas jumbo activadas (instalamos MTU 9000). Estaríamos contentos si CNI determinara automáticamente la MTU en función de la configuración del adaptador. Sin embargo, solo Cilium y Flannel se ocuparon de esto. El resto del CNI tiene solicitudes en GitHub para agregar detección automática de MTU, pero lo configuraremos manualmente cambiando el ConfigMap para Calico, Canal y Kube-router, o pasando una variable de entorno para WeaveNet.
¿Cuál es el problema con la MTU incorrecta? Este diagrama muestra la diferencia entre WeaveNet con las tramas MTU y jumbo predeterminadas habilitadas:
Cómo MTU afecta el ancho de banda
Descubrimos cuán importante es MTU para el rendimiento, y ahora veamos cómo nuestros CNI lo detectan automáticamente:
CNI detecta automáticamente MTU
El gráfico muestra que necesita configurar MTU para Calico, Canal, Kube-router y WeaveNet para un rendimiento óptimo. Cilium y Flannel pudieron determinar correctamente la MTU sin ninguna configuración.
Seguridad
Compararemos la seguridad de CNI en dos aspectos: la capacidad de cifrar los datos transmitidos y la implementación de políticas de red de Kubernetes (de acuerdo con pruebas reales, no de acuerdo con la documentación).
Solo dos CNI cifran datos: Cilium y WeaveNet. El cifrado WeaveNet se habilita configurando la contraseña de cifrado como una variable de entorno CNI. La documentación de WeaveNet describe que esto es complicado, pero todo se hace de manera simple. El cifrado de Cilium se configura mediante comandos, creando secretos de Kubernetes y modificando daemonSet (un poco más complicado que en WeaveNet, pero Cilium tiene instrucciones paso a paso).
En cuanto a la implementación de la política de red, Calico, Canal, Cilium y WeaveNet tuvieron éxito aquí, en el que puede configurar las reglas de entrada y salida. Para Kube-router, existen reglas solo para Ingress, mientras que Flannel no tiene políticas de red.
Aquí están los resultados generales:
Resultados de referencia para características de seguridad
Rendimiento
Este punto de referencia muestra el rendimiento promedio de al menos tres ejecuciones de cada prueba. Probamos el rendimiento de TCP y UDP (usando iperf3), aplicaciones reales, por ejemplo, HTTP (con Nginx y curl) o FTP (con vsftpd y curl), y finalmente, aplicaciones que usan cifrado basado en el protocolo SCP (usando cliente y servidor OpenSSH).
Para todas las pruebas, creamos un punto de referencia básico (línea verde) para comparar el rendimiento de CNI con el rendimiento de la red nativa. Aquí usamos la misma escala, pero color:
- Amarillo = muy bueno
- Naranja = bueno
- Azul = regular
- Rojo = malo
No tomaremos CNI configurados incorrectamente y solo mostraremos los resultados para CNI con la MTU correcta. (Nota: Cilium no considera correctamente la MTU si el cifrado está habilitado, por lo que deberá reducir manualmente la MTU a 8900 en la versión 1.4. En la próxima versión, 1.5, esto se hace automáticamente).
Aquí están los resultados:
Rendimiento TCP
Todos los CNI tuvieron un buen desempeño en el benchmark TCP. Los CNI cifrados están muy rezagados porque el cifrado es costoso.
Rendimiento UDP
Aquí, también, todo CNI está bien. Los CNI cifrados mostraron casi el mismo resultado. Cilium está ligeramente por detrás de sus competidores, pero es solo el 2.3% de metal desnudo, por lo que el resultado no es malo. No olvide que solo Cilium y Flannel determinaron correctamente la MTU, y estos son sus resultados sin configuración adicional.
¿Qué tal una aplicación real? Como puede ver, para HTTP, el rendimiento general es ligeramente inferior al de TCP. Incluso si usa HTTP con TCP, en el benchmark TCP configuramos iperf3 para evitar un inicio lento, y esto afectará el benchmark HTTP. Todo se hizo bien aquí. Kube-router tiene una clara ventaja, y WeaveNet se mostró no desde el mejor lado: aproximadamente un 20% peor que el metal desnudo. Cilium y WeaveNet con cifrado se ven muy tristes.
Con FTP, otro protocolo basado en TCP, los resultados son diferentes. La franela y el enrutador Kube hacen frente, mientras que Calico, Canal y Cilium están ligeramente por detrás y funcionan un 10% más lento que el metal desnudo. WeaveNet no alcanza hasta el 17%, pero WeaveNet con cifrado está un 40% por delante de Cilium cifrado.
Con SCP puede ver de inmediato lo que nos cuesta el cifrado SSH. Casi todos los CNI lo hacen, y WeaveNet se está quedando atrás nuevamente. Se espera que Cilium y WeaveNet con cifrado sean los peores de todos debido al doble cifrado (SSH + CNI).
Aquí hay una tabla resumen con los resultados:
Consumo de recursos
Ahora comparemos cómo CNI consume recursos bajo cargas pesadas (durante la transmisión a través de TCP, 10 Gb / s). En las pruebas de rendimiento, comparamos CNI con metal desnudo (línea verde). Para consumir recursos, mostraremos Kubernetes puros (línea púrpura) sin CNI y veremos cuántos recursos adicionales consume CNI.
Comencemos con la memoria. Aquí está el valor promedio de la memoria del host (sin búferes y caché) en MB durante la transferencia.
Consumo de memoria
Flannel y Kube-router mostraron excelentes resultados: solo 50 MB. Calico y Canal tienen 70 cada uno. WeaveNet claramente consume más que el resto: 130 MB, mientras que Cilium usa hasta 400.
Ahora verifiquemos el uso de la CPU. Notable : en el diagrama, no porcentajes, sino por mil, es decir, 38 ppm para "hierro desnudo", esto es 3.8%. Aquí están los resultados:
Consumo de CPU
Calico, Canal, Flannel y Kube-router usan la CPU de manera muy eficiente, solo un 2% más que Kubernetes sin CNI. WeaveNet está muy por detrás con un 5% adicional, seguido de Cilium - 7%.
Aquí hay un resumen del consumo de recursos:
Resumen
Tabla con todos los resultados:
Resultados generales de referencia
Conclusión
En la última parte, expresaré mi opinión subjetiva sobre los resultados. Recuerde que este punto de referencia solo prueba el rendimiento de una conexión en un clúster muy pequeño (3 nodos). No se aplica a grupos grandes (<50 nodos) o conexiones paralelas.
Recomiendo usar los siguientes CNI según el escenario:
- Tiene nodos con una pequeña cantidad de recursos en su clúster (varios GB de RAM, varios núcleos) y no necesita características de seguridad: elija Franela . Este es uno de los CNI más económicos. Y es compatible con una amplia variedad de arquitecturas (amd64, arm, arm64, etc.). Además, este es uno de los dos (el segundo es Cilium) CNI, que puede determinar automáticamente la MTU, para que no tenga que configurar nada. Kube-router también es adecuado, pero no es tan estándar y deberá configurar manualmente MTU.
- Si necesita cifrar la red por seguridad, tome WeaveNet . No olvide especificar el tamaño de la MTU, si usa marcos jumbo, y active el cifrado especificando una contraseña a través de una variable de entorno. Pero es mejor olvidarse del rendimiento: esta es la tarifa de cifrado.
- Para uso normal, recomiendo Calico . Este CNI se usa ampliamente en varias herramientas de implementación de Kubernetes (Kops, Kubespray, Rancher, etc.). Al igual que con WeaveNet, recuerde configurar la MTU en ConfigMap si usa tramas gigantes. Es una herramienta multifuncional, efectiva en términos de consumo de recursos, productividad y seguridad.
Y finalmente, te aconsejo que sigas el desarrollo de Cilium . Este CNI tiene un equipo muy activo que trabaja mucho en su producto (funciones, ahorro de recursos, productividad, seguridad, distribución de clústeres ...), y tienen planes muy interesantes.
Diagrama visual para la elección CNI