Share via

Configurare la rete CNI di Azure per l'allocazione statica dei blocchi CIDR e il supporto avanzato delle subnet in servizio Azure Kubernetes (servizio Azure Kubernetes) - (anteprima)

  • Articolo

Una limitazione dell'allocazione ip dinamica di Azure CNI è la scalabilità delle dimensioni della subnet del pod oltre una subnet /16. Anche con una subnet di grandi dimensioni, i cluster di grandi dimensioni possono comunque essere limitati a 65.000 pod a causa di un limite di mapping degli indirizzi di Azure. La nuova funzionalità di allocazione dei blocchi statici in Azure CNI risolve questo problema assegnando blocchi CIDR ai nodi anziché ai singoli indirizzi IP.

I vantaggi offerti sono i seguenti:

  • Migliore scalabilità IP: i blocchi CIDR vengono allocati staticamente ai nodi del cluster e sono presenti per la durata del nodo, anziché l'allocazione dinamica tradizionale di singoli indirizzi IP con CNI tradizionale. Ciò consente il routing basato su blocchi CIDR e consente di ridimensionare il limite del cluster fino a 1 milione di pod dai tradizionali pod da 65.000 per cluster. L'Rete virtuale di Azure deve essere sufficientemente grande per supportare la scalabilità del cluster.
  • Flessibilità: le subnet nodo e pod possono essere ridimensionate in modo indipendente. Una singola subnet pod può essere condivisa tra più pool di nodi di un cluster o tra più cluster del servizio Azure Kubernetes distribuiti nella stessa rete virtuale. È anche possibile configurare una subnet pod separata per un pool di nodi.
  • Prestazioni elevate: poiché ai pod vengono assegnati indirizzi IP di rete virtuale, hanno connettività diretta ad altri pod e risorse del cluster nella rete virtuale.
  • Criteri di rete virtuale separati per i pod: poiché i pod hanno una subnet separata, è possibile configurare criteri di rete virtuale separati per essi diversi dai criteri dei nodi. Ciò consente molti scenari utili, ad esempio consentire la connettività Internet solo per i pod e non per i nodi, correggere l'indirizzo IP di origine per il pod in un pool di nodi usando un gateway NAT di Azure e usare gruppi di sicurezza di rete per filtrare il traffico tra pool di nodi.
  • Criteri di rete Kubernetes: Cilium, NPM di Azure e Calico funzionano con questa nuova soluzione.

Questo articolo illustra come usare la rete CNI di Azure per l'allocazione statica di CIDR e il supporto avanzato delle subnet nel servizio Azure Kubernetes.

Prerequisiti

Nota

Quando si usa l'allocazione statica di blocchi di CIDR, l'esposizione di un'applicazione come servizio collegamento privato tramite un servizio di bilanciamento del carico Kubernetes non è supportata.

  • Esaminare i prerequisiti per la configurazione della rete CNI di Azure di base nel servizio Azure Kubernetes, perché gli stessi prerequisiti si applicano a questo articolo.

  • Esaminare i parametri di distribuzione per configurare la rete CNI di Azure di base nel servizio Azure Kubernetes, come si applicano gli stessi parametri.

  • Il motore del servizio Azure Kubernetes e i cluster DIY non sono supportati.

  • Versione 2.37.0 dell'interfaccia della riga di comando di Azure o successiva con estensione aks-preview della versione '2.0.0b2' o successiva

  • Se si dispone di un cluster esistente, è necessario abilitare Container Insights per il monitoraggio dell'utilizzo della subnet IP. È possibile abilitare Container Insights usando il az aks enable-addons comando , come illustrato nell'esempio seguente:

  • Registrare il flag di funzionalità a livello di sottoscrizione per la sottoscrizione: 'Microsoft.ContainerService/AzureVnetScalePreview'

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

Limiti

