CNI (Interface de Rede de Contêiner) Herdada do AKS

No AKS (Serviço de Kubernetes do Azure), embora a Sobreposição de CNI do Azure e a Sub-rede de Pod da CNI do Azure sejam recomendados para a maioria dos cenários, modelos de rede herdados, como a Sub-rede de Nó da CNI do Azure e o kubenet, ainda estão disponíveis e são compatíveis. Esses modelos herdados oferecem abordagens diferentes para gerenciamento e rede de endereços IP de pod, cada um com seu próprio conjunto de funcionalidades e considerações. Este artigo fornece uma visão geral dessas opções de rede herdada, detalhando os pré-requisitos, parâmetros de implantação e características principais para ajudar você a entender as funções e como elas podem ser usadas efetivamente nos clusters do AKS.

Pré-requisitos

Os seguintes pré-requisitos são necessários para a Sub-rede de Nó da CNI do Azure e o kubenet:

• 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.

• 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 obter mais informações, confira Grupos de segurança de rede.

Observação

O kubenet não está disponível para contêineres do Windows Server. Para usar pools de nós do Windows Server, você precisa usar a CNI do Azure.

Sub-rede de Nó da CNI do Azure

Com a CNI (Interface de Rede de Contêiner) do Azure, cada pod obtém um endereço IP da sub-rede e pode ser acessado diretamente. Os sistemas na mesma rede virtual que o cluster do AKS veem o IP do pod como o endereço de origem para qualquer tráfego vindo do pod. Os sistemas fora da rede virtual do cluster do AKS veem o IP do nó como o endereço de origem de qualquer tráfego vindo do pod. Esses endereços IP devem ser exclusivos em todo o seu espaço de rede e devem ser planejados com antecedência. Cada nó tem um parâmetro de configuração para o número máximo de pods aos quais ele dá suporte. O número equivalente de endereços IP por nó é então reservado com antecedência para esse nó. Essa abordagem exige mais planejamento e, muitas vezes, leva à exaustão do endereço IP ou à necessidade de recriar os clusters em uma sub-rede maior conforme as demandas de aplicativo aumentam.

Com a Sub de Nó da CNI do Azure, cada pod recebe um endereço IP na sub-rede IP e pode se comunicar diretamente com outros pods e serviços. Seus clusters podem ser tão grandes quanto o intervalo de endereços IP especificado. No entanto, você deve planejar o intervalo de endereços IP com antecedência, e todos os endereços IP são consumidos pelos nós do AKS com base no número máximo de pods que eles podem suportar. Os recursos e cenários de rede avançados, como nós virtuais ou políticas de rede (Azure ou Calico), são compatíveis com a CNI do Azure.

Parâmetros de implantação

Quando você cria um cluster do AKS, os seguintes parâmetros são configuráveis para a rede CNI do Azure:

Rede virtual: a rede virtual na qual você deseja implantar o cluster do Kubernetes. Você pode criar uma nova rede virtual ou usar uma existente. Se você quiser usar uma rede virtual existente, verifique se ela está no mesmo local e na mesma assinatura do Azure que o cluster do Kubernetes. Para obter mais informações sobre limites e cotas para uma rede virtual do Azure, consulte Limites, cotas e restrições de assinatura e serviço do Azure.

Sub-rede: a sub-rede dentro da rede virtual em que você quer implantar o cluster. Você pode adicionar novas sub-redes à rede virtual durante o processo de criação do cluster. Para conectividade híbrida, o intervalo de endereços não deve se sobrepor a nenhuma outra rede virtual em seu ambiente.

Plug-in de rede do Azure: quando o plug-in de rede do Azure é usado, o serviço LoadBalancer interno com "externalTrafficPolicy=Local" não pode ser acessado por meio de VMs com um IP em clusterCIDR que não pertence ao cluster do AKS.

Intervalo de endereços do serviço do Kubernetes: este parâmetro é o conjunto de IPs virtuais que o Kubernetes atribui aos serviços internos no seu cluster. Esse intervalo não poderá ser atualizado depois que você criar o cluster. Você pode usar qualquer intervalo de endereço particular que atenda aos seguintes requisitos:

• Não deve estar dentro do intervalo de endereços IP da rede virtual do cluster.
• Não deve se sobrepor a nenhuma outra rede virtual com a qual a rede virtual do cluster está emparelhada.
• Não deve sobrepor IPs locais.
• Não deve estar dentro dos intervalos 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ou 192.0.2.0/24.

