Interfaces de rede de contêineres legados (CNI) do AKS

No Serviço Kubernetes do Azure (AKS), enquanto a Sobreposição CNI do Azure e a Sub-rede de Pod CNI do Azure são recomendadas para a maioria dos cenários, os modelos de rede herdados, como a Sub-rede do Nó CNI do Azure e o kubenet, ainda estão disponíveis e são suportados. Esses modelos legados oferecem diferentes abordagens para gerenciamento de endereços IP pod e rede, cada um com seu próprio conjunto de recursos e considerações. Este artigo fornece uma visão geral dessas opções de rede herdadas, detalhando seus pré-requisitos, parâmetros de implantação e características-chave para ajudá-lo a entender suas funções e como elas podem ser usadas de forma eficaz em seus clusters AKS.

Pré-requisitos

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

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

• A identidade do cluster usada pelo cluster AKS deve ter pelo menos permissões de Colaborador de Rede na sub-rede dentro da rede virtual. Se você quiser 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.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write

• 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, verifique se as regras de segurança nos NSGs permitem o tráfego dentro do intervalo CIDR do nó. Para obter mais informações, consulte Grupos de segurança de rede.

Nota

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

Sub-rede do nó 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 do pod. Os sistemas fora da rede virtual do cluster AKS veem o IP do nó como o endereço de origem de qualquer tráfego do pod. Esses endereços IP devem ser exclusivos em todo o espaço da 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 suportados. O número equivalente de endereços IP por nó é então reservado antecipadamente para esse nó. Essa abordagem requer mais planejamento e muitas vezes leva ao esgotamento do endereço IP ou à necessidade de reconstruir clusters em uma sub-rede maior à medida que as demandas do seu aplicativo crescem.

Com a Sub-rede de Nó 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 AKS com base no número máximo de pods que eles podem suportar. Recursos de rede avançados e cenários, como nós virtuais ou Políticas de Rede (Azure ou Calico) são suportados com o Azure CNI.

Parâmetros de implantação

Quando você cria um cluster 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 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 seu cluster do Kubernetes. Para obter informações sobre os limites e cotas para uma rede virtual do Azure, consulte Limites de assinatura e serviço, cotas e restrições do Azure.

Sub-rede: A sub-rede dentro da rede virtual onde você deseja 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 de VMs com um IP em clusterCIDR que não pertença ao cluster AKS.

Intervalo de endereços de serviço do Kubernetes: este parâmetro é o conjunto de IPs virtuais que o Kubernetes atribui a serviços internos em seu cluster. Este intervalo não pode ser atualizado depois de criar o cluster. Você pode usar qualquer intervalo de endereços privados que satisfaça os seguintes requisitos:

• Não deve estar dentro do intervalo de endereços IP da rede virtual do cluster.
• Não deve sobrepor-se a quaisquer outras redes virtuais com as quais o cluster de rede virtual pares.
• Não deve sobrepor-se a nenhum IPs local.
• Não deve estar dentro dos intervalos 169.254.0.0/16, , 172.30.0.0/16172.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 o recomendamos. A sobreposição de intervalos de IP pode resultar em um comportamento imprevisível. Para obter mais informações, consulte as FAQs. 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 do serviço DNS do cluster. Este endereço tem de estar dentro do intervalo de endereços do serviço Kubernetes. Não use o primeiro endereço IP no seu intervalo de endereços. O primeiro endereço no intervalo de sub-redes é usado para o endereço kubernetes.default.svc.cluster.local .

Kubenet

Os clusters AKS usam 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 da sub-rede da rede virtual do Azure. Os pods recebem um endereço IP de um espaço de endereços 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 alcançar recursos na rede virtual do Azure. O endereço IP de origem do tráfego é NAT para o endereço IP primário do nó. Essa abordagem reduz consideravelmente o número de endereços IP que você precisa reservar em seu espaço de rede para 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, receberá um valor padrão de 110 para kubenet.

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

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

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

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

Limitações e considerações para kubenet

• Um salto adicional é necessário no design do kubenet, que adiciona menor latência à comunicação do pod.
• Tabelas de rotas e 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, consulte 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 direto de pod não é suportado para kubenet devido ao design kubenet.
• Ao contrário dos clusters CNI do Azure, vários clusters kubenet não podem compartilhar uma sub-rede.
• 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 entre o nó e o pod CIDR. Para obter mais detalhes, consulte Grupos de segurança de rede.
• Os recursos não suportados no kubenet incluem:
  • Políticas de rede do Azure
  • Pools de nós do Windows
  • Complemento de nós virtuais

Nota

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 exaustão do endereço IP

Um problema comum com o Azure CNI é que o intervalo de endereços IP atribuído é 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 de aplicativos esperadas. Como compromisso, você pode criar um cluster AKS que usa kubenet e se conectar a uma sub-rede de rede virtual existente. Essa 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 quaisquer pods potenciais que possam ser executados no cluster.

