Configurare funzionalità di rete di sovrimpressione di Azure CNI nel servizio Azure Kubernetes

  • Articolo

La tradizionale Azure Container Networking Interface (CNI) assegna un indirizzo IP di rete virtuale a ogni pod. Assegna questo indirizzo IP da un set preriservato di indirizzi IP in ogni nodo o una subnet separata riservata ai pod. Questo approccio richiede la pianificazione degli indirizzi IP e potrebbe causare l'esaurimento degli indirizzi, e ciò introduce difficoltà a ridimensionare i cluster man mano che le richieste dell'applicazione aumentano.

Con la sovrimpressione di Azure CNI, i nodi del cluster vengono distribuiti in una subnet di rete virtuale di Azure. Ai pod vengono assegnati indirizzi IP da un CIDR privato in un modo logico diverso dalla rete virtuale che ospita i nodi. Il traffico di pod e nodi all'interno del cluster usa una rete Overlay. Network Address Translation (NAT) usa l'indirizzo IP del nodo per raggiungere le risorse all'esterno del cluster. Questa soluzione consente di risparmiare una quantità significativa di indirizzi IP della rete virtuale e di ridimensionare il cluster in dimensioni elevate. Un vantaggio aggiuntivo è che è possibile riutilizzare il CIDR privato in diversi cluster del servizio Azure Kubernetes, che estende lo spazio IP disponibile per le applicazioni in contenitori nel servizio Azure Kubernetes.

Panoramica della rete di Overlay

In Rete di overlay, solo ai nodi del cluster Kubernetes vengono assegnati indirizzi IP dalle subnet. I pod ricevono indirizzi IP da un CIDR privato fornito al momento della creazione del cluster. A ogni nodo viene assegnato uno spazio indirizzi /24 ritagliato dallo stesso CIDR. Nodi aggiuntivi creati quando si aumenta il numero di istanze di un cluster ricevono automaticamente gli spazi indirizzi /24 dallo stesso CIDR. Azure CNI assegna indirizzi IP ai pod da questo spazio /24.

Nello stack di rete di Azure viene creato un dominio di routing separato per lo spazio CIDR privato del pod, che crea una rete Overlay per la comunicazione diretta tra i pod. Non è necessario effettuare il provisioning di route personalizzate nella subnet del cluster o usare un metodo di incapsulamento per eseguire il tunneling del traffico tra i pod, che offre prestazioni di connettività tra i pod alla pari con le macchine virtuali in una rete virtuale. I carichi di lavoro in esecuzione all'interno dei pod non sono nemmeno consapevoli che la manipolazione degli indirizzi di rete stia accadendo.

Diagramma che mostra due nodi con tre pod in esecuzione in una rete overlay. Il traffico dei pod verso endpoint esterni al cluster viene instradato tramite NAT.

La comunicazione con endpoint esterni al cluster, ad esempio reti virtuali locali e con peering, avviene usando l'IP del nodo tramite NAT. Azure CNI converte l'indirizzo IP di origine (IP Overlay del pod) del traffico all'indirizzo IP primario della macchina virtuale, che consente allo stack di rete di Azure di instradare il traffico alla destinazione. Gli endpoint esterni al cluster non possono connettersi direttamente a un pod. È necessario pubblicare l'applicazione del pod come servizio di bilanciamento del carico Kubernetes per renderla raggiungibile nella rete virtuale.

È possibile fornire connettività in uscita (egress) a Internet per i pod Overlay usando un servizio load balancer SKU Standard o un gateway NAT gestito. È anche possibile controllare il traffico in uscita indirizzandolo a un firewall usando route definite dall'utente nella subnet del cluster.

È possibile configurare la connettività in ingresso al cluster usando un controller di ingresso, ad esempio Nginx o il routing dell'applicazione HTTP. Non è possibile configurare la connettività in ingresso usando il gateway applicazione di Azure. Per informazioni dettagliate, vedere Limitazioni con Azure CNI Overlay.

Differenze tra Kubenet e Azure CNI Overlay

Analogamente ad Azure CNI Overlay, Kubenet assegna gli indirizzi IP ai pod da uno spazio indirizzi in un modo logico diverso dalla rete virtuale, ma ha scalabilità e altre limitazioni. La tabella seguente fornisce un confronto dettagliato tra Kubenet e Azure CNI Overlay. Se non si vogliono assegnare indirizzi IP di rete virtuale ai pod a causa della carenza di indirizzi IP, è consigliabile usare Azure CNI Overlay.

