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 plug-ins CNI são responsáveis por atribuir endereços IP aos pods, roteamento de rede entre pods, roteamento de serviços do Kubernetes e mais.

O Azure Kubernetes Service (AKS) fornece múltiplos plugins CNI que pode usar nos seus clusters, dependendo das suas necessidades 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 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:

  • Conserva espaço de endereçamento IP para redes virtuais ao utilizar intervalos de Classless Inter-Domain Routing (CIDR) 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 total de 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 redes virtuais.

Ambos os modelos de rede têm múltiplas opções suportadas para plugins CNI. 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 sobrepostas, os pods recebem um endereço IP de um CIDR privado e logicamente separado da sub-rede da rede virtual do Azure na qual os nós AKS estão implantados. 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 redes sobrepostas, o AKS fornece o plugin Azure CNI Overlay . Recomendamos este plugin CNI 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 da mesma rede virtual do Azure que os nós AKS. O tráfego que sai dos teus clusters não é SNAT, e o endereço IP do pod fica diretamente exposto ao destino. Esta abordagem pode ser útil em alguns cenários, como quando é necessário expor endereços IP de pods a serviços externos.

O AKS fornece dois plugins CNI para redes planas:

• Azure CNI Pod Subnet, o plug-in CNI recomendado para cenários de rede simples.
• 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.

Escolher um plugin CNI

Ao escolher um plugin CNI, há vários fatores a considerar. 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 do plugin CNI que usar, pode implementar os recursos de rede virtual para o seu cluster de uma das seguintes formas:

• A plataforma Azure pode criar e configurar automaticamente os recursos virtuais da rede quando cria um cluster AKS, como no Azure CNI Overlay, Azure CNI Node Subnet e 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 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.

Prerequisites

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

• 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/16, ou 192.0.2.0/24 para intervalos de endereços para o serviço Kubernetes, pods ou redes virtuais de cluster.
• 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 quiser definir um papel personalizado em vez de usar o papel incorporado de Contribuidor de Rede, são necessárias as seguintes permissões:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.Network/virtualNetworks/subnets/read (necessário apenas se estiver a 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ó. Para mais informações, consulte a visão geral dos grupos de segurança de rede do Azure.

Conteúdo relacionado

• Sobreposição CNI do Azure
• Azure CNI Pod Subnet
• Opções legadas de CNI
• Planeamento de endereços IP para os seus clusters