Critérios de decisão
A escolha do melhor plugin de rede para o seu caso de uso depende de seus critérios. Cada opção tem seus prós e contras e você deve avaliar se estará abrindo mão de algo quando fizer uma seleção.
Critérios de decisão de alto nível
Esgotamento de IPv4
O kubenet foi projetado pensando no espaço de endereços IP. A CNI do Azure fornece pods com conectividade de rede completa, mas requer mais espaço de endereços IP e mais planejamento. O esgotamento do IPv4 ocorre quando o número de endereços atinge o limite e impede os nós de realizarem uma operação de ampliação ou upgrade. Durante o esgotamento, seu aplicativo demanda um excesso de recursos e não consegue se manter ativo.
O kubenet permite que os nós recebam endereços IP definidos, sem a necessidade de reservar um grande número de endereços IP antecipadamente para todos os pods que podem ser executados no cluster. Com o kubenet, você se preocupa menos com o esgotamento do IPv4 e lida com um pequeno intervalo de endereços IP para dar suporte aos clusters grandes e às demandas dos aplicativos.
Os seguintes cálculos básicos comparam o espaço de endereços nos modelos de rede:
- kubenet: um simples intervalo de endereços IP /24 pode dar suporte a até 251 nós no cluster (cada sub-rede da Rede Virtual do Azure reserva os três primeiros endereços IP para operações de gerenciamento). Esta contagem de nós pode dar suporte a até 27.610 pods (com um máximo padrão de 110 pods por nó com o kubenet).
- CNI do Azure: esse mesmo intervalo básico de sub-rede /24 só podia dar suporte ao máximo de 8 nós no cluster. Esta contagem de nós só podia dar suporte a até 240 pods (com um máximo padrão de 30 pods por nó com a CNI do Azure).
Tamanho do cluster
O Kubenet tem um máximo rígido de 400 nós por cluster, enquanto na CNI do Azure isso depende de como o plugin é configurado.
Conectividade
No kubenet, você deve gerenciar e manter manualmente as UDRs (rotas definidas pelo usuário). Para alcançar os pods de fora do cluster, deve-se empregar um balanceador de carga. Com a CNI do Azure, os pods obtêm conectividade total da rede virtual e podem ser diretamente acessados das redes conectadas por meio do endereço IP privado deles.
Suporte a vários clusters
No kubenet, a mesma sub-rede de nós não pode ser usada por vários clusters. Com a CNI do Azure, essa configuração é possível.
Latency
Em comparação com a CNI do Azure, o kubenet precisa de um salto extra, o que pode introduzir uma latência secundária. Cargas de trabalho sensíveis à latência devem ser implantadas em clusters que usam a CNI do Azure.
Recursos adicionais
Com a rede da CNI do Azure, a CNI do Azure dá suporte a topologias de rede complexas como Nós Virtuais ou Políticas de Rede do Azure.
Esses recursos adicionais são os seguintes:
- Sub-rede de acordo com o pool de nós
- Alocação dinâmica de IPs
- Alocações de sub-redes de pod x nós
Diferenças comportamentais entre o Kubenet e a CNI do Azure
Além dos critérios de alto nível, há muitas diferenças comportamentais e discrepâncias no suporte a recursos:
| Funcionalidade | Kubenet | CNI do Azure | Sobreposição de CNI do Azure | CNI do Azure da plataforma Cilium |
|---|---|---|---|---|
| Implantar cluster em uma rede virtual nova ou existente | Com suporte - UDRs aplicadas manualmente | Com suporte | Compatível | Com suporte |
| Conectividade pod-pod | Com suporte | Compatível | Compatível | Com suporte |
| Conectividade pod-VM; VM na mesma rede virtual | Funciona quando iniciado pelo pod | Funciona das duas maneiras | Funciona quando iniciado pelo pod | Funciona quando iniciado pelo pod |
| Conectividade pod-VM; VM em rede virtual associada | Funciona quando iniciado pelo pod | Funciona das duas maneiras | Funciona quando iniciado pelo pod | Funciona quando iniciado pelo pod |
| Acesso local usando VPN ou Express Route | Funciona quando iniciado pelo pod | Funciona das duas maneiras | Funciona quando iniciado pelo pod | Funciona quando iniciado pelo pod |
| Acesso a recursos protegidos por pontos de extremidade do serviço | Com suporte | Compatível | Com suporte | |
| Acesso a recursos expostos por meio de pontos de extremidade privados | Com suporte | Com suporte | ||
| Expor serviços Kubernetes usando um serviço de balanceador de carga, um gateway de aplicativo ou um controlador de entrada | Com suporte | Compatível | Com suporte | As mesmas limitações ao utilizar o modo Sobreposição |
| Zonas privadas e DNS do Azure padrão | Com suporte | Compatível | Com suporte | |
| Suporte para pools Windows nós | Sem suporte | Com suporte | Com suporte | Disponível apenas para Linux |
| Nós virtuais | Sem suporte | Com suporte | Sem suporte | |
| Vários clusters compartilhando a mesma sub-rede | Sem suporte | Com suporte | Com suporte | |
| Políticas de rede compatíveis | Calico | Políticas de Rede do Calico e do Azure | Calico, Políticas de Rede do Azure, Cilium | Ciliuim |