Embora seja possível especificar um intervalo de endereços de serviço na mesma rede virtual do cluster, não é recomendável. A sobreposição de intervalos de IP pode resultar em um comportamento imprevisível. Consulte mais informações em Perguntas Frequentes. Para obter mais informações sobre os serviços do Kubernetes, consulte Serviços na documentação do Kubernetes.

Endereço IP do serviço DNS do Kubernetes: O endereço IP para o serviço DNS do cluster. Esse endereço deve estar dentro do intervalo de endereços do serviço Kubernetes. Não use o primeiro endereço IP no intervalo de endereços. O primeiro endereço no seu intervalo de sub-rede é usado para o endereço kubernetes.default.svc.cluster.local.

Kubenet

Os clusters do AKS usam o kubenet, e criam uma rede virtual e uma sub-rede do Azure para você por padrão. Com o kubenet, os nós obtêm um endereço IP de uma sub-rede da rede virtual do Azure. Os pods recebem um endereço IP de um espaço de endereço logicamente diferente para a sub-rede da rede virtual do Azure dos nós. A conversão de endereços de rede (NAT) é então configurada para que os pods possam acessar recursos na rede virtual do Azure. O endereço IP de origem do tráfego é configurado via NAT como o endereço IP primário do nó. Esta abordagem reduz muito o número de endereços IP que você precisa reservar no espaço de rede para os pods usarem.

Você pode configurar o máximo de pods implantáveis em um nó no momento da criação do cluster ou ao criar novos pools de nós. Se você não especificar maxPods ao criar novos pools de nós, você recebe um valor padrão de 110 para kubenet.

Visão geral da rede do kubenet com sua própria sub-rede

Em muitos ambientes, você definiu redes e sub-redes virtuais com intervalos de endereços IP alocados e usa esses recursos para dar suporte a vários serviços e aplicativos. Para fornecer conectividade de rede, os clusters do AKS podem usar o kubenet (rede básica) ou o CNI do Azure (rede avançada).

Com o kubenet, somente os nós recebem um endereço IP na sub-rede da rede virtual. Os pods não podem se comunicar diretamente entre si. Em vez disso, o Roteamento Definido pelo Usuário (UDR) e o encaminhamento de IP lidam com a conectividade entre os pods nos nós. As UDRs e a configuração de encaminhamento de IP são criadas e mantidas pelo serviço AKS, mas você pode trazer sua própria tabela de rotas para o gerenciamento personalizado de rotas, se desejar. Você também pode implantar pods por trás de um serviço que recebe um endereço IP atribuído e balanceia a carga do tráfego para o aplicativo. O diagrama a seguir mostra como os nós do AKS recebem um endereço IP na sub-rede da rede virtual, mas não nos pods:

O Azure dá suporte a um máximo de 400 rotas em um UDR, portanto, você não pode ter um cluster do AKS com mais de 400 nós. Os nós virtuais do AKS e as políticas de rede do Azure não têm suporte com o kubenet. As Políticas de Rede do Calico têm suporte.

Limitações e considerações para kubenet

• Um salto adicional é necessário no design de kubenet, o que adiciona uma latência secundária à comunicação de pods.
• As tabelas de rotas e as rotas definidas pelo usuário são necessárias para usar o kubenet, o que adiciona complexidade às operações.
  • Para obter mais informações, confira Personalizar a saída do cluster com uma tabela de roteamento definida pelo usuário no AKS e Personalizar a saída do cluster com tipos de saída no AKS.
• O endereçamento de pod direto não é compatível com kubenet devido ao design do kubenet.
• Ao contrário dos clusters da CNI do Azure, múltiplos clusters kubenet não podem compartilhar uma sub-rede.
• 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 entre o CIDR do nó e do pod. Para ver detalhes, confira Grupos de segurança de rede.
• Os recursos não compatíveis com kubenet incluem:
  • Políticas de rede do Azure
  • Pools de nós do Windows
  • Complemento de nós virtuais

Observação

Alguns dos pods do sistema, como konnectivity dentro do cluster, usam o endereço IP do nó host em vez de um IP do espaço de endereço de sobreposição. Os pods do sistema usarão apenas o IP do nó e não um endereço IP da rede virtual.

Disponibilidade e esgotamento de endereços IP

