Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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
Ao avaliar o suporte de rede para NAP, considere o modo de gestão de endereços IP (IPAM), o plugin de rede, o plano de dados de rede e a política de rede. A tabela seguinte descreve as opções suportadas pelo NAP:
| Camada de configuração | Option | Apoio ao NAP |
|---|---|---|
| IPAM | Sobreposição CNI do Azure | Suportado |
| IPAM | Sub-rede de Nó Azure CNI | Suportado |
| IPAM | Azure CNI Pod Subnet com Alocação Dinâmica de IP | Não suportado |
| Suplemento de rede | Kubenet | Não suportado |
| Plano de dados | Azure CNI alimentado por Cilium | Suportado num modo Azure CNI IPAM suportado |
| Política de rede | Calico | Não suportado |
Utilize o Azure CNI Overlay com o plano de dados Azure CNI Powered by Cilium. O Cilium oferece recursos avançados de rede e é otimizado para desempenho com NAP.
Configurações de sub-rede para NAP
Defina o campo opcional vnetSubnetID num recurso AKSNodeClass para configurar a sub-rede personalizada que o Karpenter utiliza para aprovisionar nós NAP. Se não especificar vnetSubnetID, o Karpenter usa a sub-rede padrão configurada durante a instalação, que normalmente é a sub-rede especificada pelo --vnet-subnet-id parâmetro quando cria o cluster AKS.
O NAP implementa, configura e gere automaticamente o Karpenter no seu cluster AKS e baseia-se nos projetos fornecedores de código aberto Karpenter e AKS Karpenter .
AKSNodeClass os recursos no seu cluster AKS podem especificar, cada um, um vnetSubnetID diferente, o que permite configurações mistas de sub-redes entre pools de nós. As classes de nó que não especificam vnetSubnetID usam 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.
Para clusters que utilizam uma rede virtual personalizada, mudar vnetSubnetID de uma sub-rede válida para outra faz com que os nós existentes associados à AKSNodeClass se desviem. Karpenter cria nós de substituição na nova sub-rede e desativa de forma controlada os nós divergentes de acordo com os NodePool orçamentos de interrupção.
Antes de alterar vnetSubnetID, certifica-te de que a identidade do cluster tem as permissões necessárias na nova sub-rede e de que a sub-rede dispõe de endereços IP disponíveis suficientes para os nós de substituição. Os orçamentos de interrupção de pods e as anotações karpenter.sh/do-not-disrupt podem atrasar a substituição voluntária por drift.
Importante
As redes virtuais geridas por AKS não suportam sub-redes personalizadas. Use vnetSubnetID apenas com uma rede virtual personalizada que gere por si.
Intervalos CIDR do cluster AKS para NAP
Quando configura uma rede personalizada com vnetSubnetID, precisa de compreender e gerir os intervalos CIDR do seu cluster para evitar conflitos de rede. Ao contrário dos pools tradicionais de nós AKS que se criam através de templates do Azure Resource Manager (ARM), o Karpenter aplica definições personalizadas de recursos (CRDs) que fornecem nós instantaneamente sem a validação estendida que o ARM proporciona.
Considerações sobre CIDR para configurações de sub-redes personalizadas do NAP
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:
Os exemplos seguintes mostram intervalos CIDR de sub-redes que entram em conflito com os CIDRs do cluster pod e do serviço, juntamente com uma configuração que evita esses conflitos. Use estes padrões para validar os seus intervalos de sub-redes antes de configurar vnetSubnetID.
# 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.
A pessoa que executa os seguintes comandos tem de ter permissão para criar a definição de função e as atribuições de funções necessárias, como a função Administrador de Controlo de Acesso Baseado em Funções. Não conceda permissões de escrita de atribuição de funções à identidade do cluster, a menos que este precise de criar atribuições de funções para outro cenário.
Obtenha o ID principal para a identidade gerida do cluster. Use o comando que corresponde ao tipo de identidade do cluster:
CLUSTER_IDENTITY=$(az aks show \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--query identity.principalId \
--output tsv)
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
A função Network Contributor atribui Microsoft.Network/*, o que permite à identidade do cluster criar, modificar e eliminar recursos de rede no âmbito da VNet atribuída. Revise este acesso antes de usar a função em produção porque o NAP requer apenas permissões de leitura e junção de sub-redes para este cenário.
Benefícios e considerações
A tabela seguinte apresenta as vantagens e desvantagens de atribuir a função Network Contributor ao nível da VNet.
| Benefícios das permissões VNet amplas | Considerações para permissões VNet amplas |
|---|---|
| • 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 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-object-id $CLUSTER_IDENTITY \
--assignee-principal-type ServicePrincipal \
--role "Network Contributor" \
--scope $VNET_ID
Para obter um exemplo completo de configuração de rede personalizada e de atribuição de permissões alargadas da VNet, consulte o script de exemplo de configuração de VNet personalizada - 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.
Defina o spec.vnetSubnetID campo para o ID completo de recurso Azure da sub-rede alvo usando o formato /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
name: custom-networking
spec:
vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_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/$VNET_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/$VNET_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 o Azure permite trazer as suas próprias configurações de Interface de Rede de Container (BYO CNI), e segue a mesma política de suporte do AKS. O BYO CNI não torna suportada uma configuração que o NAP indica como não suportada, como kubenet ou Calico. Quando utiliza um CNI personalizado, o suporte de resolução de problemas relacionado com redes está fora do âmbito de quaisquer acordos de nível de serviço ou garantias.
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: