Esta é a miña actualización , que agora se executa en Kubernetes 1.14 coa última versión de CNI a partir de abril de 2019.
En primeiro lugar, quero agradecer ao equipo de Cilium: os rapaces axudáronme a comprobar e corrixir os guións de seguimento de métricas.
O que cambiou desde novembro de 2018
Aquí tes o que cambiou desde entón (se estás interesado):
Flannel segue a ser a interface CNI máis rápida e sinxela, pero aínda non admite políticas de rede e cifrado.
Romana xa non está soportada, polo que a eliminamos do benchmark.
WeaveNet agora admite políticas de rede para Ingress e Egress. Pero a produtividade diminuíu.
En Calico, aínda debes configurar manualmente o tamaño máximo de paquete (MTU) para obter o mellor rendemento. Calico ofrece dúas opcións para instalar CNI, polo que pode prescindir dun repositorio ETCD separado:
- estado de almacenamento na API de Kubernetes como almacén de datos (tamaño do clúster < 50 nodos);
- estado de almacenamento na API de Kubernetes como un almacén de datos cun proxy Typha para aliviar a carga da API K8S (tamaño do clúster > 50 nodos).
Calico anunciou apoio encima de Istio para a seguridade a nivel de aplicación.
Cilium agora admite o cifrado. Cilium ofrece cifrado con túneles IPSec e ofrece unha alternativa á rede cifrada WeaveNet. Pero WeaveNet é máis rápido que Cilium co cifrado activado.
Agora Cilium é máis fácil de implementar grazas ao operador ETCD integrado.
O equipo de Cilium tentou recortar algo de peso do seu CNI reducindo o consumo de memoria e os custos da CPU, pero os seus competidores aínda son máis lixeiros.
Contexto de referencia
O benchmark execútase en tres servidores Supermicro non virtualizados cun interruptor Supermicro de 10 Gb. Os servidores están conectados directamente ao switch mediante cables DAC SFP+ pasivos e están configurados na mesma VLAN con marcos jumbo (MTU 9000).
Kubernetes 1.14.0 instalado en Ubuntu 18.04 LTS con Docker 18.09.2 (a versión predeterminada de Docker nesta versión).
Para mellorar a reproducibilidade, decidimos configurar sempre o mestre no primeiro nodo, colocar a parte do servidor do benchmark no segundo servidor e a parte cliente no terceiro. Para iso, usamos NodeSelector nos despregamentos de Kubernetes.
Describiremos os resultados do benchmark na seguinte escala:
Selección dun CNI para un benchmark
Este é un punto de referencia só para CNI da lista da sección Consulta a documentación oficial de Kubernetes. Dos 9 CNI, levaremos só 6: excluiremos aqueles que sexan de difícil instalación e/ou non funcionen sen configuración segundo a documentación (Romana, Contiv-VPP e JuniperContrail/TungstenFabric).
Compararemos os seguintes CNI:
- Calico v3.6
- Canal v3.6 (esencialmente Flannel para redes + Calico como firewall)
- Cilio 1.4.2
- Franela 0.11.0
- Kube-router 0.2.5
- WeaveNet 2.5.1
Instalación
Canto máis fácil sexa a instalación do CNI, mellor será a nosa primeira impresión. Todos os CNI do benchmark son moi sinxelos de instalar (cun ou dous comandos).
Como dixemos, os servidores e o switch están configurados con cadros jumbo activados (configuramos o MTU en 9000). Estaríamos encantados se CNI determinase automaticamente o MTU en función da configuración dos adaptadores. Non obstante, só Cilium e Flannel lograron isto. O resto dos CNI teñen solicitudes en GitHub para engadir o descubrimento automático de MTU, pero configurarémolo manualmente cambiando o ConfigMap para Calico, Canal e Kube-router, ou pasando unha variable de ambiente para WeaveNet.
Cal é o problema co MTU incorrecto? Este diagrama mostra a diferenza entre WeaveNet co MTU predeterminado e os cadros jumbo activados:
Como afecta o MTU ao rendemento?
Vimos o importante que é a MTU para o rendemento, agora vexamos como o determinan automaticamente os nosos CNI:
CNI detecta automaticamente MTU
O gráfico mostra que cómpre configurar o MTU para Calico, Canal, Kube-router e WeaveNet para obter un rendemento óptimo. Cilium e Flannel puideron determinar correctamente o MTU sen ningunha configuración.
Безопасность
Compararemos a seguridade do CNI en dous aspectos: a capacidade de cifrar os datos transmitidos e a implementación de políticas de rede de Kubernetes (baseadas en probas reais, non en documentación).
Só dous CNI cifran datos: Cilium e WeaveNet. Cifrado WeaveNet habilitado configurando o contrasinal de cifrado como unha variable de ambiente CNI. EN WeaveNet descríbeo dun xeito complicado, pero todo faise de forma sinxela. Cifrado Cilio configurado por comandos, creando segredos de Kubernetes e modificando o daemonSet (un pouco máis complicado que en WeaveNet, pero Cilium ten paso a paso ).
En canto á implementación da política de rede, conseguírono Calico, Canal, Cilium e WeaveNet, no que pode configurar regras de entrada e saída. Para Enrutador Kube só hai regras para Ingress, e Flanela Non hai políticas de rede en absoluto.
Aquí están os resultados xerais:
Resultados de referencia de rendemento de seguridade
Produtividade
Este punto de referencia mostra o rendemento medio de polo menos tres execucións de cada proba. Probamos o rendemento de TCP e UDP (usando iperf3), aplicacións reais como HTTP (con Nginx e curl) ou FTP (con vsftpd e curl) e, finalmente, o rendemento das aplicacións mediante o cifrado baseado en SCP (usando cliente e servidor OpenSSH).
Para todas as probas, realizamos un punto de referencia simple (liña verde) para comparar o rendemento do CNI co rendemento da rede nativa. Aquí usamos a mesma escala, pero en cor:
- Amarelo = moi bo
- Laranxa = bo
- Azul = así
- Vermello = malo
Non tomaremos CNI configurados incorrectamente e só mostraremos os resultados dos CNI coa MTU correcta. (Nota: Cilium non calcula correctamente o MTU se activas o cifrado, polo que terás que reducir manualmente o MTU a 8900 na versión 1.4. A seguinte versión, 1.5, faino automaticamente.)
Aquí están os resultados:
Rendemento TCP
Todos os CNI tiveron un bo rendemento no benchmark TCP. CNI con cifrado queda moi atrás porque o cifrado é caro.
Rendemento UDP
Tamén aquí todos os CNI están ben. CNI con cifrado mostrou case o mesmo resultado. Cilium está un pouco por detrás da competencia, pero é só un 2,3% do bare metal, polo que non é un mal resultado. Non esquezas que só Cilium e Flannel determinaron correctamente o MTU eles mesmos, e estes son os seus resultados sen ningunha configuración adicional.
E unha aplicación real? Como podes ver, o rendemento xeral de HTTP é lixeiramente inferior ao de TCP. Aínda que use HTTP con TCP, configuramos iperf3 no benchmark TCP para evitar un inicio lento que afectaría ao benchmark HTTP. Aquí todos fixeron un bo traballo. Kube-router ten unha clara vantaxe, pero WeaveNet non funcionou ben: preto dun 20% peor que o bare metal. Cilium e WeaveNet con cifrado parecen moi tristes.
Con FTP, outro protocolo baseado en TCP, os resultados varían. Flannel e Kube-router fan o traballo, pero Calico, Canal e Cilium están un pouco atrasados e son un 10% máis lentos que o bare metal. WeaveNet está por detrás de ata un 17%, pero WeaveNet cifrado está un 40% por diante do Cilium cifrado.
Con SCP podemos ver inmediatamente canto nos custa o cifrado SSH. Case todos os CNI están a facer ben, pero WeaveNet volve quedar atrás. Cilium e WeaveNet con cifrado son previsiblemente os peores debido ao dobre cifrado (SSH + CNI).
Aquí tedes unha táboa resumo cos resultados:
Consumo de recursos
Agora imos comparar como CNI consome recursos baixo cargas pesadas (durante a transferencia TCP, 10 Gbps). Nas probas de rendemento comparamos CNI con metal nu (liña verde). Para o consumo de recursos, mostremos Kubernetes puros (liña morada) sen CNI e vexamos cantos recursos adicionais consume CNI.
Comecemos pola memoria. Este é o valor medio da memoria RAM dos nodos (excluíndo os búfers e a caché) en MB durante a transferencia.
Consumo de memoria
Flannel e Kube-router mostraron excelentes resultados: só 50 MB. Calico e Canal teñen cada un 70. WeaveNet consome claramente máis que os outros: 130 MB, e Cilium usa ata 400.
Agora imos comprobar o consumo de tempo da CPU. Digna de mención: o diagrama non mostra porcentaxes, senón ppm, é dicir, 38 ppm para "ferro nu" é 3,8%. Aquí están os resultados:
Consumo de CPU
Calico, Canal, Flannel e Kube-router son moi eficientes na CPU: só un 2% máis que Kubernetes sen CNI. WeaveNet queda moi atrás cun 5% adicional, seguido de Cilium cun 7%.
Aquí tes un resumo do consumo de recursos:
Resultados de
Táboa con todos os resultados:
Resultados xerais de referencia
Conclusión
Na última parte expresarei a miña opinión subxectiva sobre os resultados. Lembra que este punto de referencia só proba o rendemento dunha única conexión nun clúster moi pequeno (3 nodos). Non se aplica a grandes clústeres (<50 nodos) nin conexións paralelas.
Recomendo usar os seguintes CNI dependendo do escenario:
- Tes no teu clúster nodos con poucos recursos (varios GB de RAM, varios núcleos) e non necesitas funcións de seguranza: escolle Flanela. Este é un dos CNI máis rendibles. E é compatible cunha gran variedade de arquitecturas (amd64, arm, arm64, etc.). Ademais, este é un dos dous CNI (o outro é Cilium) que poden determinar automaticamente o MTU, polo que non tes que configurar nada. O Kube-router tamén é adecuado, pero non é o estándar e terás que configurar manualmente o MTU.
- Se é necesario cifrar a rede por seguridade, toma WeaveNet. Non esquezas especificar o tamaño da MTU se estás a usar marcos jumbo e activa o cifrado especificando un contrasinal a través dunha variable de ambiente. Pero é mellor esquecerse do rendemento: ese é o custo do cifrado.
- Para uso normal Советую chita. Este CNI é moi utilizado en varias ferramentas de implantación de Kubernetes (Kops, Kubespray, Rancher, etc.). Do mesmo xeito que con WeaveNet, asegúrate de configurar a MTU en ConfigMap se usas marcos jumbo. É unha ferramenta multifuncional que é eficiente en termos de consumo de recursos, rendemento e seguridade.
E, finalmente, aconsello que siga o desenvolvemento Cilio. Este CNI ten un equipo moi activo que traballa moito no seu produto (funcións, aforro de recursos, rendemento, seguridade, clustering...) e teñen plans moi interesantes.
Diagrama visual para a selección do CNI
Fonte: www.habr.com