Esta é uma atualização do meu benchmark anterior , que agora roda no Kubernetes 1.14 com a versão atual da CNI para abril de 2019.
Em primeiro lugar, quero agradecer à equipe do Cilium: os caras me ajudaram a verificar e corrigir os scripts de monitoramento de métricas.
O que mudou desde novembro de 2018
Aqui está o que mudou desde então (se estiver interessado):
A flanela continua sendo a interface mais rápida e fácil da CNI, mas ainda não suporta políticas de rede e criptografia.
O Romana não é mais suportado, por isso o removemos do benchmark.
O WeaveNet agora suporta políticas de rede para Ingress e Egress! Mas a produtividade diminuiu.
No Calico, você ainda precisa configurar manualmente o tamanho máximo de pacote (MTU) para obter melhor desempenho. O Calico oferece duas opções de instalação CNI, para que você possa fazer sem um repositório ETCD separado:
- armazenamento de estado na API Kubernetes como um armazenamento de dados (tamanho do cluster <50 nós);
- armazenamento de estado na API Kubernetes como um armazenamento de dados com o proxy Typha para aliviar a carga da API K8S (tamanho do cluster> 50 nós).
O Calico anuncia o suporte a políticas em nível de aplicativo no topo do Istio para segurança em nível de aplicativo.
Cilium agora suporta criptografia! O Cilium fornece criptografia com túneis IPSec e oferece uma alternativa à rede WeaveNet criptografada. Mas o WeaveNet é mais rápido que o Cilium com a criptografia ativada.
O Cilium agora é mais fácil de implantar - graças ao operador ETCD embutido.
A equipe da Cilium tentou manter o peso da CNI, reduzindo o consumo de memória e os custos de CPU, mas os concorrentes ainda são mais leves.
Contexto de referência
O benchmark é executado em três servidores Supermicro não virtualizados com um switch Supermicro de 10 Gb. Os servidores são conectados diretamente ao switch através de cabos DAC SFP + passivos e configurados na mesma VLAN com jumbo-frames (MTU 9000).
O Kubernetes 1.14.0 está instalado no Ubuntu 18.04 LTS com Docker 18.09.2 (a versão padrão do Docker nesta versão).
Para melhorar a reprodutibilidade, decidimos sempre configurar o mestre no primeiro nó, colocar a parte do servidor de referência no segundo servidor e a parte do cliente no terceiro. Para isso, usamos o NodeSelector nas implantações do Kubernetes.
Os resultados do benchmark serão descritos nessa escala:
Escolhendo a CNI como referência
Este é um benchmark apenas para CNI da lista na seção sobre como criar um cluster principal com o kubeadm na documentação oficial do Kubernetes. Da CNI 9, tomamos apenas 6: excluímos as que são difíceis de instalar e / ou não funcionam sem a configuração da documentação (Romana, Contiv-VPP e JuniperContrail / TungstenFabric).
Vamos comparar os seguintes CNIs:
- Calico v3.6
- Canal v3.6 (essencialmente uma Flanela para rede + Calico como firewall)
- Cilium 1.4.2
- Flanela 0.11.0
- Roteador Kube 0.2.5
- WeaveNet 2.5.1
Instalação
Quanto mais fácil for instalar a CNI, melhor será a nossa primeira impressão. Toda a CNI do benchmark é muito simples de instalar (com uma ou duas equipes).
Como dissemos, o servidor e o switch são configurados com os jumbo-frames ativados (instalamos o MTU 9000). Ficaríamos felizes se a CNI determinasse automaticamente o MTU com base nas configurações do adaptador. No entanto, apenas Cilium e Flannel lidaram com isso. O restante da CNI possui solicitações no GitHub para adicionar detecção automática de MTU, mas vamos configurá-lo manualmente alterando o ConfigMap para roteador Calico, Canal e Kube ou passando uma variável de ambiente para o WeaveNet.
Qual é o problema com o MTU errado? Este diagrama mostra a diferença entre o WeaveNet com os quadros MTU e jumbo padrão ativados:
Como o MTU afeta a largura de banda
Descobrimos a importância da MTU para o desempenho e agora vamos ver como nossos CNIs a detectam automaticamente:
CNI detecta automaticamente MTU
O gráfico mostra que você precisa configurar o MTU para o Calico, o Canal, o Kube-router e o WeaveNet para obter o desempenho ideal. Cilium e Flannel foram capazes de determinar corretamente o MTU sem nenhuma configuração.
Segurança
Compararemos a segurança da CNI em dois aspectos: a capacidade de criptografar os dados transmitidos e a implementação das políticas de rede do Kubernetes (de acordo com testes reais, não de acordo com a documentação).
Apenas dois CNIs criptografam dados: Cilium e WeaveNet. A criptografia WeaveNet é ativada definindo a senha de criptografia como uma variável de ambiente CNI. A documentação do WeaveNet descrita é complicada, mas tudo é feito de maneira simples. A criptografia do Cilium é configurada por comandos, criando segredos do Kubernetes e modificando o daemonSet (um pouco mais complicado que no WeaveNet, mas o Cilium tem instruções passo a passo).
Quanto à implementação da política de rede, Calico, Canal, Cilium e WeaveNet foram bem-sucedidos aqui, nos quais você pode configurar as regras de entrada e saída. Para o roteador Kube, existem regras apenas para o Ingress, enquanto a Flannel não possui políticas de rede.
Aqui estão os resultados gerais:
Resultados de referência para recursos de segurança
Desempenho
Essa referência mostra a taxa de transferência média de pelo menos três execuções de cada teste. Testamos o desempenho de TCP e UDP (usando iperf3), aplicativos reais, por exemplo, HTTP (com Nginx e curl) ou FTP (com vsftpd e curl) e, finalmente, a operação de aplicativos usando criptografia baseada no protocolo SCP (usando cliente e servidor OpenSSH).
Para todos os testes, fizemos um benchmark bare-metal (linha verde) para comparar o desempenho da CNI com o desempenho da rede nativa. Aqui usamos a mesma escala, mas a cor:
- Amarelo = muito bom
- Laranja = bom
- Azul = mais ou menos
- Vermelho = ruim
Não tomaremos CNIs configurados incorretamente e mostraremos apenas os resultados para CNIs com a MTU correta. (Nota: o Cilium não considera o MTU corretamente se a criptografia estiver ativada, portanto, você deverá reduzir o MTU manualmente para 8900 na versão 1.4. Na próxima versão, 1.5, isso é feito automaticamente.)
Aqui estão os resultados:
Desempenho TCP
Todos os CNIs tiveram bom desempenho no benchmark TCP. Os CNIs criptografados estão muito atrasados porque a criptografia é cara.
Desempenho UDP
Aqui também toda a CNI está indo bem. CNIs criptografados mostraram quase o mesmo resultado. O Cilium está um pouco atrás dos concorrentes, mas é apenas 2,3% do bare metal, portanto o resultado não é ruim. Não se esqueça de que apenas o próprio Cilium e Flannel determinaram corretamente o MTU, e esses são seus resultados sem configuração adicional.
Que tal uma aplicação real? Como você pode ver, no HTTP, o desempenho geral é um pouco menor do que no TCP. Mesmo se você usar HTTP com TCP, no benchmark TCP, configuramos o iperf3 para evitar um início lento, e isso afetará o benchmark HTTP. Tudo foi bem feito aqui. O roteador Kube tem uma clara vantagem, e o WeaveNet não se mostrou do melhor lado: cerca de 20% pior que o bare-metal. Cilium e WeaveNet com criptografia parecem muito tristes.
Com o FTP, outro protocolo baseado em TCP, os resultados são diferentes. A flanela e o roteador Kube lidam, enquanto o Calico, o Canal e o Cilium estão um pouco atrasados e trabalham cerca de 10% mais lentos que o metal puro. O WeaveNet não acompanha até 17%, mas o WeaveNet com criptografia está 40% à frente do Cilium criptografado.
Com o SCP, você pode ver imediatamente o que a criptografia SSH nos custa. Quase todas as CNIs fazem isso, e o WeaveNet está atrasado novamente. Espera-se que o Cilium e o WeaveNet com criptografia sejam os piores de todos, devido à criptografia dupla (SSH + CNI).
Aqui está uma tabela de resumo com os resultados:
Consumo de recursos
Agora vamos comparar como a CNI consome recursos sob cargas pesadas (durante a transmissão por TCP, 10 Gb / s). Nos testes de desempenho, comparamos a CNI com o bare metal (linha verde). Para consumir recursos, mostraremos Kubernetes puros (linha roxa) sem CNI e veremos quantos recursos extras a CNI consome.
Vamos começar com a memória. Aqui está o valor médio da memória do host (sem buffers e cache) em MB durante a transferência.
Consumo de memória
Flanela e roteador Kube mostraram excelentes resultados - apenas 50 MB. Calico e Canal têm 70. Cada um deles consome mais do que o resto - 130 MB, enquanto o Cilium usa até 400.
Agora vamos verificar o uso da CPU. Digno de nota : no diagrama, não porcentagens, mas por mil, ou seja, 38 ppm para “ferro nu” - isto é 3,8%. Aqui estão os resultados:
Consumo de CPU
Calico, Canal, Flannel e roteador Kube usam a CPU com muita eficiência - apenas 2% a mais que o Kubernetes sem CNI. O WeaveNet está muito atrás, com 5% a mais, seguido por Cilium - 7%.
Aqui está um resumo do consumo de recursos:
Sumário
Tabela com todos os resultados:
Resultados gerais de referência
Conclusão
Na última parte, expressarei minha opinião subjetiva sobre os resultados. Lembre-se de que esta referência apenas testa a taxa de transferência de uma conexão em um cluster muito pequeno (3 nós). Não se aplica a clusters grandes (<50 nós) ou conexões paralelas.
Eu recomendo usar os seguintes CNIs, dependendo do cenário:
- Você possui nós com uma pequena quantidade de recursos em seu cluster (vários GB de RAM, vários núcleos) e não precisa de recursos de segurança - escolha Flanela . Este é um dos CNIs mais econômicos. E é compatível com uma grande variedade de arquiteturas (amd64, arm, arm64, etc.). Além disso, esse é um dos dois (o segundo é Cilium) CNI, que pode determinar automaticamente o MTU, para que você não precise configurar nada. O roteador Kube também é adequado, mas não é tão padrão e você precisará configurar manualmente o MTU.
- Se você precisar criptografar a rede por segurança, use o WeaveNet . Não se esqueça de especificar o tamanho da MTU, se estiver usando jumbo-frames, e ativar a criptografia especificando uma senha por meio de uma variável de ambiente. Mas é melhor esquecer o desempenho - essa é a taxa de criptografia.
- Para uso normal, eu recomendo o Calico . Essa CNI é amplamente usada em várias ferramentas de implantação do Kubernetes (Kops, Kubespray, Rancher, etc.). Como no WeaveNet, lembre-se de configurar o MTU no ConfigMap se você usar frames grandes. É uma ferramenta multifuncional, eficaz em termos de consumo de recursos, produtividade e segurança.
E, finalmente, eu aconselho você a acompanhar o desenvolvimento do Cilium . Essa CNI possui uma equipe muito ativa que trabalha muito em seu produto (funções, economia de recursos, produtividade, segurança, distribuição de cluster ...) e possui planos muito interessantes.
Diagrama visual da CNI Choice