Configurare la rete CNI di Azure per l'allocazione dinamica di indirizzi IP e il supporto avanzato della subnet nel servizio Azure Kubernetes

Articolo
02/03/2024

Uno svantaggio con l'interfaccia CNI tradizionale è l'esaurimento degli indirizzi IP del pod man mano che il cluster del servizio Azure Kubernetes aumenta, il che comporta la necessità di ricompilare l'intero cluster in una subnet più grande. La nuova funzionalità di allocazione IP dinamica in Azure CNI risolve questo problema allocando indirizzi IP pod da una subnet separata dalla subnet che ospita il cluster del servizio Azure Kubernetes.

I vantaggi offerti sono i seguenti:

Migliore utilizzo IP: gli indirizzi IP vengono allocati dinamicamente ai pod del cluster dalla subnet Pod. Ciò comporta un migliore utilizzo degli indirizzi IP nel cluster rispetto alla soluzione CNI tradizionale, che esegue l'allocazione statica degli indirizzi IP per ogni nodo.
Scalabile e flessibile: le subnet dei nodi e dei pod possono essere scalate 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. La soluzione supporta cluster molto grandi senza alcuna riduzione delle prestazioni.
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: sia i criteri di rete di Azure che Calico funzionano con questa nuova soluzione.

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

Prerequisiti

Nota

Quando si usa l'allocazione dinamica di indirizzi IP, l'esposizione di un'applicazione come servizio di 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.
Interfaccia della riga di comando di Azure 2.37.0 o versione 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 comando az aks enable-addons, come illustrato nell'esempio seguente:
```
az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
```

pianificare l'indirizzamento IP

La pianificazione dell'indirizzamento IP è molto più semplice con questa funzionalità. 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.

Gli indirizzi IP vengono allocati ai nodi in batch di 16. L'allocazione degli IP della subnet pod deve essere pianificata con un minimo di 16 IP per ogni nodo del cluster; i nodi richiederanno 16 IP all'avvio e richiederanno un altro gruppo di 16 ogni volta che ci sono <8 IP non allocati nella loro allocazione.

La pianificazione degli indirizzi IP per i servizi Kubernetes e il bridge Docker rimangono invariati.

Numero massimo di pod per nodo in un cluster con allocazione dinamica di indirizzi IP e supporto della subnet avanzata

I pod per nodo valori quando si usa Azure CNI con allocazione dinamica di indirizzi IP differiscono leggermente dal comportamento CNI tradizionale:

CNI	Default	Configurabile in fase di distribuzione
CNI di Azure tradizionale	30	Sì (fino a 250)
Azure CNI con allocazione dinamica di indirizzi IP	250	Sì (fino a 250)

Tutte le altre indicazioni relative alla configurazione dei pod massimi per nodo rimangono invariate.

Parametri di distribuzione

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

Il parametro subnet ora fa riferimento alla subnet correlata ai nodi del cluster.
Viene usata una subnet pod di parametro aggiuntiva per specificare la subnet i cui indirizzi IP verranno allocati dinamicamente ai pod.

Configurare la rete con allocazione dinamica di indirizzi IP e supporto avanzato per le subnet - Interfaccia della riga di comando di Azure

L'uso dell'allocazione dinamica degli indirizzi IP e del supporto avanzato della subnet nel cluster è simile al metodo predefinito per la configurazione di un cluster CNI di Azure. L'esempio seguente illustra 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 dinamica di indirizzi IP e supporto avanzato della subnet. Assicurarsi di sostituire variabili come $subscription con i propri valori.

Creare la rete virtuale con due subnet.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="westcentralus"

# 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.241.0.0/16 -o none

Creare il cluster, facendo riferimento alla subnet del nodo usando --vnet-subnet-id e la subnet del pod usando --pod-subnet-id e abilitando 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 \
    --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

Aggiunta del pool di nodi

Quando si aggiunge un pool di nodi, fare riferimento alla subnet del nodo usando --vnet-subnet-id e la subnet del pod usando --pod-subnet-id. 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 \
    --no-wait

Monitorare l'utilizzo della subnet IP

Azure CNI offre la possibilità di monitorare l'utilizzo della subnet IP. Per abilitare il monitoraggio dell'utilizzo della subnet IP, seguire questa procedura:

Ottenere il file YAML

Scaricare o grep il file denominato container-azm-ms-agentconfig.yaml da GitHub.
Trovare azure_subnet_ip_usage nelle integrazioni. Impostare enabled su true.
Salvare il file.

Ottenere le credenziali del servizio Azure Kubernetes

Impostare le variabili per sottoscrizione, gruppo di risorse e cluster. Si considerino gli esempi seguenti:


    $s="subscriptionId"

    $rg="resourceGroup"

    $c="ClusterName"

    az account set -s $s

    az aks get-credentials -n $c -g $rg

Applicare la configurazione

Aprire il terminale nella cartella in cui è stato scaricato il file container-azm-ms-agentconfig.yaml.
Prima di tutto, applicare la configurazione usando il comando: kubectl apply -f container-azm-ms-agentconfig.yaml
Il pod verrà riavviato e dopo 5-10 minuti le metriche saranno visibili.
Per visualizzare le metriche nel cluster, passare a Cartelle di lavoro nella pagina del cluster nel portale di Azure e trovare la cartella di lavoro denominata “Utilizzo IP subnet". La visualizzazione sarà simile alla seguente:

Domande frequenti sull'allocazione dinamica di indirizzi IP e subnet avanzate

È possibile assegnare più subnet pod a un pool di cluster/nodi?

È possibile assegnare una sola subnet a un cluster o a un pool di nodi. Tuttavia, più cluster o pool di nodi possono condividere una singola 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 il CNI tradizionale, mentre altri usano la nuova CNI?

L'intero cluster deve usare un solo tipo di CNI.

Passaggi successivi

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