Area Sovrimpressione di Azure CNI Kubenet
Scalabilità del cluster 5000 nodi e 250 pod/nodo 400 nodi e 250 pod/nodo
Configurazione di rete Semplice: non sono necessarie configurazioni aggiuntive per la rete dei pod Complesso: richiede tabelle di route e route definite dall'utente nella subnet del cluster per la rete dei pod
Prestazioni della connettività dei pod Prestazioni in parità con le macchine virtuali in una rete virtuale L'hop aggiuntivo aggiunge latenza
Criteri di rete di Kubernetes Criteri di rete di Azure, Calico, Cilium Calico
Piattaforme del sistema operativo supportate Linux e Windows Server 2022, 2019 Solo Linux

Pianificazione degli indirizzi IP

  • Nodi del cluster: quando si configura il cluster del servizio Azure Kubernetes, assicurarsi che le subnet della rete virtuale abbiano spazio sufficiente per aumentare per il ridimensionamento futuro. È possibile assegnare ogni pool di nodi a una subnet dedicata. Una /24subnet può contenere fino a 251 nodi poiché i primi tre indirizzi IP sono riservati per le attività di gestione.
  • Pod: la soluzione Overlay assegna uno spazio indirizzi /24 per i pod in ogni nodo dal CIDR privato specificato durante la creazione del cluster. La dimensione /24 è fissa e non può essere aumentata o ridotta. È possibile eseguire fino a 250 pod in un nodo. Quando si pianifica lo spazio indirizzi del pod, assicurarsi che il CIDR privato sia sufficientemente grande da fornire spazi di indirizzi /24 per i nuovi nodi per supportare l'espansione futura del cluster.
    • Quando si pianifica lo spazio degli indirizzi IP per i pod, considerare i fattori seguenti:
      • Lo stesso spazio CIDR dei pod può essere usato in più cluster del servizio Azure Kubernetes indipendenti nella stessa rete virtuale.
      • Lo spazio CIDR dei pod non deve sovrapporsi all'intervallo di subnet del cluster.
      • Lo spazio CIDR dei pod non deve sovrapporsi alle reti connesse direttamente (ad esempio peering reti virtuali, ExpressRoute o VPN). Se il traffico esterno ha indirizzi IP di origine nell'intervallo podCIDR, deve eseguire la conversione in un indirizzo IP non sovrapposto tramite SNAT per comunicare con il cluster.
  • Intervallo di indirizzi del servizio Kubernetes: le dimensioni del CIDR dell'indirizzo del servizio dipendono dal numero di servizi cluster che si intende creare. Deve essere minore di /12. Questo intervallo non deve sovrapporsi all'intervallo CIDR del pod, all'intervallo di subnet del cluster e all'intervallo IP usato nelle reti virtuali con peering e nelle reti locali.
  • Indirizzo IP del servizio DNS Kubernetes: questo indirizzo IP si trova all'interno dell'intervallo di indirizzi del servizio Kubernetes usato dall'individuazione del servizio cluster. Non usare il primo indirizzo IP nell'intervallo di indirizzi, perché questo viene usato per l'indirizzo kubernetes.default.svc.cluster.local.

Gruppi di sicurezza di rete

Il traffico da pod a pod con Azure CNI Overlay non è incapsulato e vengono applicate le regole del gruppo di sicurezza di rete della subnet. Se il gruppo di sicurezza di rete della subnet contiene regole di negazione che influiscono sul traffico CIDR del pod, assicurarsi che siano presenti le regole seguenti per garantire la funzionalità del cluster appropriata (oltre a tutti i requisiti in uscita del servizio Azure Kubernetes):

  • Traffico dal CIDR del nodo al CIDR del nodo su tutte le porte e protocolli
  • Traffico dal CIDR del nodo al CIDR del pod su tutte le porte e i protocolli (necessario per il routing del traffico del servizio)
  • Traffico dal CIDR del pod al CIDR del pod su tutte le porte e i protocolli (necessario per il traffico da pod a pod e da pod a server, tra cui DNS)

Il traffico da un pod a qualsiasi destinazione all'esterno del blocco CIDR del pod usa SNAT per impostare l'IP di origine sull'IP del nodo in cui viene eseguito il pod.

Se si vuole limitare il traffico tra carichi di lavoro nel cluster, è consigliabile usare i criteri di rete.

Numero massimo di pod per nodo

