Esta é minha atualização , que agora é executado no Kubernetes 1.14 com a versão CNI mais recente em abril de 2019.
Primeiramente quero agradecer à equipe Cilium: a galera me ajudou 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 você estiver interessado):
Flanela continua sendo a interface CNI mais rápida e simples, mas ainda não oferece suporte a políticas de rede e criptografia.
Romana não é mais suportada, então nós a removemos do benchmark.
WeaveNet agora oferece suporte a políticas de rede para entrada e saída! Mas a produtividade diminuiu.
No Calico, você ainda precisa configurar manualmente o tamanho máximo do pacote (MTU) para obter melhor desempenho. Calico oferece duas opções para instalar o CNI, então você pode fazer isso sem um repositório ETCD separado:
- armazenar o estado na API Kubernetes como um armazenamento de dados (tamanho do cluster <50 nós);
- armazenar o estado na API Kubernetes como um armazenamento de dados com um proxy Typha para aliviar a carga na API K8S (tamanho do cluster> 50 nós).
Calico anunciou apoio além do Istio para segurança em nível de aplicativo.
Cilium agora suporta criptografia! Cilium fornece criptografia com túneis IPSec e oferece uma alternativa à rede WeaveNet criptografada. Mas o WeaveNet é mais rápido que o Cilium com criptografia habilitada.
Cilium agora é mais fácil de implantar graças ao operador ETCD integrado.
A equipe Cilium tentou reduzir o peso de seu CNI reduzindo o consumo de memória e os custos de CPU, mas seus 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 por meio de cabos DAC SFP+ passivos e são configurados na mesma VLAN com jumbo frames (MTU 9000).
Kubernetes 1.14.0 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 servidor do benchmark no segundo servidor e a parte cliente no terceiro. Para fazer isso, usamos NodeSelector em implantações do Kubernetes.
Descreveremos os resultados do benchmark na seguinte escala:
Selecionando um CNI para um benchmark
Este é um benchmark apenas para CNI da lista da seção Consulte a documentação oficial do Kubernetes. Dos 9 CNIs, pegaremos apenas 6: excluiremos aqueles que são difíceis de instalar e/ou não funcionam sem configuração conforme documentação (Romana, Contiv-VPP e JuniperContrail/TungstenFabric).
Compararemos os seguintes CNIs:
- Calico v3.6
- Canal v3.6 (essencialmente Flanela para rede + Calico como firewall)
- Cílio 1.4.2
- Flanela 0.11.0
- Roteador Kube 0.2.5
- WeaveNet 2.5.1
Instalação
Quanto mais fácil for a instalação do CNI, melhor será a nossa primeira impressão. Todos os CNIs do benchmark são muito fáceis de instalar (com um ou dois comandos).
Como dissemos, os servidores e o switch são configurados com jumbo frames habilitados (definimos o MTU para 9000). Ficaríamos felizes se a CNI determinasse automaticamente o MTU com base na configuração dos adaptadores. No entanto, apenas Cilium e Flannel conseguiram isso. O restante dos CNIs tem solicitações no GitHub para adicionar descoberta automática de MTU, mas iremos configurá-lo manualmente alterando o ConfigMap para roteador Calico, Canal e Kube ou passando uma variável de ambiente para WeaveNet.
Qual é o problema com MTU incorreto? Este diagrama mostra a diferença entre WeaveNet com MTU padrão e jumbo frames habilitados:
Como o MTU afeta o rendimento?
Vimos o quão importante é o MTU para o desempenho, agora vamos ver como nossos CNIs o determinam automaticamente:
CNI detecta automaticamente MTU
O gráfico mostra que você precisa configurar o MTU para Calico, Canal, roteador Kube e WeaveNet para obter desempenho ideal. Cilium e Flannel foram capazes de determinar corretamente o MTU sem quaisquer configurações.
segurança
Compararemos a segurança CNI em dois aspectos: a capacidade de criptografar os dados transmitidos e a implementação de políticas de rede Kubernetes (baseadas em testes reais, não em documentação).
Apenas dois CNIs criptografam dados: Cilium e WeaveNet. Criptografia WeaveNet habilitado definindo a senha de criptografia como uma variável de ambiente CNI. EM WeaveNet descreve isso de uma forma complicada, mas tudo é feito de forma simples. Criptografia Cílio configurado por comandos, criando segredos do Kubernetes e através da modificação do daemonSet (um pouco mais complicado que no WeaveNet, mas o Cilium tem passo a passo ).
Quanto à implementação da política de rede, conseguiram Calico, Canal, Cílio e WeaveNet, no qual você pode configurar regras de entrada e saída. Para Roteador Kube existem regras apenas para o Ingress e Flanela Não existem políticas de rede.
Aqui estão os resultados gerais:
Resultados de referência de desempenho de segurança
Desempenho
Este benchmark mostra o rendimento médio em pelo menos três execuções de cada teste. Testamos o desempenho de TCP e UDP (usando iperf3), aplicações reais como HTTP (com Nginx e curl) ou FTP (com vsftpd e curl) e finalmente o desempenho de aplicações usando criptografia baseada em SCP (usando cliente e servidor OpenSSH).
Para todos os testes, realizamos um benchmark bare metal (linha verde) para comparar o desempenho do CNI com o desempenho da rede nativa. Aqui usamos a mesma escala, mas em cores:
- Amarelo = muito bom
- Laranja = bom
- Azul = mais ou menos
- Vermelho = ruim
Não pegaremos CNIs configurados incorretamente e mostraremos apenas resultados para CNIs com o MTU correto. (Observação: o Cilium não calcula corretamente o MTU se você ativar a criptografia, então você terá que reduzir manualmente o MTU para 8900 na versão 1.4. A próxima versão, 1.5, faz isso automaticamente.)
Aqui estão os resultados:
Desempenho TCP
Todos os CNIs tiveram um bom desempenho no benchmark TCP. A CNI com criptografia está muito atrasada porque a criptografia é cara.
Desempenho UDP
Também aqui todos os CNIs estão bem. CNI com criptografia mostrou quase o mesmo resultado. Cilium está um pouco atrás da concorrência, mas é apenas 2,3% de bare metal, então não é um resultado ruim. Não se esqueça que apenas o Cilium e o Flannel determinaram o MTU corretamente, e estes são os resultados sem qualquer configuração adicional.
Que tal uma aplicação real? Como você pode ver, o desempenho geral do HTTP é ligeiramente inferior ao do TCP. Mesmo se você usar HTTP com TCP, configuramos o iperf3 no benchmark TCP para evitar uma inicialização lenta que afetaria o benchmark HTTP. Todos fizeram um bom trabalho aqui. O roteador Kube tem uma clara vantagem, mas o WeaveNet não teve um bom desempenho: 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 variam. Flannel e Kube-router fazem o trabalho, mas Calico, Canal e Cilium estão um pouco atrás e são cerca de 10% mais lentos que o bare metal. A WeaveNet está 17% atrás, mas a WeaveNet criptografada está 40% à frente da Cilium criptografada.
Com o SCP podemos ver imediatamente quanto nos custa a criptografia SSH. Quase todos os CNIs estão indo bem, mas a WeaveNet está novamente ficando para trás. Cilium e WeaveNet com criptografia são provavelmente os piores devido à criptografia dupla (SSH + CNI).
Aqui está uma tabela resumo com os resultados:
Consumo de recursos
Agora vamos comparar como o CNI consome recursos sob cargas pesadas (durante a transferência TCP, 10 Gbps). Nos testes de desempenho comparamos CNI com bare metal (linha verde). Para consumo de recursos, vamos mostrar o Kubernetes puro (linha roxa) sem CNI e ver quantos recursos extras o CNI consome.
Vamos começar com a memória. Aqui está o valor médio da RAM dos nós (excluindo buffers e cache) em MB durante a transferência.
Consumo de memória
O roteador Flanela e Kube apresentaram excelentes resultados - apenas 50 MB. Calico e Canal têm 70 cada. WeaveNet claramente consome mais que os outros - 130 MB, e Cilium usa até 400.
Agora vamos verificar o consumo de tempo da CPU. Digno de nota: o diagrama não mostra porcentagens, mas ppm, ou seja, 38 ppm para “ferro puro” é 3,8%. Aqui estão os resultados:
Consumo de CPU
Calico, Canal, Flannel e Kube-router são muito eficientes em termos de CPU - apenas 2% a mais que Kubernetes sem CNI. WeaveNet fica muito atrás com 5% extras, seguido por Cilium com 7%.
Aqui está um resumo do consumo de recursos:
Resultados de
Tabela com todos os resultados:
Resultados gerais de benchmark
Conclusão
Na última parte expressarei minha opinião subjetiva sobre os resultados. Lembre-se de que este benchmark testa apenas o rendimento de uma única conexão em um cluster muito pequeno (3 nós). Não se aplica a clusters grandes (<50 nós) ou conexões paralelas.
Recomendo usar os seguintes CNIs dependendo do cenário:
- Você tem em seu cluster nós com poucos recursos (vários GB de RAM, vários núcleos) e você não precisa de recursos de segurança - escolha Flanela. Este é um dos CNIs com melhor custo-benefício. E é compatível com uma ampla variedade de arquiteturas (amd64, arm, arm64, etc.). Além disso, este é um dos dois (o outro é 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 é padrão e você precisará configurar manualmente o MTU.
- Se necessário criptografar a rede por segurança, leve WeaveNet. Não se esqueça de especificar o tamanho da MTU se estiver usando jumbo frames e habilite a criptografia especificando uma senha por meio de uma variável de ambiente. Mas é melhor esquecer o desempenho – esse é o custo da criptografia.
- Para uso normal Eu aconselho Chita. Este CNI é amplamente utilizado em várias ferramentas de implantação do Kubernetes (Kops, Kubespray, Rancher, etc.). Tal como acontece com o WeaveNet, certifique-se de configurar o MTU no ConfigMap se estiver usando jumbo frames. É uma ferramenta multifuncional eficiente em termos de consumo de recursos, desempenho e segurança.
E por fim, aconselho você a acompanhar o desenvolvimento Cílio. Esta CNI tem uma equipe muito ativa que trabalha muito no seu produto (funcionalidades, economia de recursos, desempenho, segurança, clustering...) e tem planos muito interessantes.
Diagrama visual para seleção de CNI
Fonte: habr.com