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

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.

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

Este artigo mostra como usar a rede kubenet para criar e usar uma sub-rede da rede virtual de um cluster do AKS. Para saber mais sobre opções de rede e considerações, confira Conceitos de rede para o Kubernetes e o AKS.

Pré-requisitos

• A rede virtual do cluster do AKS deve permitir conectividade com a Internet de saída.
• Não crie mais de um cluster do AKS na mesma sub-rede.
• 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. O intervalo não pode ser atualizado depois que você criar o cluster.
• A identidade do cluster usada pelo cluster do AKS deve ter pelo menos a função de Colaborador de Rede na sub-rede dentro de sua rede virtual. A CLI ajuda a definir a atribuição de função automaticamente. Se estiver usando um modelo do ARM ou outros clientes, será necessário 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 permissões a ela. Se você desejar definir uma função personalizada em vez de usar a função integrada 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 a CNI do Azure. O modelo de rede kubenet não está disponível para contêineres do Windows Server.

Antes de começar

Você precisará da CLI do Azure versão 2.0.65 ou posterior instalada e configurada. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

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.

Com a 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 cenários e recursos avançados de rede, como nós virtuais ou políticas de rede (Azure ou Calico), têm suporte com a CNI do Azure.

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ásico só pode dar suporte a um máximo de oito 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

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

Escolher um modelo de rede para usar

As seguintes considerações ajudam a delinear quando cada modelo de rede pode ser o mais adequado:

Use kubenet quando:

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

Use CNI do Azure quando:

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

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

Criar a rede virtual e a sub-rede

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

   az group create --name myResourceGroup --location eastus
   

2. Se você não tiver uma rede virtual e uma sub-rede para usar, crie esses recursos de rede usando o comando az network vnet create. O comando de exemplo a seguir cria uma rede virtual nomeada myAKSVnet com o prefixo de endereço 192.168.0.0/16 e uma sub-rede nomeada 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 a ID do recurso de sub-rede usando o comando az network vnet subnet show e armazene-a 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 do AKS na rede virtual

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

Observação

Ao usar a identidade atribuída pelo sistema, a CLI do Azure concede a função de Colaborador de Rede à identidade atribuída pelo sistema depois que o cluster é criado. Se estiver usando um modelo do ARM ou outros clientes, será necessário usar a identidade gerenciada atribuída pelo usuário em vez disso.

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

  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. Esse endereço é usado para atribuir um endereço IP aos serviços internos no cluster do AKS. Esse intervalo de endereços IP deve ser um espaço de endereço que não esteja em uso em outro lugar de seu ambiente de rede, incluindo qualquer intervalo de rede local se você se conectar ou se planejar conectar suas redes virtuais do Azure usando o ExpressRoute 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 espaço de endereço grande que não esteja em uso em outro lugar no ambiente de rede. Esse intervalo inclui qualquer intervalo de rede local se você conectar ou planejar conectar suas redes virtuais do Azure usando o ExpressRoute 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 que você espera ampliar. Não será possível alterar esse intervalo de endereços depois que o cluster for implantado.
    • O intervalo de endereços IP do pod é usado para atribuir um espaço de endereço /24 a cada nó no cluster. No exemplo a seguir, o --pod-cidr do 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 do Azure continua atribuindo um intervalo de endereços IP do pod a cada novo nó.

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

Criar uma identidade gerenciada

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

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

  Sua saída deve ser parecida com o seguinte exemplo de saída:

  {                                  
    "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 é automaticamente adicionada e você pode ignorar esta etapa. Se você estiver usando um modelo do ARM ou outros clientes, você precisa de usar a ID da Entidade da identidade gerenciada do cluster para realizar uma atribuição de função.

• Obtenha a ID do recurso de rede virtual usando o comando az network vnet show e armazene-a como uma variável nomeada 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 do AKS na rede virtual usando o comando az role assignment create e forneça a <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"
  

Observação

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

Criar um cluster AKS

• Crie um cluster do AKS usando o comando az aks create e forneça a ID do recurso de identidade gerenciada do painel de controle para que o argumento assign-identity para atribua 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 do AKS, um grupo de segurança de rede e uma tabela de rotas são automaticamente criados. Esses recursos de rede são gerenciados pelo plano de controle do AKS. O grupo de segurança de rede é associado automaticamente às NICs virtuais em seus nós. A tabela de rotas é associada automaticamente à sub-rede da rede virtual. As regras do grupo de segurança de rede e as tabelas de rotas são atualizadas automaticamente conforme você cria e expõe os serviços.

Traga sua própria sub-rede e suas tabela de rotas com kubenet

Com o kubenet, uma tabela de rotas deve existir em suas sub-redes do cluster. O AKS permite trazer sua própria sub-rede e sua tabela de rotas existentes. Se a 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 a sua sub-rede personalizada contiver uma tabela de rotas quando você criar o cluster, o AKS confirmará a tabela de rotas existente durante 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 personalizadas. No entanto, as regras são adicionadas pelo provedor de serviços de nuvem Kubernetes e 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 exige regras organizadas da tabela de rotas para rotear solicitações com sucesso. Devido a este design, as tabelas de rotas devem ser cuidadosamente mantidas para cada cluster que depende delas. Múltiplos clusters não podem compartilhar uma tabela de rotas porque os CIDRs de pods de diferentes clusters podem se sobrepor, o que causa cenários de roteamento inesperados e incorretos. 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 à possibilidade de sobreposição de CIDRs de pods e regras de roteamento conflitantes.
• Para a identidade gerenciada atribuída pelo sistema, só há suporte para fornecer sua própria sub-rede e tabela de rotas através da CLI do Azure, porque a CLI do Azure adiciona automaticamente a atribuição de função. Se você estiver usando um modelo do ARM ou outros clientes, você deve 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 na sua sub-rede personalizada e na tabela de rotas personalizadas.
• Não há suporte para o uso da mesma tabela de roteamento com vários clusters AKS.

Observação

Ao criar e usar sua própria VNet e tabela de rotas com o plug-in de rede kubenet, é necessário 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ções.

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

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

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

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

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

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

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

Próximas etapas

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