Di seguito sono riportate alcune delle limitazioni dell'uso dell'allocazione di blocchi statici di Azure CNI:

  • La versione minima di Kubernetes necessaria è la 1.28
  • Le dimensioni massime della subnet supportate sono x.x.x.x/12 ~ 1 milione di INDIRIZZI IP
  • Non supportato per i pool di nodi Windows (il supporto di Windows sarà presto disponibile)
  • Non supportato per il piano dati Cilium (il supporto sarà presto disponibile)
  • È possibile usare solo una sola modalità di funzionamento per subnet. Se una subnet usa la modalità di allocazione blocco statico, non può essere usata la modalità di allocazione IP dinamica in un cluster o un pool di nodi diverso con la stessa subnet e viceversa.
  • Supportato solo nei nuovi cluster o quando si aggiungono pool di nodi con una subnet diversa ai cluster esistenti. La migrazione o l'aggiornamento di cluster o pool di nodi esistenti non è supportata.
  • In tutti i blocchi CIDR assegnati a un nodo nel pool di nodi, un IP verrà selezionato come INDIRIZZO IP primario del nodo. Pertanto, per gli amministratori di rete che selezionano il --max-pods valore provare a usare il calcolo seguente per soddisfare al meglio le esigenze e avere un utilizzo ottimale degli indirizzi IP nella subnet:
    max_pods = (N * 16) - 1' dove N è un numero intero positivo e N > 0

Aree di disponibilità

Questa funzionalità non è disponibile nelle aree seguenti:

  • Stati Uniti meridionali
  • Stati Uniti orientali 2
  • Stati Uniti occidentali
  • West US 2

pianificare l'indirizzamento IP

La pianificazione dell'indirizzamento IP è più flessibile e granulare. Poiché i nodi e i pod vengono ridimensionati in modo indipendente, gli spazi indirizzi possono anche essere pianificati separatamente. Poiché le subnet dei pod possono essere configurate in base alla granularità di un pool di nodi, è sempre possibile aggiungere una nuova subnet quando si aggiunge un pool di nodi. I pod di sistema in un pool di cluster/nodi ricevono anche indirizzi IP dalla subnet del pod, quindi questo comportamento deve essere tenuto in considerazione.

In questo scenario, i blocchi CIDR di /28 (16 IP) vengono allocati ai nodi in base alla configurazione "--max-pod" per il pool di nodi che definisce il numero massimo di pod per nodo. 1 IP è riservato in ogni nodo da tutti gli INDIRIZZI IP disponibili in tale nodo per scopi interni.

Pertanto, durante la determinazione e la pianificazione degli indirizzi IP, è essenziale definire la configurazione "--max-pods" e può essere calcolata meglio come indicato di seguito: max_pods_per_node = (16 * N) - 1 dove N è un numero intero positivo maggiore di 0

I valori ideali senza wastag IP richiedono che il valore max pods sia conforme all'espressione precedente.

Esempio 1: max_pods = 30, blocchi CIDR allocati per nodo = 2, IP totali disponibili per i pod = (16 * 2) - 1 = 32 - 1 = 31, IP wastage per nodo = 31 - 30 = 1 [Wastage basso - Caso accettabile]Esempio 2: max_pods = 31, blocchi CIDR allocati per nodo = 2, IP totali disponibili per i pod = (16 * 2) - 1 = 32 - 1 = 31, wastag IP per nodo = 31 - 31 = 31 = 0 [Caso ideale]Esempio 3: max_pods = 32, blocchi CIDR allocati per nodo = 3, IP totali disponibili per i pod = (16 * 3) - 1 = 48 - 1 = 47, wastag IP per nodo = 47 - 32 = 15 [Wastage elevato - Non consigliato]

La pianificazione degli indirizzi IP per i servizi Kubernetes rimane invariata.

Nota

Verificare che la rete virtuale disponga di uno spazio indirizzi sufficientemente grande e contiguo per supportare la scalabilità del cluster.

Parametri di distribuzione

I parametridi distribuzione per la configurazione della rete CNI di Azure di base nel servizio Azure Kubernetes sono tutti validi, con due eccezioni:

  • Il parametro id subnet della rete virtuale fa ora riferimento alla subnet correlata ai nodi del cluster.
  • L'ID subnet del pod del parametro viene usato per specificare la subnet i cui indirizzi IP verranno allocati in modo statico o dinamico ai pod nel pool di nodi.
  • Il parametro della modalità di allocazione ip pod specifica se usare l'allocazione dinamica di blocchi singoli o statici.

