Visão geral da rede CNI do AKS (Serviço de Kubernetes do Azure)
O Kubernetes usa plug-ins da CNI (Interface de Rede de Contêiner) para gerenciar a rede em clusters do Kubernetes. Os CNIs são responsáveis por atribuir endereços IP a pods, roteamento de rede entre pods, roteamento do Serviço kubernetes e muito mais.
O AKS fornece vários plug-ins de CNI que você pode usar em seus clusters, dependendo dos requisitos de rede.
Modelos de rede no AKS
Escolher um plug-in CNI para o cluster do AKS depende, em grande parte, de qual modelo de rede atende melhor às suas necessidades. Cada modelo tem suas próprias vantagens e desvantagens que você deve considerar ao planejar seu cluster do AKS.
O AKS usa dois modelos de rede principais: rede de sobreposição e rede simples.
Ambos os modelos de rede têm várias opções de plug-in CNI com suporte. As principais diferenças entre os modelos são como os endereços IP do pod são atribuídos e como o tráfego sai do cluster.
Redes de sobreposição
A rede de sobreposição é o modelo de rede mais comum usado no Kubernetes. Nas redes de sobreposição, os pods recebem um endereço de IP de um CIDR privado e separado logicamente da sub-rede da VNet do Azure em que os nós do AKS estão implantados. Isso permite uma escalabilidade mais simples e geralmente melhor do que o modelo de rede simples.
Em redes de sobreposição, os pods podem se comunicar entre si diretamente. O tráfego que sai do cluster é SNAT (Endereço de Rede de Origem Traduzido) para o endereço IP do nó, e o tráfego IP do Pod de entrada é roteado por meio de algum serviço, como um balanceador de carga. Isso significa que o endereço IP do pod está “oculto” atrás do endereço IP do nó. Essa abordagem reduz o número de endereços IP de VNet necessários para seus clusters.
O Serviço de Kubernetes do Azure fornece os seguintes plug-ins de CNI para a rede de sobreposição:
- A sobreposição de CNI do Azure, o plug-in de CNI recomendado para a maioria dos cenários.
- kubenet, CNI do modelo de sobreposição herdado.
Redes simples
Diferentemente de uma rede de sobreposição, um modelo de rede simples no AKS atribui endereços de IP aos pods de uma sub-rede da mesma VNet do Azure que os nós do AKS. Isso significa que todo o tráfego que sai dos seus clusters não é SNAT, e o endereço de IP do pod é exposto diretamente ao destino. Isso pode ser útil para alguns cenários, como quando você precisa expor endereços IP de pod a serviços externos.
O Serviço de Kubernetes do Azure fornece dois plug-ins de CNI para rede simples. Este artigo não entra em detalhes para cada opção de plug-in. Para obter mais informações, consulte a documentação vinculada:
- Sub-rede do Pod CNI do Azure, o plug-in de CNI recomendado para cenários de rede simples.
- Sub-rede do nó da CNI do Azure, uma CNI de modelo de rede simples herdada geralmente só recomenda que você use se precisar de uma VNet gerenciada para seu cluster.
Como escolher uma CNI
Ao escolher uma CNI, há vários fatores a serem considerados. Cada modelo de rede tem suas próprias vantagens e desvantagens, e a melhor opção para seu cluster dependerá dos requisitos específicos.
Escolher um modelo de rede
Os dois principais modelos de rede no AKS são sobreposição e redes simples.
Redes de sobreposição:
- Conserve o espaço de endereço IP da VNet usando intervalos CIDR separados logicamente para pods.
- Suporte máximo à escala de cluster.
- Gerenciamento de endereço IP simples.
Redes simples:
- Os pods têm conectividade total da VNet e podem ser diretamente acessados por meio de seu endereço IP privado de redes conectadas.
- Exigir espaço de endereço IP de VNet grande e não fragmentado.
Usar comparação de maiúsculas e minúsculas
Ao escolher um modelo de rede, considere os casos de uso para cada plug-in de CNI e o tipo de modelo de rede que ele usa:
| Plug-in de CNI | Modelo de rede | Destaques de caso de uso |
|---|---|---|
| Sobreposição de CNI do Azure | Sobreposição | – Melhor para a conservação de IP da VNET – Contagem máxima de nós com suporte pelo Servidor de API + 250 pods por nó – Configuração mais simples – Sem acesso direto ao IP do pod externo |
| Sub-rede do pod da CNI do Azure | Plano | – Acesso direto externo – Modos para o uso eficiente de IP da VNet ou suporte à grande escala de cluster(Versão prévia) |
| Kubenet (herdado) | Sobreposição | – Prioriza a conservação de IP – Escala limitada – Gerenciamento manual de rotas |
| Sub-rede de Nó da CNI do Azure (Herdado) | Plano | – Acesso direto externo – Configuração mais simples – Escala limitada – Uso ineficiente de IPs de VNet |
Comparação de recursos
Talvez você também queira comparar os recursos de cada plug-in de CNI. A tabela a seguir fornece uma comparação de alto nível dos recursos compatíveis com cada plug-in CNI:
| Recurso | Sobreposição de CNI do Azure | Sub-rede do pod da CNI do Azure | Sub-rede de Nó da CNI do Azure (Herdado) | Kubenet |
|---|---|---|---|---|
| Implantar cluster em uma VNet nova ou existente | Com suporte | Compatível | Com suporte | Com suporte – UDRs manuais |
| Conectividade pod-VM com VM na mesma VNet ou emparelhada | Pod iniciado | Ambas as maneiras | Ambas as maneiras | Pod iniciado |
| Acesso local usando VPN/Express Route | Pod iniciado | Ambas as maneiras | Ambas as maneiras | Pod iniciado |
| Acesso aos pontos de extremidade de serviço | Com suporte | Compatível | Compatível | Com suporte |
| Expor serviços usando o balanceador de carga | Com suporte | Compatível | Compatível | Com suporte |
| Expor serviços usando o Gateway de Aplicativo | Não há suporte no momento | Com suporte | Compatível | Com suporte |
| Expor serviços usando o controlador de entrada | Com suporte | Compatível | Compatível | Com suporte |
| Pools de nós do Windows | Com suporte | Compatível | Compatível | Sem suporte |
| Zonas privadas e DNS do Azure padrão | Com suporte | Compatível | Compatível | Com suporte |
| Compartilhamento de sub-rede da VNet em vários clusters | Com suporte | Compatível | Compatível | Sem suporte |
Escopo de suporte entre modelos de rede
Dependendo da CNI usada, os recursos de rede virtual do cluster podem ser implantados de uma das seguintes maneiras:
- A plataforma Azure pode criar e configurar automaticamente os recursos de rede virtual quando você cria um cluster AKS. como na Sobreposição de CNI do Azure, na sub-rede do Nó CNI do Azure e no Kubenet.
- Você pode criar e configurar manualmente os recursos da rede virtual e anexá-los a esses recursos ao criar o cluster AKS.
Embora haja suporte para recursos como pontos de extremidade de serviço ou UDRs, as políticas de suporte para AKS definem quais alterações você pode fazer. Por exemplo:
- Se você criar manualmente os recursos de rede virtual para um cluster AKS, terá suporte ao configurar seus próprios pontos de extremidade de serviço ou UDRs.
- Se a plataforma Azure criar automaticamente os recursos de rede virtual para o cluster AKS, não será possível alterar manualmente esses recursos gerenciados por AKS para que configurem suas próprias UDRs ou pontos de extremidade de serviço.
Pré-requisitos
Há vários requisitos e considerações a serem considerados ao planejar sua configuração de rede para o AKS:
- A rede virtual do cluster do AKS deve permitir conectividade com a Internet de saída.
- Os clusters do AKS não podem usar
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16ou192.0.2.0/24para o intervalo de endereços do serviço do Kubernetes, o intervalo de endereços do pod ou o intervalo de endereços da rede virtual do cluster. - Em cenários de VNet BYO, a identidade do cluster usada pelo cluster do AKS deve ter pelo menos permissões de Colaborador de Rede na sub-rede em sua rede virtual. Se você quiser definir uma função personalizada em vez de usar a função de Colaborador de Rede interna, as seguintes permissões serão necessárias:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(necessário somente se você estiver definindo suas próprias sub-redes e CIDRs)
- A sub-rede atribuída ao pool de nós do AKS não pode ser uma sub-rede delegada.
- O AKS não aplica NSGs (grupos de segurança de rede) à sua sub-rede e não muda nenhum dos NSGs associados a essa sub-rede. Se você fornecer sua própria sub-rede e adicionar os NSGs associados a ela, verifique se as regras de segurança nos NSGs permitem o tráfego dentro do intervalo de CIDR do nó. Para saber mais, confira Grupos de segurança de rede.
Próximas etapas
Azure Kubernetes Service