Um problema comum com a CNI do Azure é que o intervalo de endereços IP atribuídos é muito pequeno para adicionar mais nós quando você dimensiona ou atualiza um cluster. A equipe de rede também pode não ser capaz de emitir um intervalo de endereços IP grande o suficiente para dar suporte às demandas esperadas dos aplicativos. Como um compromisso, você pode criar um cluster do AKS que usa o kubenet e se conectar a uma sub-rede de rede virtual existente. Esta abordagem permite que os nós recebam endereços IP definidos sem a necessidade de reservar um grande número de endereços IP antecipadamente para qualquer pod em potencial que possa ser executado no cluster.

Com o kubenet, você pode usar um intervalo de endereços IP muito menor e dar suporte a grandes clusters e demandas de aplicativos. Por exemplo, com um intervalo de endereços IP /27 em sua sub-rede, você pode executar um cluster de 20 a 25 nós com espaço suficiente para dimensionamento ou upgrade. Este tamanho de cluster pode dar suporte a até 2.200-2.750 pods (com um máximo padrão de 110 pods por nó). O número máximo de pods por nó que você pode configurar com o kubenet no AKS é 250.

Os seguintes cálculos básicos comparam a diferença nos modelos de rede:

• kubenet: Um simples intervalo de endereços IP /24 pode dar suporte a até 251 nós no cluster. Cada sub-rede da rede virtual do Azure reserva os três primeiros endereços IP para operações de gerenciamento. Esta contagem de nós pode dar suporte a até 27.610 pods, com um máximo padrão de 110 pods por nó.
• CNI do Azure: esse mesmo intervalo de sub-rede /24 básica só pode dar suporte a no máximo 8 nós no cluster. Esta contagem de nós pode dar suporte a até 240 pods, com um máximo padrão de 30 pods por nó.

Observação

Esses máximos não levam em conta operações de atualização ou dimensionamento. Na prática, você não pode executar o número máximo de nós que o intervalo de endereços IP de sub-rede dá suporte. Você deve deixar alguns endereços IP disponíveis para operações de colocação em escala ou upgrade.

Emparelhamento de rede virtual e conexões do ExpressRoute

Você pode usar o emparelhamento de rede virtual do Azure ou conexões do ExpressRoute com a CNI do Azure e o kubenet para fornecer conectividade local. Planeje os endereços IP com cuidado para evitar sobreposição e roteamento de tráfego incorreto. Por exemplo, muitas redes locais usam um intervalo de endereços 10.0.0.0/8 que é anunciado na conexão ExpressRoute. Recomendamos criar seus clusters do AKS em sub-redes da rede virtual do Azure fora deste intervalo de endereços, como 172.16.0.0/16.

Para obter mais informações, confira Comparar modelos de rede e os respectivos escopos de suporte.

Perguntas frequentes sobre a sub-rede de Pod da CNI do Azure

• Posso implantar VMs na sub-rede do cluster?

  Sim, para a Sub-rede de Nó da CNI do Azure, as VMs podem ser implantadas na mesma sub-rede que o cluster do AKS.

• Qual IP de origem os sistemas externos veem em um tráfego originado em um pod com o CNI do Azure habilitado?

  Os sistemas na mesma rede virtual que o cluster do AKS veem o IP do pod como o endereço de origem para qualquer tráfego vindo do pod. Os sistemas fora da rede virtual do cluster do AKS veem o IP do nó como o endereço de origem de qualquer tráfego vindo do pod. No entanto, para a alocação de IP dinâmica da CNI do Azure, não importa se a conexão está dentro da mesma rede virtual ou redes virtuais cruzadas, o IP do pod é sempre o endereço de origem para qualquer tráfego do pod. Isso ocorre porque a CNI do Azure para alocação de IP dinâmica implementa a infraestrutura de Rede de Contêiner do Microsoft Azure, que oferece experiência de ponta a ponta. Portanto, elimina o uso de ip-masq-agent, que ainda é usado pela CNI tradicional do Azure.

• Posso configurar políticas de rede por pod?

  Sim, a política de rede do Kubernetes está disponível no AKS. Para obter mais informações, consulte Proteger o tráfego entre os pods usando as políticas de rede no AKS.