Com o kubenet, você pode usar um intervalo de endereços IP muito menor e suportar 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 dimensionar ou atualizar. Esse tamanho de cluster pode suportar 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 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 suportar até 251 nós no cluster. Cada sub-rede de rede virtual do Azure reserva os três primeiros endereços IP para operações de gerenciamento. Essa contagem de nós pode suportar até 27.610 pods, com um máximo padrão de 110 pods por nó.
• Azure CNI: Esse mesmo intervalo de sub-rede /24 básico só pode suportar um máximo de 8 nós no cluster. Essa contagem de nós só pode suportar até 240 pods, com um máximo padrão de 30 pods por nó.

Nota

Esses máximos não levam em conta operações de atualização ou escala. Na prática, não é possível executar o número máximo de nós suportados pelo intervalo de endereços IP da sub-rede. Você deve deixar alguns endereços IP disponíveis para operações de dimensionamento ou atualização.

Emparelhamento de rede virtual e conexões de Rota Expressa

Você pode usar o emparelhamento de rede virtual do Azure ou conexões de Rota Expressa com o Azure CNI e kubenet para fornecer conectividade local. Certifique-se de planejar seus endereços IP cuidadosamente 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 AKS em sub-redes de rede virtual do Azure fora desse intervalo de endereços, como 172.16.0.0/16.

Para obter mais informações, consulte Comparar modelos de rede e seus escopos de suporte.

Perguntas frequentes sobre o Azure CNI Pod Subnet

• Posso implantar VMs na minha sub-rede de cluster?

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

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

  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 do pod. Os sistemas fora da rede virtual do cluster AKS veem o IP do nó como o endereço de origem de qualquer tráfego do pod. Mas para a alocação de IP dinâmico CNI do Azure, não importa se a conexão está dentro da mesma rede virtual ou entre redes virtuais, 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âmico implementa a infraestrutura de Rede de Contêineres do Microsoft Azure, que oferece experiência de ponta a ponta. Assim, elimina o uso do ip-masq-agent, que ainda é usado pelo 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 começar, consulte Proteger o tráfego entre pods usando políticas de rede no AKS.

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

  Por padrão, os clusters AKS usam 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 de rede virtual. A conversão de endereços de rede (NAT) é então configurada nos nós e os pods recebem um endereço IP "oculto" atrás do IP do nó. Essa abordagem reduz o número de endereços IP que você precisa reservar em seu espaço de rede para pods usarem.

  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 do pod. Os sistemas fora da rede virtual do cluster AKS veem o IP do nó como o endereço de origem de qualquer tráfego do pod. Esses endereços IP devem ser exclusivos em todo o espaço da 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 suportados. O número equivalente de endereços IP por nó é então reservado antecipadamente para esse nó. Essa abordagem requer mais planejamento e muitas vezes leva ao esgotamento do endereço IP ou à necessidade de reconstruir clusters em uma sub-rede maior à medida que as demandas do seu aplicativo crescem.

• Posso implantar VMs na minha sub-rede de cluster?

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

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

  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 do pod. Os sistemas fora da rede virtual do cluster AKS veem o IP do nó como o endereço de origem de qualquer tráfego do pod.

  Mas para o Azure CNI para alocação de IP dinâmico, não importa se a conexão está dentro da mesma rede virtual ou entre redes virtuais, 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âmico implementa a infraestrutura de Rede de Contêineres do Microsoft Azure, que oferece experiência de ponta a ponta. Assim, elimina o uso do ip-masq-agent, que ainda é usado pelo CNI tradicional do Azure.

• Posso usar uma sub-rede diferente dentro da minha rede virtual de cluster para o intervalo de endereços de serviço do Kubernetes?

  Não é recomendado, mas esta configuração é possível. O intervalo de endereços de serviço é um conjunto de IPs virtuais (VIPs) que o Kubernetes atribui a serviços internos em seu cluster. A Rede do Azure não tem visibilidade do intervalo de IP de serviço do cluster Kubernetes. A falta de visibilidade do 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 essa sobreposição ocorrer, o Kubernetes poderá atribuir a um serviço um IP que já esteja em uso por outro recurso na sub-rede, causando comportamento imprevisível ou falhas. Ao garantir que você use um intervalo de endereços fora da rede virtual do cluster, você pode evitar esse risco de sobreposição. Sim, quando você implanta um cluster com a CLI do Azure ou um modelo do Gerenciador de Recursos. Consulte Máximo de pods por nó.

• Posso usar uma sub-rede diferente dentro da minha rede virtual de cluster para o intervalo de endereços de serviço do Kubernetes?

  Não é recomendado, mas esta configuração é possível. O intervalo de endereços de serviço é um conjunto de IPs virtuais (VIPs) que o Kubernetes atribui a serviços internos em seu cluster. A Rede do Azure não tem visibilidade do intervalo de IP de serviço do cluster Kubernetes. A falta de visibilidade do 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 essa sobreposição ocorrer, o Kubernetes poderá atribuir a um serviço um IP que já esteja em uso por outro recurso na sub-rede, causando comportamento imprevisível ou falhas. Ao garantir que você use um intervalo de endereços fora da rede virtual do cluster, você pode evitar esse risco de sobreposição.