È possibile configurare il numero massimo di pod per nodo al momento della creazione del cluster o quando si aggiunge un nuovo pool di nodi. Il valore predefinito per Azure CNI Overlay è 250. Il valore massimo che è possibile specificare in Azure CNI Overlay è 250 e il valore minimo è 10. Il valore massimo di pod per nodo configurati durante la creazione di un pool di nodi si applica solo ai nodi nel pool di nodi.

Scelta di un modello di rete da usare

Azure CNI offre due opzioni di indirizzi IP per i pod: la configurazione tradizionale che assegna IP di rete virtuale ai pod e alla rete Overlay. La scelta dell’opzione da usare per il cluster del servizio Azure Kubernetes è un compromesso tra le esigenze di flessibilità e di configurazione avanzata. Le considerazioni seguenti sono utili per stabilire quando ogni modello di rete può essere il più appropriato.

Usare la rete Overlay quando:

  • Si vuole ridimensionare fino a un numero elevato di pod, ma è disponibile uno spazio di indirizzi IP limitato nella rete virtuale.
  • La maggior parte delle comunicazioni dei pod avviene all'interno del cluster.
  • Non sono necessarie funzionalità avanzate del servizio Azure Kubernetes, ad esempio nodi virtuali.

Usare l'opzione di rete virtuale tradizionale quando:

  • È disponibile uno spazio indirizzi IP adeguato.
  • La maggior parte delle comunicazioni dei pod avviene con risorse esterne al cluster.
  • Le risorse esterne al cluster devono raggiungere direttamente i pod.
  • Sono necessarie funzionalità avanzate del servizio Azure Kubernetes, come i nodi virtuali.

Limitazioni con Azure CNI Overlay

Azure CNI Overlay presenta le limitazioni seguenti:

  • Non è possibile usare il gateway applicazione come controller in ingresso (AGIC) per un cluster Overlay.
  • I set di disponibilità delle macchine virtuali (VMAS) non sono supportati per Overlay.
  • Non è possibile usare macchine virtuali serie DCsv2 nei pool di nodi. Per soddisfare i requisiti di Confidential Computing, prendere in considerazione l'uso di macchine virtuali riservate serie DCasv5 o DCadsv5.
  • Se si usa la propria subnet per distribuire il cluster, i nomi della subnet, della rete virtuale e del gruppo di risorse che contiene la rete virtuale devono essere di almeno 63 caratteri. Questo deriva dal fatto che questi nomi verranno usati come etichette nei nodi del ruolo di lavoro del servizio Azure Kubernetes e sono quindi soggetti alle regole di sintassi delle etichette kubernetes.

Configurare i cluster Overlay

Nota

È necessario avere l'interfaccia della riga di comando versione 2.48.0 o successiva per usare l’argomento --network-plugin-mode. Per Windows, è necessario aver installato l'estensione dell'interfaccia della riga di comando di Azure aks-preview più recente e seguire le istruzioni seguenti.

Creare un cluster con Azure CNI Overlay usando il comando az aks create. Assicurarsi di usare l'argomento --network-plugin-mode per specificare un cluster Overlay. Se il CIDR del pod non è specificato, il servizio Azure Kubernetes assegna uno spazio predefinito: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

Aggiungere un nuovo pool di nodi a una subnet dedicata

Dopo aver creato un cluster con Azure CNI Overlay, è possibile creare un altro pool di nodi e assegnare i nodi a una nuova subnet della stessa rete virtuale. Questo approccio può essere utile se si desidera controllare gli indirizzi IP in ingresso o in uscita dell'host da/verso destinazioni nella stessa rete virtuale o reti virtuali con peering.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Aggiornare un cluster esistente a CNI Overlay

Nota

È possibile aggiornare un cluster Azure CNI esistente in Overlay se il cluster soddisfa i criteri seguenti:

  • Il cluster si trova in Kubernetes versione 1.22+.
  • Non usa la funzionalità di allocazione IP pod dinamica.
  • Non sono abilitati i criteri di rete. Il motore dei criteri di rete può essere disinstallato prima dell'aggiornamento, vedere Disinstallare Gestione criteri di rete di Azure o Calico
  • Non usa pool di nodi Windows con Docker come runtime del contenitore.

Nota

Poiché il dominio di routing non è ancora supportato per ARM, CNI Overlay non è ancora supportata nei nodi del processore basato su ARM (ARM64).

Nota

