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

O Kubernetes usa plug-ins CNI (Container Networking Interface) para gerenciar a rede em clusters Kubernetes. As 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 plugins CNI que você pode usar em seus clusters, dependendo dos seus requisitos de rede.

Modelos de rede no AKS

Escolher um plug-in CNI para o seu cluster AKS depende em grande parte de qual modelo de rede se adapta melhor às suas necessidades. Cada modelo tem suas próprias vantagens e desvantagens que você deve considerar ao planejar seu cluster AKS.

O AKS usa dois modelos de rede principais: rede de sobreposição e rede plana.

Ambos os modelos de rede têm várias opções de plug-in CNI suportadas. 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. Em redes de sobreposição, os pods recebem um endereço IP de um CIDR privado e logicamente separado da sub-rede VNet do Azure onde os nós AKS são implantados. Isso permite uma escalabilidade mais simples e muitas vezes melhor do que o modelo de rede plana.

Em redes de sobreposição, os pods podem se comunicar entre si diretamente. O tráfego que sai do cluster é SNAT'd (Source Network Address Converted) para o endereço IP do nó e o tráfego IP do Pod de entrada é roteado através 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 rede virtual necessários para seus clusters.

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

• Azure CNI Overlay, o plug-in CNI recomendado para a maioria dos cenários.
• kubenet, o modelo de sobreposição legado CNI.

Redes planas

Ao contrário de uma rede de sobreposição, um modelo de rede simples no AKS atribui endereços IP a pods de uma sub-rede da mesma VNet do Azure que os nós AKS. Isso significa que o tráfego que sai de seus clusters não é SNAT'd e o endereço IP do pod está diretamente exposto ao destino. Isso pode ser útil para alguns cenários, como quando você precisa expor endereços IP pod a serviços externos.

O Serviço Kubernetes do Azure fornece dois plug-ins CNI para rede simples. Este artigo não se aprofunda para cada opção de plugin. Para obter mais informações, consulte a documentação vinculada:

• Azure CNI Pod Subnet, o plug-in CNI recomendado para cenários de rede simples.
• Azure CNI Node Subnet, um modelo de rede plana herdado A CNI geralmente só recomenda que você use se precisar de uma VNet gerenciada para seu cluster.

Escolher uma CNI

Ao escolher uma CNI, há vários fatores a considerar. Cada modelo de rede tem suas próprias vantagens e desvantagens, e a melhor escolha para seu cluster dependerá de seus requisitos específicos.

Escolher um modelo de rede

Os dois principais modelos de rede no AKS são redes de sobreposição e planas.

• Redes de sobreposição:

  • Conserve o espaço de endereço IP da VNet usando intervalos CIDR logicamente separados para pods.
  • Suporte máximo à escala de cluster.
  • Gerenciamento de endereço IP simples.

• Redes planas:

  • Os pods obtêm conectividade VNet completa e podem ser acessados diretamente através de seu endereço IP privado a partir de redes conectadas.
  • Requer espaço de endereço IP VNet grande e não fragmentado.

Comparação de casos de uso

Ao escolher um modelo de rede, considere os casos de uso para cada plugin CNI e o tipo de modelo de rede que ele usa:

Plugin CNI	Modelo de rede	Destaques do caso de uso
Sobreposição do Azure CNI	Sobreposição	- Melhor para conservação de VNET IP - Contagem máxima de nós suportada pelo API Server + 250 pods por nó - Configuração mais simples -Sem acesso IP pod externo direto
Azure CNI Pod Subnet	Apartamento	- Acesso direto ao pod externo - Modos para uso eficiente de VNet IP ou suporte em grande escala de cluster (Preview)
Kubenet (Legado)	Sobreposição	- Prioriza a conservação da PI - Escala limitada - Gestão manual de rotas
Sub-rede do nó CNI do Azure (legado)	Apartamento	- Acesso direto ao pod externo - Configuração mais simples - Escala limitada - Uso ineficiente de IPs VNet

Comparação de funcionalidades

Você também pode querer comparar os recursos de cada plugin CNI. A tabela a seguir fornece uma comparação de alto nível dos recursos suportados por cada plug-in CNI:

Caraterística	Sobreposição do Azure CNI	Azure CNI Pod Subnet	Sub-rede do nó CNI do Azure (legado)	Kubenet
Implantar cluster em VNet nova ou existente	Suportado	Suportado	Suportado	Suportado - UDRs manuais
Conectividade Pod-VM com VM na mesma VNet ou emparelhada	Pod iniciado	Nos dois sentidos	Nos dois sentidos	Pod iniciado
Acesso local via VPN/Express Route	Pod iniciado	Nos dois sentidos	Nos dois sentidos	Pod iniciado
Acesso a pontos de extremidade de serviço	Suportado	Suportado	Suportado	Suportado
Expor serviços usando o balanceador de carga	Suportado	Suportado	Suportado	Suportado
Expor serviços usando o App Gateway	Atualmente não suportado	Suportado	Suportado	Suportado
Expor serviços usando o controlador de entrada	Suportado	Suportado	Suportado	Suportado
Pools de nós do Windows	Suportado	Suportado	Suportado	Não suportado
DNS padrão do Azure e zonas privadas	Suportado	Suportado	Suportado	Suportado
Compartilhamento de sub-rede VNet em vários clusters	Suportado	Suportado	Suportado	Não suportado

Escopo de suporte entre modelos de rede

Dependendo da CNI usada, os recursos da 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 CNI do Azure, na sub-rede do Nó CNI do Azure e no Kubenet.
• Você pode criar e configurar manualmente os recursos de rede virtual e anexá-los a esses recursos ao criar seu cluster AKS.

Embora recursos como pontos de extremidade de serviço ou UDRs sejam suportados, as políticas de suporte para o 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 UDRs ou pontos de extremidade de serviço.
• Se a plataforma Azure criar automaticamente os recursos de rede virtual para seu cluster AKS, você não poderá alterar manualmente esses recursos gerenciados pelo AKS para configurar seus próprios UDRs ou pontos de extremidade de serviço.

Pré-requisitos

Há vários requisitos e considerações a ter em mente ao planejar sua configuração de rede para o AKS:

• A rede virtual para o cluster AKS deve permitir conectividade de saída com a Internet.
• Os clusters AKS não podem usar 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16ou 192.0.2.0/24 para o intervalo de endereços de serviço do Kubernetes, intervalo de endereços de pod ou intervalo de endereços de rede virtual de cluster.
• Em cenários de VNet BYO, a identidade do cluster usada pelo cluster AKS deve ter pelo menos permissões de Colaborador de Rede na sub-rede dentro da sua rede virtual. Se você deseja definir uma função personalizada em vez de usar a função interna de Colaborador de Rede, as seguintes permissões são necessárias:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.Network/virtualNetworks/subnets/read (necessário apenas se você estiver definindo suas próprias sub-redes e CIDRs)
• A sub-rede atribuída ao pool de nós AKS não pode ser uma sub-rede delegada.
• O AKS não aplica Grupos de Segurança de Rede (NSGs) à sua sub-rede e não modifica nenhum dos NSGs associados a essa sub-rede. Se você fornecer sua própria sub-rede e adicionar NSGs associados a essa sub-rede, deverá garantir que as regras de segurança nos NSGs permitam o tráfego dentro do intervalo CIDR do nó. Para obter mais informações, consulte Grupos de segurança de rede.

Passos Seguintes

• Sobreposição do Azure CNI
• Azure CNI Pod Subnet
• Opções antigas da CNI
• Planejamento de endereço IP para seus clusters