Panoramica delle configurazioni di rete per il provisioning automatico dei nodi (NAP) nel servizio Azure Kubernetes

Questo articolo offre una panoramica dei requisiti di configurazione della rete e dei consigli per i cluster di Servizio Azure Kubernetes (AKS) utilizzando il node auto-provisioning (NAP). Vengono illustrate le configurazioni supportate, il comportamento predefinito della subnet, la configurazione del controllo degli accessi in base al ruolo e le considerazioni relative al routing tra domini (CIDR) senza classi.

Per una panoramica del provisioning automatico dei nodi nel servizio Azure Kubernetes, vedere Panoramica del provisioning automatico dei nodi (Protezione accesso alla rete) nel servizio Azure Kubernetes.

Configurazioni di rete supportate per Protezione accesso alla rete

Quando valuti il supporto networking per NAP, considera la modalità di gestione degli indirizzi IP (IPAM), il plugin di rete, il data plane di rete e la policy di rete. La tabella seguente descrive le opzioni supportate da NAP:

Usa Azure CNI Overlay con il data plane Azure CNI Powered by Cilium. Cilium offre funzionalità di rete avanzate ed è ottimizzato per le prestazioni con Nap.

Configurazioni delle sottoreti per NAP

Imposta il campo facoltativo vnetSubnetID in una risorsa AKSNodeClass per configurare la subnet personalizzata che Karpenter utilizza per eseguire il provisioning dei nodi NAP. Se non si specifica vnetSubnetID, Karpenter usa la subnet predefinita configurata durante l'installazione, che in genere è la subnet specificata dal parametro --vnet-subnet-id quando si crea il cluster AKS.

NAP distribuisce automaticamente, configura e gestisce Karpenter nel cluster AKS e si basa sui progetti open source Karpenter e provider AKS Karpenter.

AKSNodeClass risorse nel cluster AKS possono specificare ciascuna un vnetSubnetID diverso, consentendo configurazioni di subnet miste nei pool di nodi. Le classi di nodi che non specificano vnetSubnetID usano la configurazione della subnet predefinita del cluster.

Comportamento di deriva della subnet

Karpenter monitora le modifiche alla configurazione della subnet e rileva la deviazione quando il vnetSubnetID viene modificato in un AKSNodeClass. Comprendere questo comportamento è fondamentale quando si gestiscono configurazioni di rete personalizzate.

Per i cluster che usano una rete virtuale personalizzata, la modifica di vnetSubnetID da una subnet valida a un'altra fa sì che i nodi esistenti associati a AKSNodeClass vadano in stato di drift. Karpenter crea nodi sostitutivi nella nuova subnet e disattiva in modo controllato i nodi soggetti a drift secondo i NodePoolbudget di interruzione.

Prima di modificare vnetSubnetID, assicurarsi che l'identità del cluster disponga delle autorizzazioni necessarie per la nuova subnet e che la subnet disponga di indirizzi IP disponibili sufficienti per i nodi sostitutivi. I budget di interruzione dei pod e le annotazioni karpenter.sh/do-not-disrupt possono ritardare la sostituzione volontaria della deriva.

Intervalli CIDR del cluster AKS per NAP

Quando si configura una rete personalizzata con vnetSubnetID, è necessario comprendere e gestire gli intervalli CIDR del cluster per evitare conflitti di rete. A differenza dei pool di nodi del servizio Azure Kubernetes tradizionali creati tramite modelli di Azure Resource Manager (ARM), Karpenter applica le definizioni di risorse personalizzate (CRD) che effettuano immediatamente il provisioning dei nodi senza la convalida estesa fornita da ARM.

Considerazioni CIDR per le configurazioni personalizzate della subnet NAP

Quando si configura vnetSubnetID, è necessario:

• Verificare la compatibilità CIDR: assicurarsi che le subnet personalizzate non siano in conflitto con gli intervalli CIDR esistenti.
• Pianificare la capacità IP: calcolare gli indirizzi IP necessari per il ridimensionamento previsto.
• Convalida connettività: testare le rotte di rete e le regole del gruppo di sicurezza.
• Monitorare l'utilizzo: tenere traccia dell'utilizzo della subnet e pianificare la crescita.
• Configurazione del documento: consente di gestire i record delle decisioni relative alla progettazione di rete.