L'aggiornamento di un cluster esistente alla sovrimpressione CNI è un processo non reversibile.

Avviso

Prima della build del sistema operativo Windows 20348.1668, esisteva una limitazione per i pod Overlay di Windows che presentava in modo errato SNAT di pacchetti dai pod di rete host, che avevano un effetto più dannoso per l'aggiornamento dei cluster in Overlay. Per evitare questo problema, usare una build del sistema operativo Windows maggiore o uguale a 20348.1668.

Avviso

Se si usa una configurazione personalizzata di azure-ip-masq-agent per includere intervalli IP aggiuntivi che non devono essere pacchetti SNAT dai pod, l'aggiornamento ad Azure CNI Overlay può interrompere la connettività a questi intervalli. Gli indirizzi IP dei pod dallo spazio di sovrimpressione non saranno raggiungibili da alcun elemento all'esterno dei nodi del cluster. Inoltre, per i cluster sufficientemente vecchi potrebbe esserci un oggetto ConfigMap lasciato da una versione precedente di azure-ip-masq-agent. Se ConfigMap, denominato azure-ip-masq-agent-config, esiste e non è intenzionalmente sul posto, deve essere eliminato prima di eseguire il comando di aggiornamento. Se non si usa una configurazione personalizzata di ip-masq-agent, durante il processo di aggiornamento dovrebbe esistere solo ConfigMap azure-ip-masq-agent-config-reconciled di Azure ip-masq-agent ConfigMap. Questa operazione verrà aggiornata automaticamente durante il processo di aggiornamento.

Il processo di aggiornamento attiva la ricreazione simultanea di ogni pool di nodi. L'aggiornamento di ogni pool di nodi separatamente in Overlay non è supportato. Eventuali interruzioni della rete del cluster sono simili a un aggiornamento dell'immagine del nodo o all'aggiornamento della versione di Kubernetes in cui per ogni nodo in un pool di nodi viene ricreata l'immagine.

Aggiornamento del cluster Azure CNI

Aggiornare un cluster Azure CNI esistente per usare Overlay con il comando az aks update.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Il parametro --pod-cidr è necessario quando si esegue l'aggiornamento da CNI legacy perché i pod devono ottenere indirizzi IP da un nuovo spazio di sovrimpressione, che non si sovrappone alla subnet del nodo esistente. Il CIDR del pod non può sovrapporsi neanche ad alcun indirizzo di rete virtuale dei pool di nodi. Ad esempio, se l'indirizzo della rete virtuale è 10.0.0.0/8 e i nodi si trovano nella subnet 10.240.0.0/16, --pod-cidr non può sovrapporsi a 10.0.0.0/8 o al CIDR del servizio esistente nel cluster.

Aggiornamento del cluster Kubenet

Aggiornare un cluster Kubenet esistente per usare Azure CNI Overlay usando il comando az aks update.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Poiché il cluster usa già un CIDR privato per i pod che non si sovrappone allo spazio IP della rete virtuale, non è necessario specificare il parametro --pod-cidr e il CIDR pod rimarrà invariato.

Nota

Quando si esegue l'aggiornamento da Kubenet a CNI Overlay, la tabella di route non sarà più necessaria per il routing dei pod. Se il cluster usa una tabella di route fornita dal cliente, le route usate per indirizzare il traffico dei pod al nodo corretto verranno eliminate automaticamente durante l'operazione di migrazione. Se il cluster usa una tabella di route gestita (la tabella di route è stata creata dal servizio Azure Kubernetes e risiede nel gruppo di risorse del nodo), tale tabella di route verrà eliminata come parte della migrazione.

Rete a doppio stack

È possibile distribuire i cluster del servizio Azure Kubernetes in modalità dual stack quando si usano la rete sovrapposta e una rete virtuale di Azure dual stack. In questa configurazione, i nodi ricevono sia un indirizzo IPv4 che IPv6 dalla subnet della rete virtuale di Azure. I pod ricevono un indirizzo IPv4 e IPv6 da uno spazio di indirizzi logicamente diverso dalla subnet della rete virtuale Azure dei nodi. Viene poi configurato il protocollo NAT (Network Address Translation) in modo che i pod possano raggiungere le risorse nella rete virtuale di Azure. L'indirizzo IP di origine del traffico è NAT verso l'indirizzo IP primario del nodo della stessa famiglia (da IPv4 a IPv4 e IPv6 a IPv6).

