Condividi tramite

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 Azure Kubernetes Service (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

Protezione accesso alla rete supporta le seguenti configurazioni di rete:

È consigliabile usare Azure CNI con Cilium. Cilium offre funzionalità di rete avanzate ed è ottimizzato per le prestazioni con Nap.

Configurazioni di rete non supportate per Protezione dell'accesso alla rete

NAP non supporta le seguenti configurazioni di rete:

  • Politica di rete Calico
  • Allocazione ip dinamica

Configurazioni delle sottoreti per NAP

NAP distribuisce, configura e gestisce automaticamente Karpenter sui tuoi cluster AKS ed è basato sui progetti open source Karpenter e AKS Karpenter provider. È possibile usare le risorse AKSNodeClass per specificare configurazioni di subnet personalizzate per i nodi NAP nei pool di nodi impostando il campo facoltativo vnetSubnetID e Karpenter usa una subnet specificata per il provisioning dei nodi. Se non si specifica una subnet, Karpenter usa la subnet predefinita configurata durante l'installazione di Karpenter. Questa subnet predefinita è in genere la stessa specificata durante la creazione del cluster AKS con il parametro --vnet-subnet-id nel comando az aks create.

Questo approccio consente di avere una combinazione di classi di nodi, con alcune subnet personalizzate per carichi di lavoro specifici e altre usando 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.

vnetSubnetID La modifica da una subnet valida a un'altra subnet valida non è un'operazione supportata. Se modifichi vnetSubnetID in modo che punti a una subnet valida diversa, Karpenter lo rileva come drift della subnet e impedisce il provisioning dei nodi fino a quando il problema non viene risolto mediante il ripristino di vnetSubnetID alla subnet originale. Questo comportamento garantisce che venga effettuato il provisioning dei nodi solo nelle subnet desiderate, mantenendo l'integrità della rete e la sicurezza. Tuttavia, esistono eccezioni a questa regola. È possibile modificare il vnetSubnetID solo negli scenari seguenti:

  • Correzione di un ID subnet non valido che impedisce il provisioning dei nodi.
  • Correzione di un riferimento subnet non valido che causa errori di configurazione.
  • Aggiornamento di un identificatore di subnet che punta a una subnet inesistente o inaccessibile.

Comprendere gli intervalli CIDR (Classless Inter-Domain Routing) del cluster AKS

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

Considerazioni sul CIDR per le configurazioni di subnet personalizzate

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:

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

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

Questo approccio è il più permissivo e concede le autorizzazioni di identità del cluster per leggere e aggiungere qualsiasi subnet all'interno della rete virtuale principale e fornisce l'accesso collaboratore alla rete.

Importante

Esaminare il ruolo "Collaboratore rete" prima di applicare questo approccio al cluster di produzione.

Vantaggi e considerazioni

La tabella seguente illustra i vantaggi e le considerazioni sull'assegnazione di autorizzazioni generali per la rete virtuale:

Vantaggi Considerazioni
• Semplifica la gestione delle autorizzazioni.
• Elimina la necessità di aggiornare le autorizzazioni quando si aggiungono nuove subnet.
• Funziona bene per gli ambienti a tenant singolo.
• Funzioni quando una sottoscrizione raggiunge il numero massimo di ruoli personalizzati.		 • Fornisce autorizzazioni più ampie rispetto a quelle strettamente necessarie.
• Potrebbe non soddisfare requisiti di sicurezza rigorosi.

Autorizzazioni necessarie

Per assegnare autorizzazioni generali per la rete virtuale, concedere all'identità gestita del cluster le autorizzazioni seguenti nella rete virtuale:

# 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

Per un esempio completo della configurazione della rete personalizzata e dell'assegnazione di autorizzazioni estese per la VNet, vedere la configurazione della VNET personalizzata - Script di esempio di Controllo degli accessi in base al ruolo più permissivo.

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:

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"

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/$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"

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

Karpenter per Azure consente di portare le proprie configurazioni Container Network Interface (BYO CNI), seguendo gli stessi criteri di supporto del servizio Azure Container. Ciò significa che quando si usa un CNI personalizzato, il supporto per la risoluzione dei problemi relativi alla rete non rientra nell'ambito di qualsiasi contratto di servizio o garanzia.

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:

  • Last updated on