Conflitti CIDR comuni

Tenere presente i seguenti scenari di conflitto CIDR comuni quando si utilizzano subnet personalizzate con NAP:

Negli esempi seguenti vengono illustrati gli intervalli CIDR della subnet in conflitto con i CIDR del pod e del servizio del cluster, insieme a una configurazione che evita tali conflitti. Usare questi modelli per convalidare gli intervalli di subnet prima di configurare 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

Configurazione del controllo degli accessi in base al ruolo per le configurazioni di subnet personalizzate

Quando si usano configurazioni di subnet personalizzate con NAP, è necessario assicurarsi che Karpenter disponga delle autorizzazioni necessarie per leggere le informazioni sulla subnet e collegare i nodi alle subnet specificate. Ciò richiede la configurazione delle autorizzazioni RBAC appropriate per l'identità gestita del cluster.

La persona che esegue i comandi seguenti deve avere l'autorizzazione per creare la definizione del ruolo e le assegnazioni di ruolo necessarie, ad esempio il ruolo Amministratore basato su ruoli Controllo di accesso. Non concedere autorizzazioni di scrittura per l'assegnazione di ruolo all'identità del cluster, a meno che non sia necessario creare assegnazioni di ruolo per un altro scenario.

Ottenere l'ID entità dell'identità gestita del cluster. Usare il comando che corrisponde al tipo di identità del cluster:

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

CLUSTER_IDENTITY=$(az identity show \
  --resource-group $IDENTITY_RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query principalId \
  --output tsv)

Esistono due approcci principali per configurare queste autorizzazioni: Assegnare autorizzazioni di rete virtuale (VNet) generali o Assegnare autorizzazioni subnet con ambito.

# 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

# For each subnet, assign specific subnet permissions
SUBNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

# Create custom role definition for subnet access
cat > subnet-access-role.json << EOF
{
  "Name": "Karpenter Subnet Access",
  "IsCustom": true,
  "Description": "Allows reading subnet information and joining VMs to subnets",
  "Actions": [
    "Microsoft.Network/virtualNetworks/subnets/read",
    "Microsoft.Network/virtualNetworks/subnets/join/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}
EOF

# Create the custom role (only needed once per subscription)
az role definition create --role-definition subnet-access-role.json

# Assign the custom role to each subnet
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

Configurazioni di subnet personalizzate di esempio

L'esempio seguente illustra come configurare una subnet personalizzata per i nodi NAP usando il campo vnetSubnetID in una risorsa AKSNodeClass:

Imposta il campo spec.vnetSubnetID sull'ID completo della risorsa Azure della subnet di destinazione utilizzando il 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"

L'esempio seguente illustra come usare più classi di nodi con configurazioni di subnet diverse:

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"

Politica di supporto di Bring Your Own CNI (BYO CNI)

Karpenter per Azure consente di usare configurazioni BYO CNI (Bring Your Own Container Network Interface) e segue gli stessi criteri di supporto di AKS. BYO CNI non rende supportata una configurazione che NAP elenca come non supportata, ad esempio kubenet o Calico. Quando si usa un CNI personalizzato, il supporto per la risoluzione dei problemi relativi alla rete non rientra nell'ambito di eventuali contratti o garanzie a livello di servizio.

Dettagli dell'ambito di supporto

Di seguito viene descritto che cos'è e non è supportato quando si usa BYO CNI con Karpenter:

• Supportato: funzionalità e problemi di integrazione specifici di Karpenter quando si utilizzano configurazioni CNI personalizzate (Bring Your Own - BYO).
• Non supportato: problemi di rete specifici di CNI, problemi di configurazione o risoluzione dei problemi quando si usano plug-in CNI di terze parti.

Passaggi successivi

Per altre informazioni sul provisioning automatico dei nodi in AKS (Azure Kubernetes Service), vedere gli articoli seguenti:

• Usare il provisioning automatico dei nodi in una rete virtuale personalizzata
• Configurare i pool di nodi per il provisioning automatico dei nodi su AKS
• Configurare i criteri di interruzione per il provisioning automatico dei nodi su AKS