Partilhar via

Visão geral das configurações de rede para o provisionamento automático de nós (NAP) no Azure Kubernetes Service (AKS)

Este artigo oferece uma visão geral dos requisitos e recomendações de configuração de rede para clusters do Azure Kubernetes Service (AKS) com o provisionamento automático de nós (NAP). Ele abrange configurações suportadas, comportamento de sub-rede padrão, configuração de controle de acesso baseado em função (RBAC) e considerações de roteamento entre domínios sem classe (CIDR).

Para obter uma visão geral do provisionamento automático de nós no AKS, consulte Visão geral do provisionamento automático de nós (NAP) no Serviço Kubernetes do Azure (AKS).

Configurações de rede suportadas para NAP

A NAP suporta as seguintes configurações de rede:

Recomendamos usar o Azure CNI com o Cilium. O Cilium oferece recursos avançados de rede e é otimizado para desempenho com NAP.

Configurações de rede sem suporte para NAP

A NAP não suporta as seguintes configurações de rede:

  • Política de rede Calico
  • Alocação dinâmica de IP

Configurações de sub-rede para NAP

A NAP implanta, configura e gerencia automaticamente o Karpenter em seus clusters AKS e é baseada nos projetos de provedor Karpenter e AKS Karpenter de código aberto. Pode utilizar AKSNodeClass recursos para especificar configurações personalizadas de sub-rede para nós NAP nos seus agrupamentos de nós, definindo o campo opcional vnetSubnetID, e o Karpenter usa a sub-rede que especificou para o aprovisionamento de nós. Se você não especificar uma sub-rede, o Karpenter usará a sub-rede padrão configurada durante a instalação do Karpenter. Esta sub-rede padrão é normalmente a mesma sub-rede especificada durante a criação do cluster AKS com o --vnet-subnet-id parâmetro no az aks create comando.

Essa abordagem permite que você tenha uma combinação de classes de nó, com algumas usando sub-redes personalizadas para cargas de trabalho específicas e outras usando a configuração de sub-rede padrão do cluster.

Comportamento de desvio de sub-rede

Karpenter monitora as alterações de configuração da sub-rede e detecta desvios quando o vnetSubnetID em um AKSNodeClass é modificado. Compreender esse comportamento é fundamental ao gerenciar configurações de rede personalizadas.

A modificação vnetSubnetID de uma sub-rede válida para outra sub-rede válida não é uma operação suportada. Se alterar o vnetSubnetID para apontar para uma sub-rede válida diferente, o Karpenter deteta isso como desvio de sub-rede e impede o provisionamento do nó até que o problema seja resolvido revertendo o vnetSubnetID para a sub-rede original. Esse comportamento garante que os nós sejam provisionados apenas nas sub-redes pretendidas, mantendo a integridade e a segurança da rede. No entanto, existem exceções a esta regra. Você só pode modificar o vnetSubnetID nos seguintes cenários:

  • Corrigir um ID de sub-rede malformado que impede o provisionamento dos nós.
  • Corrigir uma referência de sub-rede inválida que causa erros de configuração.
  • Atualizar um identificador de sub-rede que aponta para uma sub-rede inexistente ou inacessível.

Compreender os intervalos CIDR (Classless Inter-Domain Routing) do cluster de AKS

Ao configurar a rede personalizada com vnetSubnetID, é responsável por entender e gerir os intervalos CIDR do cluster para evitar conflitos de rede. Ao contrário dos pools de nós AKS tradicionais criados por meio de modelos ARM, Karpenter aplica definições de recursos personalizadas (CRDs) que provisionam nós instantaneamente sem a validação estendida que o ARM fornece.

Considerações CIDR para configurações de sub-rede personalizadas

Ao configurar vnetSubnetID, deve:

  • Verificar a compatibilidade CIDR: certifique-se de que as sub-redes personalizadas não entrem em conflito com os intervalos CIDR existentes.
  • Planejar a capacidade de IP: calcule os endereços IP necessários para o dimensionamento esperado.
  • Validar conectividade: teste rotas de rede e regras de grupo de segurança.
  • Monitore o uso: acompanhe a utilização da sub-rede e planeje o crescimento.
  • Configuração de documentos: Mantenha registros de decisões de projeto de rede.

Conflitos CIDR comuns

Esteja ciente dos seguintes cenários comuns de conflito CIDR ao usar sub-redes personalizadas com NAP:

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

Configuração do RBAC para configurações de sub-rede personalizadas

Ao usar configurações de sub-rede personalizadas com NAP, você precisa garantir que o Karpenter tenha as permissões necessárias para ler informações de sub-rede e unir nós às sub-redes especificadas. Isso requer a configuração de permissões RBAC apropriadas para a identidade gerenciada do cluster.

Há duas abordagens principais para configurar essas permissões: Atribuir permissões de rede virtual ampla (VNet) ou Atribuir permissões de sub-rede com escopo.

Essa abordagem é a mais permissiva e concede à identidade do cluster permissões para ler e unir-se a qualquer sub-rede dentro da VNet principal, além de fornecer acesso de contribuidor de rede.

Importante

Investigue a função "Colaborador de rede" antes de aplicar essa abordagem ao cluster de produção.

Benefícios e considerações

A tabela a seguir descreve os benefícios e as considerações da atribuição de permissões de rede virtual amplas:

Benefícios Considerações
• Simplifica a gestão de permissões.
• Elimina a necessidade de atualizar permissões ao adicionar novas sub-redes.
• Funciona bem para ambientes de inquilino único.
• Funciona quando uma subscrição atinge o número máximo de funções personalizadas.		 • Fornece permissões mais amplas do que o estritamente necessário.
• Pode não cumprir requisitos de segurança rigorosos.

Permissões necessárias

Para atribuir permissões de VNet amplas, conceda à identidade gerenciada do cluster as seguintes permissões na rede virtual:

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

Para obter um exemplo completo de configuração de rede personalizada e atribuição de permissões de rede virtual amplas, consulte a Configuração de VNET personalizada - Script de exemplo RBAC mais permissivo.

Exemplo de configurações de sub-rede personalizadas

O exemplo a seguir mostra como configurar uma sub-rede personalizada para nós NAP usando o campo vnetSubnetID num recurso AKSNodeClass.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

O exemplo a seguir mostra como usar várias classes de nó com diferentes configurações de sub-rede:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Traga sua própria política de suporte CNI (BYO CNI)

O Karpenter para Azure permite trazer suas próprias configurações de Interface de Rede de Contêiner (BYO CNI), seguindo a mesma política de suporte do AKS. Isso significa que, ao usar um CNI personalizado, o suporte à solução de problemas relacionado à rede está fora do escopo de quaisquer contratos ou garantias de nível de serviço.

Detalhes do escopo do suporte

A seguir descreve o que é e o que não é suportado ao usar o BYO CNI com Karpenter:

  • Suportado: funcionalidades específicas do Karpenter e problemas de integração ao usar configurações CNI de traga seu próprio (BYO).
  • Não suportado: problemas de rede específicos da CNI, problemas de configuração ou solução de problemas ao usar plug-ins CNI de terceiros.

Próximos passos

Para obter mais informações sobre o provisionamento automático de nós no AKS, consulte os seguintes artigos:

  • Last updated on