• O número máximo de pods implantados em um nó é configurável?

  Por padrão, os clusters do AKS usam o kubenet e criam uma rede virtual e uma sub-rede. Com o kubenet, os nós obtém um endereço IP de uma sub-rede da rede virtual. Em seguida, o NAT (conversão de endereços de rede) é configurado nos nós e os pods recebem um endereço IP "oculto" por trás do IP do nó. Essa abordagem reduz o número de endereços IP que você precisa reservar no espaço de rede para uso dos pods.

  Com a CNI (Interface de Rede de Contêiner) do Azure, cada pod obtém um endereço IP da sub-rede e pode ser acessado diretamente. Os sistemas na mesma rede virtual que o cluster do AKS veem o IP do pod como o endereço de origem para qualquer tráfego vindo do pod. Os sistemas fora da rede virtual do cluster do AKS veem o IP do nó como o endereço de origem de qualquer tráfego vindo do pod. Esses endereços IP devem ser exclusivos em todo o seu espaço de rede e devem ser planejados com antecedência. Cada nó tem um parâmetro de configuração para o número máximo de pods aos quais ele dá suporte. O número equivalente de endereços IP por nó é então reservado com antecedência para esse nó. Essa abordagem exige mais planejamento e, muitas vezes, leva à exaustão do endereço IP ou à necessidade de recriar os clusters em uma sub-rede maior conforme as demandas de aplicativo aumentam.

• Posso implantar VMs na sub-rede do cluster?

  Sim. No entanto, para a CNI do Azure para alocação de IP dinâmica, as VMs não podem ser implantadas na sub-rede do pod.

• Qual IP de origem os sistemas externos veem em um tráfego originado em um pod com o CNI do Azure habilitado?

  Os sistemas na mesma rede virtual que o cluster do AKS veem o IP do pod como o endereço de origem para qualquer tráfego vindo do pod. Os sistemas fora da rede virtual do cluster do AKS veem o IP do nó como o endereço de origem de qualquer tráfego vindo do pod.

  No entanto, para a CNI do Azure para alocação de IP dinâmica, não importa se a conexão está dentro da mesma rede virtual ou redes virtuais cruzadas, o IP do pod é sempre o endereço de origem para qualquer tráfego do pod. Isso ocorre porque a CNI do Azure para alocação de IP dinâmica implementa a infraestrutura de Rede de Contêiner do Microsoft Azure, que oferece experiência de ponta a ponta. Portanto, elimina o uso de ip-masq-agent, que ainda é usado pela CNI tradicional do Azure.

• Eu posso usar uma sub-rede diferente na rede virtual do cluster para o intervalo de endereços de serviço do Kubernetes?

  Não é recomendado, mas essa configuração é possível. O intervalo de endereços do serviço é um conjunto de VIPs (IPs virtuais) que o Kubernetes atribui aos serviços internos no cluster. O Azure Networking não tem visibilidade do intervalo de IP de serviço do cluster do Kubernetes. A falta de visibilidade no intervalo de endereços de serviço do cluster pode levar a problemas. É possível criar posteriormente uma nova sub-rede na rede virtual do cluster que se sobrepõe ao intervalo de endereços de serviço. Se tal sobreposição ocorrer, o Kubernetes poderá atribuir um serviço a um IP que já esteja em uso por outro recurso na sub-rede, causando comportamento ou falhas imprevisíveis. Ao garantir que você use um intervalo de endereços fora da rede virtual do cluster, é possível evitar esse risco de sobreposição. Sim, ao implantar um cluster com a CLI do Azure ou um modelo do Resource Manager. Consulte Máximo de pods por nó.

• Eu posso usar uma sub-rede diferente na rede virtual do cluster para o intervalo de endereços de serviço do Kubernetes?

  Não é recomendado, mas essa configuração é possível. O intervalo de endereços do serviço é um conjunto de VIPs (IPs virtuais) que o Kubernetes atribui aos serviços internos no cluster. O Azure Networking não tem visibilidade do intervalo de IP de serviço do cluster do Kubernetes. A falta de visibilidade no intervalo de endereços de serviço do cluster pode levar a problemas. É possível criar posteriormente uma nova sub-rede na rede virtual do cluster que se sobrepõe ao intervalo de endereços de serviço. Se tal sobreposição ocorrer, o Kubernetes poderá atribuir um serviço a um IP que já esteja em uso por outro recurso na sub-rede, causando comportamento ou falhas imprevisíveis. Ao garantir que você use um intervalo de endereços fora da rede virtual do cluster, é possível evitar esse risco de sobreposição.