Prerequisiti

  • È necessario avere installata l'interfaccia della riga di comando di Azure 2.48.0 o versione successiva.
  • Kubernetes versione 1.26.3 o successiva.

Limiti

Le funzionalità seguenti non sono supportate con la rete dual stack:

  • Pool di nodi di Windows
  • Criteri di rete di Azure
  • Criteri di rete Calico
  • Gateway NAT
  • Componente aggiuntivo nodi virtuali

Distribuire un cluster servizio Azure Kubernetes dual stack

Per supportare cluster dual stack, vengono forniti gli attributi seguenti:

  • --ip-families: accetta un elenco delimitato da virgole di famiglie IP da abilitare nel cluster.
    • Sono supportati solo ipv4 o ipv4,ipv6.
  • --pod-cidrs: accetta un elenco delimitato da virgole di intervalli IP di notazione CIDR da cui assegnare indirizzi IP pod.
    • Il conteggio e l'ordine degli intervalli in questo elenco devono corrispondere al valore fornito a --ip-families.
    • Se non viene specificato alcun valore, viene utilizzato il valore 10.244.0.0/16,fd12:3456:789a::/64 predefinito.
  • --service-cidrs: accetta un elenco delimitato da virgole di intervalli IP di notazione CIDR da cui assegnare gli INDIRIZZI IP del servizio.
    • Il conteggio e l'ordine degli intervalli in questo elenco devono corrispondere al valore fornito a --ip-families.
    • Se non viene specificato alcun valore, viene utilizzato il valore 10.0.0.0/16,fd12:3456:789a:1::/108 predefinito.
    • La subnet IPv6 assegnata a --service-cidrs non può essere maggiore di /108.

Creare un cluster del servizio Azure Kubernetes dual stack

  1. Creare un gruppo di risorse Azure per il cluster usando il comando [az group create][az-group-create].

    az group create -l <region> -n <resourceGroupName>

  2. Creare un cluster servizio Azure Kubernetes dual stack usando il comando az aks create con il parametro --ip-families impostato su ipv4,ipv6.

    az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

Creare un carico di lavoro di esempio

Dopo aver creato il cluster, è possibile distribuire i carichi di lavoro. Questo articolo illustra la distribuzione di un carico di lavoro di esempio di un server Web NGINX.

Distribuire un server Web NGINX

Il componente aggiuntivo di routing dell'applicazione è il modo consigliato per l'ingresso in un cluster del servizio Azure Kubernetes. Per altre informazioni sul componente aggiuntivo di routing dell'applicazione e per un esempio di distribuzione di un'applicazione con il componente aggiuntivo, vedere Ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione.

Esporre il carico di lavoro tramite un servizio di tipo LoadBalancer

Importante

Esistono attualmente due limitazioni relative ai servizi IPv6 nel servizio Azure Kubernetes.

  • Azure Load Balancer invia probe di integrità alle destinazioni IPv6 da un indirizzo locale di collegamento. Nei pool di nodi Linux di Azure, questo traffico non può essere instradato a un pod, quindi il traffico passa ai servizi IPv6 distribuiti con esito negativo externalTrafficPolicy: Cluster. I servizi IPv6 devono essere distribuiti con externalTrafficPolicy: Local, per cui kube-proxy risponde al probe nel nodo.
  • Prima della versione Kubernetes 1.27, viene effettuato il provisioning solo del primo indirizzo IP per un servizio nel servizio di bilanciamento del carico, quindi un servizio dual stack riceve solo un indirizzo IP pubblico per la famiglia di IP elencata per la prima volta. Per fornire un servizio dual stack per una singola distribuzione, creare due servizi destinati allo stesso selettore, uno per IPv4 e uno per IPv6. Questa non è più una limitazione in Kubernetes 1.27 o versione successiva.

  1. Esporre la distribuzione NGINX usando il comando kubectl expose deployment nginx.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Si riceve un output che mostra che i servizi sono stati esposti.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. Una volta che la distribuzione è stata esposta e i LoadBalancerservizi sono stati completamente forniti, ottenere gli indirizzi IP dei servizi usando il comando kubectl get services.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Verificare la funzionalità tramite una richiesta Web da riga di comando da un host che supporta IPv6. Azure Cloud Shell non è in grado di supportare IPv6.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

Passaggi successivi

Per informazioni su come usare il servizio Azure Kubernetes con il plug-in CNI (Container Network Interface), vedere Usare il proprio plug-in Container Network Interface (CNI).