Operazioni preliminari

  • Se si usa l'interfaccia della riga di comando di Azure, è necessaria l'estensione aks-preview . Vedere Installare l'estensione dell'interfaccia della aks-preview riga di comando di Azure.
  • Se si usa ARM o l'API REST, la versione dell'API del servizio Azure Kubernetes deve essere 2024-01-02-preview o successiva.

Installare l'estensione aks-preview dell'interfaccia della riga di comando di Azure.

  1. Installare l'estensione aks-preview usando il comando [az extension add][az-extension-add].

    az extension add --name aks-preview

  2. Eseguire l'aggiornamento alla versione più recente dell'estensione usando il comando [az extension update][az-extension-update]. L'estensione deve avere una versione di '2.0..0b2' o successiva

    az extension update --name aks-preview

Registrare il flag di funzionalità AzureVnetScalePreview

  1. Registrare il flag di AzureVnetScalePreview funzionalità usando il comando [az feature register][az-feature-register].

    az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

    Sono necessari alcuni minuti per visualizzare lo stato Registered.

  2. Verificare lo stato della registrazione usando il comando [az feature show][az-feature-show].

    az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

  3. Quando lo stato riflette Registered, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando [az provider register][az-provider-register].

    az provider register --namespace Microsoft.ContainerService

Configurare la rete con allocazione statica di blocchi CIDR e supporto avanzato della subnet - Interfaccia della riga di comando di Azure

L'uso dell'allocazione statica dei blocchi CIDR nel cluster è simile al metodo predefinito per la configurazione di un cluster CNI di Azure per l'allocazione ip dinamica. Nell'esempio seguente viene illustrata la creazione di una nuova rete virtuale con una subnet per i nodi e una subnet per i pod e la creazione di un cluster che usa Azure CNI con allocazione statica di blocchi CIDR. Assicurarsi di sostituire variabili come $subscription con i valori.

Creare la rete virtuale con due subnet.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create -resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none

Creare il cluster, facendo riferimento alla subnet del nodo usando , la subnet del pod usando --vnet-subnet-id--pod-subnet-id, per --pod-ip-allocation-mode definire la modalità di allocazione ip e abilitare il componente aggiuntivo di monitoraggio.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create --name $clusterName --resource-group $resourceGroup --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --kubernetes-version 1.28

Aggiunta del pool di nodi

Quando si aggiunge un pool di nodi, fare riferimento alla subnet del nodo usando --vnet-subnet-id, la subnet del pod usando --pod-subnet-id e la modalità di allocazione usando '--pod-ip-allocation-mode'. Nell'esempio seguente vengono create due nuove subnet a cui viene quindi fatto riferimento nella creazione di un nuovo pool di nodi:

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Domande frequenti sull'allocazione statica dei blocchi CIDR e delle subnet avanzate

  • È possibile assegnare più subnet pod a un cluster?

    È possibile assegnare più subnet a un cluster, ma è possibile assegnare a ogni pool di nodi una sola subnet. Pool di nodi diversi nello stesso cluster o in un cluster diverso possono condividere la stessa subnet.

  • È possibile assegnare completamente subnet pod da una rete virtuale diversa?

    No, la subnet del pod deve trovarsi dalla stessa rete virtuale del cluster.

  • Alcuni pool di nodi in un cluster possono usare l'allocazione IP dinamica mentre altri usano la nuova allocazione di blocchi statici?

Sì, pool di nodi diversi possono usare modalità di allocazione diverse. Tuttavia, una volta usata una subnet in una modalità di allocazione, può essere usata solo nella stessa modalità di allocazione in tutti i pool di nodi a cui è associata.

Passaggi successivi

Per altre informazioni sulla rete in servizio Azure Kubernetes, vedere gli articoli seguenti: