Usar a rede kubenet com seus próprios intervalos de endereços IP no Serviço Kubernetes do Azure (AKS)

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.

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. Esses endereços IP devem ser planejados com antecedência e exclusivos em todo o espaço da rede. 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. 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.

Este artigo mostra como usar a rede kubenet para criar e usar uma sub-rede de rede virtual para um cluster AKS. Para obter mais informações sobre opções de rede e considerações, consulte Conceitos de rede para Kubernetes e AKS.

Pré-requisitos

• A rede virtual para o cluster AKS deve permitir conectividade de saída com a Internet.
• Não crie mais de um cluster AKS na mesma sub-rede.
• Os clusters AKS não podem usar 169.254.0.0/16, , 172.31.0.0/16172.30.0.0/16ou para o intervalo de endereços de serviço do Kubernetes, intervalo de endereços de pod ou 192.0.2.0/24 intervalo de endereços de rede virtual de cluster. O intervalo não pode ser atualizado depois de criar o cluster.
• A identidade do cluster usada pelo cluster AKS deve ter, pelo menos, a função de Colaborador de Rede na sub-rede dentro da sua rede virtual. A CLI ajuda a definir a atribuição de função automaticamente. Se você estiver usando um modelo ARM ou outros clientes, precisará definir manualmente a atribuição de função. Você também deve ter as permissões apropriadas, como o proprietário da assinatura, para criar uma identidade de cluster e atribuir-lhe permissões. Se você quiser definir uma função personalizada em vez de usar a função interna de Colaborador de Rede, precisará das seguintes permissões:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Aviso

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

Antes de começar

Você precisa da CLI do Azure versão 2.0.65 ou posterior instalada e configurada. Executar az --version para localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).

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.

Com o Azure CNI, 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.

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 oito 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

Para fornecer conectividade local, as abordagens de rede kubenet e Azure-CNI podem usar o emparelhamento de rede virtual do Azure ou conexões ExpressRoute. Planeje seus intervalos de 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.

Escolha um modelo de rede para usar

As considerações a seguir ajudam a descrever quando cada modelo de rede pode ser o mais apropriado:

Use kubenet quando:

• Você tem espaço de endereço IP limitado.
• A maior parte da comunicação do pod está dentro do cluster.
• Você não precisa de recursos avançados do AKS, como nós virtuais ou Política de Rede do Azure.

Use o Azure CNI quando:

• Você tem espaço de endereço IP disponível.
• A maior parte da comunicação do pod é para recursos fora do cluster.
• Você não deseja gerenciar rotas definidas pelo usuário para conectividade de pod.
• Você precisa de recursos avançados do AKS, como nós virtuais ou Política de Rede do Azure.

Para obter mais informações para ajudá-lo a decidir qual modelo de rede usar, consulte Comparar modelos de rede e seu escopo de suporte.

Criar uma rede virtual e uma sub-rede

1. Crie um grupo de recursos usando o az group create comando.

   az group create --name myResourceGroup --location eastus
   

2. Se você não tiver uma rede virtual e uma sub-rede existentes para usar, crie esses recursos de rede usando o az network vnet create comando. O comando de exemplo a seguir cria uma rede virtual chamada myAKSVnet com o prefixo de endereço 192.168.0.0/16 e uma sub-rede chamada myAKSSubnet com o prefixo de endereço 192.168.1.0/24:

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. Obtenha o ID do recurso de sub-rede usando o comando e armazene-o az network vnet subnet show como uma variável nomeada SUBNET_ID para uso posterior.

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

Criar um cluster AKS na rede virtual

Criar um cluster AKS com identidades gerenciadas atribuídas pelo sistema

Nota

Ao usar a identidade atribuída pelo sistema, a CLI do Azure concede a função de Colaborador de Rede à identidade atribuída ao sistema após a criação do cluster. Se você estiver usando um modelo ARM ou outros clientes, precisará usar a identidade gerenciada atribuída pelo usuário.

• Crie um cluster AKS com identidades gerenciadas atribuídas pelo sistema usando o az aks create comando.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID    
  

  Parâmetros de implantação:

  • --service-cidr é opcional. Este endereço é usado para atribuir serviços internos no cluster AKS um endereço IP. Esse intervalo de endereços IP deve ser um espaço de endereçamento que não esteja em uso em outro lugar em seu ambiente de rede, incluindo quaisquer intervalos de rede locais se você se conectar ou planeja conectar suas redes virtuais do Azure usando a Rota Expressa ou uma conexão VPN Site a Site. O valor padrão é 10.0.0.0/16.
  • --dns-service-ip é opcional. O endereço deve ser o endereço .10 do intervalo de endereços IP do serviço. O valor padrão é 10.0.0.10.
  • --pod-cidr é opcional. Esse endereço deve ser um grande espaço de endereçamento que não esteja em uso em outro lugar em seu ambiente de rede. Esse intervalo inclui qualquer intervalo de rede local se você se conectar ou planeja conectar suas redes virtuais do Azure usando a Rota Expressa ou uma conexão VPN Site a Site. O valor padrão é 10.244.0.0/16.
    • Esse intervalo de endereços deve ser grande o suficiente para acomodar o número de nós para os quais você espera ser dimensionado. Não é possível alterar esse intervalo de endereços depois que o cluster é implantado.
    • O intervalo de endereços IP do pod é usado para atribuir um espaço de endereço /24 a cada nó do cluster. No exemplo a seguir, o --pod-cidr de 10.244.0.0/16 atribui o primeiro nó 10.244.0.0/24, o segundo nó 10.244.1.0/24 e o terceiro nó 10.244.2.0/24.
    • À medida que o cluster é dimensionado ou atualizado, a plataforma Azure continua a atribuir um intervalo de endereços IP de pod a cada novo nó.

Criar um cluster AKS com identidade gerenciada atribuída pelo usuário

Criar uma identidade gerenciada

• Crie uma identidade gerenciada usando o az identity comando. Se você tiver uma identidade gerenciada existente, localize a ID Principal usando o az identity show --ids <identity-resource-id> comando.

  az identity create --name myIdentity --resource-group myResourceGroup
  

  Sua saída deve ser semelhante à saída de exemplo a seguir:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Adicionar atribuição de função para identidade gerenciada

Se você estiver usando a CLI do Azure, a função será adicionada automaticamente e você poderá ignorar esta etapa. Se você estiver usando um modelo ARM ou outros clientes, precisará usar a ID Principal da identidade gerenciada pelo cluster para executar uma atribuição de função.

• Obtenha o ID do recurso de rede virtual usando o comando e armazene-o az network vnet show como uma variável chamada VNET_ID.

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• Atribua a identidade gerenciada para suas permissões de Colaborador de Rede do cluster AKS na rede virtual usando o az role assignment create comando e forneça o <principalId>.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Nota

A permissão concedida à identidade gerenciada do cluster usada pelo Azure pode levar até 60 minutos para ser preenchida.

Criar um cluster do AKS

• Crie um cluster AKS usando o comando e forneça o ID do recurso de identidade gerenciado do plano de controle para o az aks createassign-identity argumento atribuir a identidade gerenciada atribuída pelo usuário.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id>
  

Quando você cria um cluster AKS, um grupo de segurança de rede e uma tabela de rotas são criados automaticamente. Esses recursos de rede são gerenciados pelo plano de controle AKS. O grupo de segurança de rede é automaticamente associado às NICs virtuais em seus nós. A tabela de rotas é automaticamente associada à sub-rede de rede virtual. As regras do grupo de segurança de rede e as tabelas de rotas são atualizadas automaticamente à medida que você cria e expõe serviços.

Trazer a sua própria sub-rede e tabela de rotas com o kubenet

Com o kubenet, uma tabela de rotas deve existir na(s) sub-rede(s) do cluster. O AKS suporta trazer sua própria sub-rede e tabela de rotas existentes. Se sua sub-rede personalizada não contiver uma tabela de rotas, o AKS criará uma para você e adicionará regras durante todo o ciclo de vida do cluster. Se sua sub-rede personalizada contiver uma tabela de rotas quando você criar seu cluster, o AKS reconhecerá a tabela de rotas existente durante as operações de cluster e adicionará/atualizará as regras de acordo com as operações do provedor de nuvem.

Aviso

Você pode adicionar/atualizar regras personalizadas na tabela de rotas personalizada. No entanto, regras são adicionadas pelo provedor de nuvem Kubernetes que não podem ser atualizadas ou removidas. Regras como 0.0.0.0/0 devem sempre existir em uma determinada tabela de rotas e mapear para o destino do seu gateway de internet, como um NVA ou outro gateway de saída. Tenha cuidado ao atualizar as regras.

Saiba mais sobre como configurar uma tabela de rotas personalizada.

A rede Kubenet requer regras de tabela de rotas organizadas para encaminhar solicitações com êxito. Devido a esse design, as tabelas de rotas devem ser cuidadosamente mantidas para cada cluster que depende dela. Vários clusters não podem compartilhar uma tabela de rotas porque CIDRs pod de clusters diferentes podem se sobrepor, o que causa cenários de roteamento inesperados e quebrados. Ao configurar vários clusters na mesma rede virtual ou dedicar uma rede virtual a cada cluster, considere as seguintes limitações:

• Uma tabela de rotas personalizada deve ser associada à sub-rede antes de criar o cluster AKS.
• O recurso de tabela de rotas associado não pode ser atualizado após a criação do cluster. No entanto, as regras personalizadas podem ser modificadas na tabela de rotas.
• Cada cluster AKS deve usar uma única tabela de rotas exclusiva para todas as sub-redes associadas ao cluster. Não é possível reutilizar uma tabela de rotas com vários clusters devido ao potencial de sobreposição de CIDRs de pod e regras de roteamento conflitantes.
• Para identidade gerenciada atribuída ao sistema, só há suporte para fornecer sua própria sub-rede e tabela de rotas por meio da CLI do Azure porque a CLI do Azure adiciona automaticamente a atribuição de função. Se você estiver usando um modelo ARM ou outros clientes, deverá usar uma identidade gerenciada atribuída pelo usuário, atribuir permissões antes da criação do cluster e garantir que a identidade atribuída pelo usuário tenha permissões de gravação para sua sub-rede personalizada e tabela de rotas personalizada.
• Não há suporte para o uso da mesma tabela de rotas com vários clusters AKS.

Nota

Quando você cria e usa sua própria VNet e tabela de rotas com o plug-in de rede kubenet, você precisa usar uma identidade de plano de controle atribuída pelo usuário. Para uma identidade de plano de controle atribuída pelo sistema, não é possível recuperar a ID de identidade antes de criar um cluster, o que causa um atraso durante a atribuição de função.

As identidades gerenciadas atribuídas pelo sistema e pelo usuário são suportadas quando você cria e usa sua própria VNet e tabela de rotas com o plug-in de rede do Azure. É altamente recomendável usar uma identidade gerenciada atribuída pelo usuário para cenários BYO.

Adicionar uma tabela de rotas com uma identidade gerenciada atribuída pelo usuário ao seu cluster AKS

Depois de criar uma tabela de rotas personalizada e associá-la a uma sub-rede em sua rede virtual, você pode criar um novo cluster AKS especificando sua tabela de rotas com uma identidade gerenciada atribuída pelo usuário. Você precisa usar o ID da sub-rede para onde planeja implantar seu cluster AKS. Essa sub-rede também deve ser associada à sua tabela de rotas personalizada.

1. Obtenha o ID da sub-rede usando o az network vnet subnet list comando.

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. Crie um cluster AKS com uma sub-rede personalizada pré-configurada com uma tabela de rotas usando o az aks create comando e fornecendo seus valores para os --vnet-subnet-idparâmetros , --enable-managed-identitye --assign-identity .

   az aks create -g myResourceGroup -n myManagedCluster --vnet-subnet-id mySubnetIDResourceID --enable-managed-identity --assign-identity controlPlaneIdentityResourceID
   

Próximos passos

Este artigo mostrou como implantar seu cluster AKS em sua sub-rede de rede virtual existente. Agora, você pode começar a criar novos aplicativos usando o Helm ou implantar aplicativos existentes usando o Helm.