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. Os plugins CNI tratam da atribuição de endereços IP a pods, do encaminhamento do tráfego de rede entre pods, do encaminhamento do tráfego de serviço Kubernetes e muito mais.

O Azure Kubernetes Service (AKS) fornece múltiplas configurações de rede CNI que pode usar nos seus clusters, dependendo das suas necessidades de rede. Quando planeia rede pod, escolhe uma opção de gestão de endereços IP (IPAM) e uma tecnologia de encaminhamento e transporte para o plano de dados da rede.

Modelos de rede no AKS

Escolher uma opção IPAM para o seu cluster AKS depende muito do modelo de rede que melhor se adequa às suas necessidades. Cada modelo tem as suas próprias vantagens e desvantagens que deve considerar ao planear o seu cluster AKS.

O AKS utiliza dois modelos principais de rede:

• Rede sobreposta:

  • Poupa espaço de endereços IP para redes virtuais (VNets) utilizando intervalos CIDR (Classless Inter-Domain Routing) logicamente separados para pods.
  • Proporciona suporte máximo para a escala de cluster.
  • Proporciona uma gestão simples dos endereços IP.

• Rede plana:

  • Fornece conectividade completa à rede virtual para pods. Os pods podem ser contactados diretamente através do seu endereço IP privado a partir de redes ligadas.
  • Requer um espaço de endereços IP grande e não fragmentado para VNets.

Ambos os modelos de rede suportam múltiplas opções de IPAM. As principais diferenças entre os modelos são a forma como atribui endereços IP pod e como o tráfego sai do cluster.

Para o Azure CNI, a opção IPAM é separada do plano de dados da rede. Pode usar o plano de dados Azure CNI Powered by Cilium com Azure CNI Overlay, Azure CNI Pod Subnet ou Azure CNI Node Subnet. Para mais informações sobre IPAM e opções de plano de dados, consulte Rede de pods Plan para AKS.

Redes de sobreposição

A rede sobreposta no AKS atribui endereços IP pod a partir de um CIDR pod separado, distinto da sub-rede de nó no VNet. Esta configuração permite uma escalabilidade mais simples e frequentemente melhor do que o modelo de rede plana.

Em redes de sobreposição, os pods têm a capacidade de se comunicar diretamente uns com os outros. O tráfego que sai do cluster tem o Endereço de Rede de Origem traduzido (realizado SNAT) para o endereço IP do nó. O tráfego IP do pod de entrada é encaminhado através de um serviço, como um balanceador de carga. O endereço IP do pod é então "escondido" atrás do endereço IP do nó. Esta abordagem reduz o número de endereços IP necessários para redes virtuais nos seus clusters.

Para rede sobreposta, o AKS fornece o Azure CNI Overlay. Use esta opção IPAM para a maioria dos cenários.

Redes planas

Ao contrário de uma rede sobreposta, um modelo de rede plana no AKS atribui endereços IP a pods a partir de uma sub-rede na mesma rede virtual Azure que os nós AKS. Para o tráfego de rede privada, o endereço IP de origem que um destino vê depende da opção IPAM. A subrede Azure CNI Pod preserva o endereço IP do pod através de redes virtuais conectadas. Com a Subnet de Nó CNI do Azure, os destinos na rede virtual do cluster veem o endereço IP do pod, mas os destinos fora da rede virtual do cluster veem o endereço IP do nó. Quando a saída da internet está ativada, o método de saída configurado do cluster determina o endereço IP de origem pública que os destinos da internet veem.

O AKS fornece duas opções Azure CNI IPAM para redes planas:

• Azure CNI Pod Subnet, a opção IPAM recomendada para cenários de rede plana.
• Azure CNI Node Subnet, um modelo CNI legado para redes planas. Em geral, recomendamos que o utilize apenas se precisar de uma rede virtual gerida para o seu cluster.

Escolha uma opção IPAM para AKS

Ao escolher uma opção IPAM, considere vários fatores. Cada modelo de rede tem as suas próprias vantagens e desventajas. A melhor escolha para o teu cluster depende dos teus requisitos específicos.

Comparação de casos de uso

Comparação de funcionalidades

Escopo de suporte entre modelos de rede

Dependendo da opção IPAM que usar, pode implementar os recursos virtuais de rede do seu cluster de uma das seguintes formas:

• A plataforma Azure pode criar e configurar automaticamente os recursos de rede virtual quando cria um cluster AKS.
• 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 criar manualmente os recursos de rede virtual para um cluster AKS, terá suporte ao configurar os 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 para redes AKS CNI

Ao planear a configuração da sua rede para o AKS, tenha em mente estes requisitos e considerações:

• A menos que utilize um cluster isolado em rede, a rede virtual do cluster AKS deve permitir conectividade à internet de saída para os endpoints necessários. Clusters isolados de rede podem arrancar sem conectividade à internet de saída.

• Os intervalos de endereços do AKS têm as seguintes restrições:

  Intervalo CIDR reservado	Aplica-se a	Condition
  169.254.0.0/16	Intervalos de endereços virtuais de rede de serviço, pod e cluster Kubernetes	Todos os clusters AKS
  192.0.2.0/24	Intervalos de endereços virtuais de rede de serviço, pod e cluster Kubernetes	Todos os clusters AKS
  172.30.0.0/16	Intervalos de endereços virtuais de rede de serviço, pod e cluster Kubernetes	Todos os clusters AKS
  172.31.0.0/16	Intervalos de endereços virtuais de rede de serviço, pod e cluster Kubernetes	Todos os clusters AKS

  O AKS rejeita CIDRs pod que sobrepõem um intervalo reservado durante a criação ou atualização do cluster. Por exemplo, 172.16.0.0/12 não é válido porque o intervalo inclui 172.30.0.0/16 e 172.31.0.0/16.

• Em cenários em que trazes a tua própria rede virtual, a identidade do cluster que o cluster AKS usa deve ter pelo menos permissões de Network Contributor na sub-rede dentro da tua rede virtual.

• Se definir um papel personalizado em vez de usar o papel incorporado de Contribuidor de Rede, inclua as seguintes permissões:

  Permissão	Quando necessário
  Microsoft.Network/virtualNetworks/subnets/join/action	Sempre ao usar um papel personalizado
  Microsoft.Authorization/roleAssignments/write	Sempre ao usar um papel personalizado
  Microsoft.Network/virtualNetworks/subnets/read	Só ao definir as 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 usar a sua própria sub-rede e adicionar Grupos de Segurança de Rede (NSGs) associados a essa sub-rede, deve garantir que as regras de segurança nos NSGs permitem tráfego no intervalo CIDR do nó. Com o Azure CNI Overlay, se uma regra de negação NSG afetar o tráfego CIDR do pod, deve também permitir o tráfego do CIDR do nó para o CIDR do pod e do CIDR do pod para o CIDR do pod em todas as portas e protocolos. Para mais informações, consulte Grupos de segurança de rede com Azure CNI Overlay.

• O Serviço de Rede de Contentores (CNS) é um serviço local de nó dentro da rede CNI do Azure Kubernetes Service que aloca, acompanha e programa a rede para pods. Este componente envia telemetria (métricas e registos), por predefinição, para fora do cluster para um ponto final do Application Insights gerido pela Microsoft, para permitir uma resolução mais rápida de quaisquer problemas de atribuição de endereços IP de rede aos pods.

Conteúdo relacionado

• Sobreposição CNI do Azure
• Sub-rede de pods do Azure CNI
• Opções legadas de CNI
• Planeamento de endereços IP para os seus clusters