esta es mi actualizacion , que ahora se ejecuta en Kubernetes 1.14 con la última versión de CNI en abril de 2019.
En primer lugar, quiero agradecer al equipo de Cilium: los chicos me ayudaron a verificar y corregir los scripts de monitoreo de métricas.
Qué ha cambiado desde noviembre de 2018
Esto es lo que ha cambiado desde entonces (si está interesado):
franela sigue siendo la interfaz CNI más rápida y sencilla, pero aún no admite políticas de red ni cifrado.
Romana ya no es compatible, por lo que la hemos eliminado del punto de referencia.
¡WeaveNet ahora admite políticas de red para ingreso y salida! Pero la productividad ha disminuido.
En Calico, aún necesita configurar manualmente el tamaño máximo de paquete (MTU) para obtener el mejor rendimiento. Calico ofrece dos opciones para instalar CNI, por lo que puede prescindir de un repositorio ETCD separado:
- almacenar el estado en la API de Kubernetes como un almacén de datos (tamaño del clúster <50 nodos);
- almacenar el estado en la API de Kubernetes como un almacén de datos con un proxy Typha para aliviar la carga en la API de K8S (tamaño del clúster > 50 nodos).
Calico anunció su apoyo además de Istio para seguridad a 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 el cifrado habilitado.
Cilium ahora es más fácil de implementar gracias al operador ETCD integrado.
El equipo de Cilium ha intentado reducir algo de peso de su CNI reduciendo el consumo de memoria y los costes de CPU, pero sus competidores siguen siendo más ligeros.
Contexto de referencia
La prueba se ejecuta en tres servidores Supermicro no virtualizados con un conmutador Supermicro de 10 Gb. Los servidores se conectan directamente al conmutador mediante cables DAC SFP+ pasivos y se configuran en la misma VLAN con tramas gigantes (MTU 9000).
Kubernetes 1.14.0 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 hacer esto, utilizamos NodeSelector en implementaciones de Kubernetes.
Describiremos los resultados del benchmark en la siguiente escala:
Seleccionar un CNI como punto de referencia
Este es un punto de referencia sólo para el CNI de la lista de la sección Consulte la documentación oficial de Kubernetes. De los 9 CNI, tomaremos solo 6: excluiremos aquellos que son difíciles de instalar y/o no funcionan sin configuración según la documentación (Romana, Contiv-VPP y JuniperContrail/TungstenFabric).
Compararemos los siguientes CNI:
- Calicó v3.6
- Canal v3.6 (esencialmente franela para networking + Calico como firewall)
- Cilio 1.4.2
- Franela 0.11.0
- Enrutador Kube 0.2.5
- TejidoNet 2.5.1
Instalación
Cuanto más fácil sea instalar el CNI, mejor será nuestra primera impresión. Todos los CNI del punto de referencia son muy fáciles de instalar (con uno o dos comandos).
Como dijimos, los servidores y el conmutador están configurados con tramas gigantes habilitadas (configuramos la MTU en 9000). Estaríamos felices si CNI determinara automáticamente la MTU según la configuración de los adaptadores. Sin embargo, sólo Cilium y franela lograron esto. El resto de los CNI tienen solicitudes en GitHub para agregar el descubrimiento automático 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 MTU predeterminado y tramas jumbo habilitadas:
¿Cómo afecta MTU al rendimiento?
Hemos visto lo importante que es la MTU para el rendimiento, ahora veamos cómo nuestros CNI la determinan automáticamente:
CNI detecta automáticamente MTU
El gráfico muestra que necesita configurar la MTU para Calico, Canal, Kube-router y WeaveNet para obtener un rendimiento óptimo. Cilium y franela pudieron determinar correctamente la MTU por sí mismos 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 (basadas en pruebas reales, no en documentación).
Solo dos CNI cifran datos: Cilium y WeaveNet. Cifrado tejidonet habilitado estableciendo la contraseña de cifrado como una variable de entorno CNI. EN WeaveNet lo describe de forma complicada, pero todo se hace de forma sencilla. Cifrado Cilio configurado mediante comandos, creando secretos de Kubernetes y mediante la modificación del 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, lo han logrado Calico, Canal, Cilium y WeaveNet, en el que puede configurar reglas de entrada y salida. Para enrutador Kube hay reglas solo para el ingreso, y Franela No existen políticas de red en absoluto.
Aquí están los resultados generales:
Resultados de las pruebas comparativas de rendimiento de seguridad
Rendimiento
Este punto de referencia muestra el rendimiento promedio durante al menos tres ejecuciones de cada prueba. Probamos el rendimiento de TCP y UDP (usando iperf3), aplicaciones reales como HTTP (con Nginx y curl) o FTP (con vsftpd y curl) y finalmente el rendimiento de aplicaciones usando cifrado basado en SCP (usando cliente y servidor OpenSSH).
Para todas las pruebas, realizamos una prueba comparativa básica (línea verde) para comparar el rendimiento de CNI con el rendimiento de la red nativa. Aquí utilizamos la misma escala, pero en color:
- Amarillo = muy bueno
- naranja = bueno
- Azul = regular
- Rojo = malo
No aceptaremos CNI configurados incorrectamente y solo mostraremos resultados para CNI con la MTU correcta. (Nota: Cilium no calcula correctamente la MTU si habilita el cifrado, por lo que tendrá que reducir manualmente la MTU a 8900 en la versión 1.4. La próxima versión, 1.5, lo hace automáticamente).
Aquí están los resultados:
Rendimiento TCP
Todos los CNI obtuvieron buenos resultados en el punto de referencia TCP. CNI con cifrado va muy por detrás porque el cifrado es caro.
Rendimiento UDP
Aquí también a todos los CNI les va bien. El CNI con cifrado mostró casi el mismo resultado. Cilium está un poco por detrás de la competencia, pero solo representa el 2,3% del metal desnudo, por lo que no es un mal resultado. No olvide que solo Cilium y franela determinaron la MTU correctamente por sí mismos, y estos son sus resultados sin ninguna configuración adicional.
¿Qué tal una aplicación real? Como puede ver, el rendimiento general de HTTP es ligeramente inferior al de TCP. Incluso si usa HTTP con TCP, configuramos iperf3 en el punto de referencia de TCP para evitar un inicio lento que afectaría el punto de referencia de HTTP. Todos hicieron un buen trabajo aquí. Kube-router tiene una clara ventaja, pero WeaveNet no tuvo un buen desempeño: aproximadamente un 20% peor que el bare metal. Cilium y WeaveNet con cifrado parecen realmente tristes.
Con FTP, otro protocolo basado en TCP, los resultados varían. La franela y el enrutador Kube hacen el trabajo, pero Calico, Canal y Cilium están un poco por detrás y son aproximadamente un 10% más lentos que el metal desnudo. WeaveNet está por detrás hasta en un 17%, pero el WeaveNet cifrado está un 40% por delante del Cilium cifrado.
Con SCP podemos ver inmediatamente cuánto nos cuesta el cifrado SSH. A casi todos los CNI les está yendo bien, pero WeaveNet vuelve a quedarse atrás. Se espera que Cilium y WeaveNet con cifrado sean los peores debido al doble cifrado (SSH + CNI).
A continuación se muestra una tabla resumen con los resultados:
Consumo de recursos
Ahora comparemos cómo CNI consume recursos bajo cargas pesadas (durante la transferencia TCP, 10 Gbps). En las pruebas de rendimiento comparamos CNI con metal desnudo (línea verde). Para el consumo de recursos, mostremos Kubernetes puro (línea morada) sin CNI y veamos cuántos recursos adicionales consume CNI.
Empecemos por la memoria. Aquí está el valor promedio de la RAM de los nodos (excluyendo buffers y caché) en MB durante la transferencia.
Consumo de memoria
El enrutador franela y Kube mostraron excelentes resultados: solo 50 MB. Calico y Canal tienen 70 cada uno. WeaveNet claramente consume más que los demás: 130 MB, y Cilium usa hasta 400.
Ahora verifiquemos el consumo de tiempo de la CPU. Notable: el diagrama no muestra porcentajes, sino ppm, es decir, 38 ppm para “hierro desnudo” es 3,8%. Aquí están los resultados:
Consumo de CPU
Calico, Canal, Flannel y Kube-router son muy eficientes en CPU: solo un 2% más que Kubernetes sin CNI. WeaveNet se queda muy atrás con un 5% adicional, seguido por Cilium con un 7%.
A continuación se muestra un resumen del consumo de recursos:
resultados
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 única conexión en un clúster muy pequeño (3 nodos). No se aplica a clústeres grandes (<50 nodos) ni a conexiones paralelas.
Recomiendo utilizar los siguientes CNI según el escenario:
- ¿Tienes en tu grupo? nodos con pocos recursos (varios GB de RAM, varios núcleos) y no necesita funciones de seguridad: elija Franela. Este es uno de los CNI más rentables. Y es compatible con una amplia variedad de arquitecturas (amd64, arm, arm64, etc.). Además, este es uno de los dos CNI (el otro es Cilium) que pueden determinar automáticamente la MTU, por lo que no es necesario configurar nada. El enrutador Kube también es adecuado, pero no es estándar y deberá configurar manualmente la MTU.
- Si es necesario cifrar la red por seguridad, tome tejidonet. No olvide especificar el tamaño de MTU si está utilizando tramas gigantes y habilite el cifrado especificando una contraseña a través de una variable de entorno. Pero es mejor olvidarse del rendimiento: ese es el coste del cifrado.
- para uso normal советую Calicó. Este CNI se utiliza ampliamente en varias herramientas de implementación de Kubernetes (Kops, Kubespray, Rancher, etc.). Al igual que con WeaveNet, asegúrese de configurar la MTU en ConfigMap si usa tramas gigantes. Es una herramienta multifuncional y eficiente en términos de consumo de recursos, rendimiento y seguridad.
Y por último, te aconsejo que sigas el desarrollo. Cilio. Este CNI tiene un equipo muy activo que trabaja mucho en su producto (características, ahorro de recursos, rendimiento, seguridad, clustering...) y tienen planes muy interesantes.
Diagrama visual para la selección del CNI.
Fuente: habr.com