Critérios de decisão
Escolher o melhor plugin de rede para o seu caso de uso depende dos seus critérios. Cada opção tem seus próprios prós, contras e compensações a serem considerados ao fazer uma seleção.
Critérios de decisão de alto nível
Exaustão do IPv4
Kubenet é projetado com a conservação do espaço de endereço IP em mente. O Azure CNI fornece pods com conectividade de rede completa, mas requer mais espaço de endereço IP e planejamento. O esgotamento do IPv4 ocorre quando o número de endereços atinge o limite e interrompe os nós de uma operação de escala ou atualização. Durante a exaustão, seu aplicativo exige muitos recursos e vacila para acompanhar.
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 potenciais que poderiam ser executados no cluster. Com o kubenet, você se preocupa menos com a exaustão do IPv4 e lida com um pequeno intervalo de endereços IP para suporte a clusters grandes e demandas de aplicativos.
Os seguintes cálculos básicos comparam o espaço de endereçamento nos modelos de rede:
- kubenet: um simples intervalo de endereços IP /24 pode suportar até 251 nós no cluster (cada sub-rede de rede virtual do Azure reserva os três primeiros endereços IP para operações de gerenciamento). Essa contagem de nós pode suportar até 27.610 pods (com um máximo padrão de 110 pods por nó com kubenet).
- Azure CNI: esse mesmo intervalo de sub-rede /24 básico só poderia suportar um máximo de 8 nós no cluster. Essa contagem de nós só pode oferecer suporte a até 240 pods (com um máximo padrão de 30 pods por nó com o Azure CNI).
Tamanho do cluster
O Kubenet tem um máximo rígido de 400 nós por cluster, enquanto o Azure CNI depende de como o plug-in está configurado.
Conectividade
No Kubenet, você deve gerenciar manualmente e manter rotas definidas pelo usuário (UDRs). Para alcançar pods de fora do cluster, um balanceador de carga deve ser usado. Com o Azure CNI, os pods obtêm conectividade de rede virtual completa e podem ser acessados diretamente por meio de seu endereço IP privado a partir de redes conectadas.
Suporte a vários clusters
No kubenet, vários clusters não podem usar a mesma sub-rede de nó. Com o Azure CNI, essa configuração é possível.
Latência
Em comparação com o Azure CNI, o Kubenet precisa de um salto extra, que pode introduzir alguma latência menor. Cargas de trabalho sensíveis à latência devem ser implantadas em clusters usando o Azure CNI.
Capacidades extras
O Azure CNI dá suporte a topologias de rede complexas com a rede CNI do Azure, como nós virtuais ou políticas de rede do Azure.
Esses recursos extras são:
- Sub-rede por pool de nós
- Alocação dinâmica de PI
- Alocações de sub-rede de nó vs pod
Diferenças comportamentais entre Kubenet e Azure CNI
Além dos critérios de alto nível, há muitas diferenças comportamentais e discrepâncias no suporte a recursos:
| Funcionalidade | Kubenet | Azure CNI | Sobreposição do Azure CNI | Azure CNI com Tecnologia Cilium |
|---|---|---|---|---|
| Implantar cluster em rede virtual nova ou existente | Suportado - UDRs aplicados manualmente | Suportado | Suportado | Suportado |
| Conectividade Pod-pod | Suportado | Suportado | Suportado | Suportado |
| Conectividade Pod-VM; VM na mesma rede virtual | Funciona quando iniciado por pod | Funciona nos dois sentidos | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Conectividade Pod-VM; VM em rede virtual emparelhada | Funciona quando iniciado por pod | Funciona nos dois sentidos | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Acesso local usando VPN ou Rota Expressa | Funciona quando iniciado por pod | Funciona nos dois sentidos | Funciona quando iniciado por pod | Funciona quando iniciado por pod |
| Acesso a recursos protegidos por pontos de extremidade de serviço | Suportado | Suportado | Suportado | |
| Acesso a recursos expostos por pontos de extremidade privados | Suportado | Suportado | ||
| Expor serviços do Kubernetes usando um serviço de balanceador de carga, App Gateway ou controlador de entrada | Suportado | Suportado | Suportado | Mesmas limitações ao usar o modo de sobreposição |
| DNS padrão do Azure e zonas privadas | Suportado | Suportado | Suportado | |
| Suporte para pools de nós do Windows | Não suportado | Suportado | Suportado | Disponível apenas para Linux |
| Nós virtuais | Não suportado | Suportado | Não suportado | |
| Vários clusters compartilhando uma sub-rede | Não suportado | Suportado | Suportado | |
| Políticas de rede suportadas | Calico | Políticas de rede do Calico e do Azure | Calico, Azure Network Policies, Cilium | Ciliuim |