Compartilhar via

Visão geral da rede CNI do AKS (Serviço de Kubernetes do Azure)

  • Artigo

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.

Um diagrama mostrando dois nós com três pods, cada um executando em uma rede de sobreposição. O tráfego de pod para pontos de extremidade fora do cluster é roteado via NAT.

O Serviço de Kubernetes do Azure fornece os seguintes plug-ins de CNI para a rede de sobreposição:

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.

Um diagrama mostrando dois nós com três pods em execução em um modelo de rede simples.

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:

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 (versão prévia) Plano – Acesso direto externo
– Modos para o uso eficiente de IP da VNet ou suporte à grande escala de cluster
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/16 ou 192.0.2.0/24 para 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.
  • Os cenários CNI BYO, a identidade do cluster usada pelo cluster do AKS precisa ter, pelo menos, permissões de Colaborador de Rede na sub-rede da 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/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Microsoft.Authorization/roleAssignments/write
  • 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