TL; DR: Todos os CNIs funcionam como deveriam, com exceção do Kube-Router e Kube-OVN, o Calico, com exceção da detecção automática de MTU, é o melhor.
Atualização do artigo dos meus cheques anteriores ( и ), no momento do teste estou usando o Kubernetes 1.19 no Ubuntu 18.04 com CNIs atualizados em agosto de 2020.
Antes de mergulharmos nas métricas...
O que há de novo desde abril de 2019?
- Pode testar em seu próprio cluster: você pode executar testes em seu próprio cluster usando nossa ferramenta Referência da rede Kubernetes:
- Novos membros apareceram
- da VMware Tanzu
- de alauda.io
- Novos cenários: as verificações atuais executam testes de desempenho de rede "Pod-to-Pod" e foi adicionado um novo script "Pod-to-Service" que executa testes mais próximos das condições do mundo real. Na prática, seu Pod com API funciona com a base como serviço, e não através do endereço IP do Pod (é claro que verificamos TCP e UDP para ambos os cenários).
- Consumo de recursos: cada teste agora tem sua própria comparação de recursos
- Removendo testes de aplicativos: não fazemos mais testes HTTP, FTP e SCP, pois nossa colaboração frutífera com a comunidade e os mantenedores do CNI descobriu uma lacuna entre os resultados do iperf sobre TCP e os resultados do curl devido a um atraso na inicialização do CNI (os primeiros segundos do Pod inicialização, o que não é típico em condições reais).
- Código aberto: todas as fontes de teste (scripts, configurações yml e dados “brutos” originais) estão disponíveis
Protocolo de teste de referência
O protocolo é descrito em detalhes Observe que este artigo é sobre o Ubuntu 18.04 com o kernel padrão.
Selecionando um CNI para avaliação
Este teste visa comparar CNIs configurados com um arquivo yaml (portanto, são excluídos todos aqueles instalados por scripts, como VPP e outros).
Nossos CNIs selecionados para comparação:
- Antrea v.0.9.1
- Calico v3.16
- Canal v3.16 (rede de flanela + políticas de rede Calico)
- Cílio 1.8.2
- Flanela 0.12.0
- Roteador Kube mais recente (2020–08–25)
- WeaveNet 2.7.0
Configurando MTU para CNI
Primeiramente, verificamos o impacto da detecção automática de MTU no desempenho do TCP:
Impacto do MTU no desempenho do TCP
Uma lacuna ainda maior é encontrada ao usar UDP:
Impacto do MTU no desempenho do UDP
Dado o ENORME impacto no desempenho revelado nos testes, gostaríamos de enviar uma carta de esperança a todos os mantenedores do CNI: adicionem detecção automática de MTU ao CNI. Você vai salvar gatinhos, unicórnios e até o mais fofo: o pequeno Devop.
No entanto, se precisar usar CNI sem suporte para detecção automática de MTU, você poderá configurá-lo manualmente para obter desempenho. Observe que isso se aplica a Calico, Canal e WeaveNet.
Meu pequeno pedido aos CNIs acompanhantes...
Teste CNI: dados brutos
Nesta seção, compararemos o CNI com o MTU correto (determinado automaticamente ou definido manualmente). O principal objetivo aqui é mostrar os dados brutos em gráficos.
Legenda de cores:
- cinza - amostra (ou seja, ferro puro)
- verde - largura de banda acima de 9500 Mbps
- amarelo - largura de banda acima de 9000 Mbps
- laranja - largura de banda acima de 8000 Mbps
- vermelho - largura de banda abaixo de 8000 Mbps
- azul - neutro (não relacionado à largura de banda)
Consumo de recursos sem carga
Em primeiro lugar, verifique o consumo de recursos quando o cluster está “adormecido”.
Consumo de recursos sem carga
Pod para Pod
Este cenário pressupõe que o pod cliente se conecte diretamente ao pod servidor usando seu endereço IP.
Cenário pod a pod
TCP
Resultados TCP de pod para pod e consumo de recursos correspondente:
UDP
Resultados UDP pod-to-pod e consumo de recursos correspondente:
Pod para serviço
Esta seção é relevante para casos de uso reais, o pod cliente se conecta ao pod servidor por meio do serviço ClusterIP.
Script de pod para serviço
TCP
Resultados TCP de pod para serviço e consumo de recursos correspondente:
UDP
Resultados UDP pod-to-service e consumo de recursos correspondente:
Apoio à política de rede
Dentre todos os citados, o único que não apoia a política é o Flanela. Todos os outros implementam corretamente políticas de rede, incluindo entrada e saída. Bom trabalho!
Criptografia CNI
Entre os CNIs verificados estão aqueles que podem criptografar a troca de rede entre Pods:
- Antrea usando IPsec
- Calico usando wireguard
- Cílio usando IPsec
- WeaveNet usando IPsec
Largura de banda
Como restam menos CNIs, vamos colocar todos os cenários em um gráfico:
Consumo de recursos
Nesta seção, avaliaremos os recursos usados ao processar a comunicação Pod-to-Pod em TCP e UDP. Não faz sentido desenhar um gráfico Pod-to-Service, pois ele não fornece informações adicionais.
Juntando tudo
Vamos tentar repetir todos os gráficos, introduzimos aqui um pouco de subjetividade, substituindo os valores reais pelas palavras “vwry fast”, “low”, etc.
Conclusão e minhas conclusões
Isso é um pouco subjetivo, pois estou transmitindo minha própria interpretação dos resultados.
Fico feliz que novos CNIs tenham surgido, o Antrea teve um bom desempenho, muitas funções foram implementadas mesmo nas primeiras versões: detecção automática de MTU, criptografia e fácil instalação.
Se compararmos o desempenho, todos os CNIs funcionam bem, exceto Kube-OVN e Kube-Router. O Kube-Router também não conseguiu detectar o MTU, não encontrei uma maneira de configurá-lo em nenhum lugar da documentação ( uma solicitação sobre este tópico está aberta).
Em termos de consumo de recursos, o Cilium ainda usa mais RAM do que outros, mas o fabricante está claramente visando clusters grandes, o que claramente não é o mesmo que testar um cluster de três nós. Kube-OVN também consome muitos recursos de CPU e RAM, mas é um CNI jovem baseado em Open vSwitch (como o Antrea, tem melhor desempenho e consome menos).
Todos, exceto Flannel, têm políticas de rede. É muito provável que ele nunca os apoie, pois o objetivo é mais simples que um nabo cozido no vapor: quanto mais leve, melhor.
Além disso, entre outras coisas, o desempenho da criptografia é incrível. Calico é um dos CNIs mais antigos, mas a criptografia só foi adicionada há algumas semanas. Eles escolheram wireguard em vez de IPsec e, simplesmente, funciona muito bem e de forma incrível, eclipsando completamente outros CNIs nesta parte do teste. É claro que o consumo de recursos aumenta devido à criptografia, mas o rendimento alcançado vale a pena (o Calico mostrou uma melhoria seis vezes maior no teste de criptografia em comparação ao Cilium, que ocupa o segundo lugar). Além disso, você pode ativar o wireguard a qualquer momento após implantar o Calico no cluster e também pode desativá-lo por um curto período de tempo ou permanentemente, se desejar. No entanto, é incrivelmente conveniente! Lembramos que o Calico atualmente não detecta automaticamente MTU (esse recurso está planejado para versões futuras), portanto, certifique-se de configurar o MTU se sua rede suportar Jumbo Frames (MTU 9000).
Entre outras coisas, observe que o Cilium pode criptografar o tráfego entre nós de cluster (e não apenas entre Pods), o que pode ser muito importante para nós de cluster públicos.
Como conclusão, sugiro os seguintes casos de uso:
- Preciso de CNI para um cluster muito pequeno OU não preciso de segurança: trabalhar com Flanela, o CNI mais leve e estável (ele também é um dos mais antigos, segundo a lenda foi inventado pelo Homo Kubernautus ou Homo Contaitorus). Você também pode estar interessado no projeto mais engenhoso , verificar!
- Precisa de CNI para um cluster regular: Chita - sua escolha, mas não esqueça de configurar o MTU se necessário. Você pode brincar de maneira fácil e natural com as políticas de rede, ativar e desativar a criptografia, etc.
- Precisa de CNI para cluster de (muito) grande escala: Bom, o teste não mostra o comportamento de grandes clusters, ficaria feliz em realizar testes, mas não temos centenas de servidores com conexão de 10Gbps. Portanto a melhor opção é executar um teste modificado em seus nós, pelo menos com Calico e Cilium.
Fonte: habr.com