Requisiti di pianificazione degli indirizzi IP
Si applica a: Locale di Azure, versione 23H2
La pianificazione degli indirizzi IP per il servizio Azure Kubernetes abilitata da Azure Arc prevede la progettazione di una rete che supporta applicazioni, pool di nodi, reti pod, comunicazione del servizio e accesso esterno. Questo articolo illustra alcune considerazioni chiave per la pianificazione efficace degli indirizzi IP e il numero minimo di indirizzi IP necessari per distribuire il servizio Azure Kubernetes nell'ambiente di produzione. Prima di leggere questo articolo, vedere i concetti e i requisiti di rete del servizio Azure Kubernetes.
Pianificazione di indirizzi IP semplici per cluster e applicazioni Kubernetes
Nello scenario seguente si riservano indirizzi IP da una singola rete per i cluster e i servizi Kubernetes. Questo esempio è lo scenario più semplice e semplice per l'assegnazione di indirizzi IP.
Requisito dell'indirizzo IP | Numero minimo di indirizzi IP | Come e dove effettuare questa prenotazione |
---|---|---|
Indirizzi IP delle macchine virtuali Arc del servizio Azure Kubernetes | Riservare un indirizzo IP per ogni nodo di lavoro nel cluster Kubernetes. Ad esempio, se si vogliono creare 3 pool di nodi con 3 nodi in ogni pool di nodi, sono necessari 9 indirizzi IP nel pool DI INDIRIZZI IP. | Riservare gli indirizzi IP tramite pool IP nella rete logica arc VM. |
Indirizzi IP di aggiornamento della versione di Arc K8s del servizio Azure Kubernetes | Poiché AKS Arc esegue aggiornamenti in sequenza, riservare un indirizzo IP per ogni cluster Arc del servizio Azure Kubernetes per le operazioni di aggiornamento della versione di Kubernetes. | Riservare gli indirizzi IP tramite pool IP nella rete logica arc VM. |
IP del piano di controllo | Riservare un indirizzo IP per ogni cluster Kubernetes nell'ambiente. Ad esempio, se si vogliono creare 5 cluster in totale, riservare 5 indirizzi IP, uno per ogni cluster Kubernetes. | Riservare gli indirizzi IP tramite pool IP nella rete logica arc VM. |
Indirizzi IP del servizio di bilanciamento del carico | Il numero di indirizzi IP riservati dipende dal modello di distribuzione dell'applicazione. Come punto di partenza, è possibile riservare un indirizzo IP per ogni servizio Kubernetes. | Riservare gli indirizzi IP nella stessa subnet della rete logica Arc VM, ma all'esterno del pool IP. |
Procedura dettagliata di esempio per la prenotazione di indirizzi IP per cluster e applicazioni Kubernetes
Jane è un amministratore IT che inizia con il servizio Azure Kubernetes abilitato da Azure Arc. Jane vuole distribuire due cluster Kubernetes: cluster Kubernetes A e cluster Kubernetes B nel cluster locale di Azure. Jane vuole anche eseguire un'applicazione di voto sopra il cluster A. Questa applicazione ha tre istanze dell'interfaccia utente front-end in esecuzione tra i due cluster e un'istanza del database back-end. Tutti i cluster e i servizi del servizio Azure Kubernetes vengono eseguiti in una singola rete, con una singola subnet.
- Il cluster Kubernetes A ha 3 nodi del piano di controllo e 5 nodi di lavoro.
- Il cluster Kubernetes B ha 1 nodo del piano di controllo e 3 nodi di lavoro.
- 3 istanze dell'interfaccia utente front-end (porta 443).
- 1 istanza del database back-end (porta 80).
In base alla tabella precedente, Jane deve riservare un totale di 19 indirizzi IP nella subnet di Jane:
- 8 indirizzi IP per le macchine virtuali del nodo Arc del servizio Azure Kubernetes nel cluster A (un IP per macchina virtuale del nodo K8s).
- 4 indirizzi IP per le macchine virtuali del nodo Arc del servizio Azure Kubernetes nel cluster B (un IP per macchina virtuale del nodo K8s).
- 2 indirizzi IP per l'esecuzione dell'operazione di aggiornamento di Arc del servizio Azure Kubernetes (un indirizzo IP per ogni cluster del servizio Azure Kubernetes Arc).
- 2 indirizzi IP per il piano di controllo Arc del servizio Azure Kubernetes (un indirizzo IP per ogni cluster di Azure Kubernetes Arc)
- 3 Indirizzi IP per il servizio Kubernetes (un indirizzo IP per istanza dell'interfaccia utente front-end, poiché usano tutte la stessa porta. Il database back-end può usare uno dei tre indirizzi IP purché usi una porta diversa.
Continuando con questo esempio e aggiungendolo alla tabella seguente, si ottiene:
Parametro | Numero di indirizzi IP | Come e dove effettuare questa prenotazione |
---|---|---|
VM Arc del servizio Azure Kubernetes, aggiornamento della versione K8s e IP del piano di controllo | Riservare 16 indirizzi IP | Effettuare questa prenotazione tramite pool IP nella rete logica locale di Azure. |
Indirizzi IP del servizio di bilanciamento del carico | 3 Indirizzo IP per i servizi Kubernetes, per l'applicazione di voto di Jane. | Questi indirizzi IP vengono usati quando si installa un servizio di bilanciamento del carico nel cluster A. È possibile usare l'estensione MetalLB Arc o usare il servizio di bilanciamento del carico di terze parti. Assicurarsi che questo IP si trova nella stessa subnet della rete logica Arc, ma all'esterno del pool IP definito nella rete logica arc VM. |
Comandi dell'interfaccia della riga di comando di esempio per la prenotazione di indirizzi IP per cluster e applicazioni Kubernetes
Questa sezione descrive il set di comandi eseguiti da Jane per il suo scenario. Creare prima di tutto una rete logica con un pool IP con almeno 16 indirizzi IP. È stato creato il pool DI INDIRIZZI IP con 20 indirizzi IP per offrire la possibilità di ridimensionare il giorno N. Per informazioni dettagliate sulle opzioni dei parametri nelle reti logiche, vedere az stack-hci-vm network lnet create
:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Creare quindi un cluster Arc del servizio Azure Kubernetes con la rete logica precedente:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
È ora possibile abilitare il servizio di bilanciamento del carico MetalLB con un pool IP di 3 indirizzi IP, nella stessa subnet della rete logica arc VM. Se l'applicazione necessita di un aumento, è possibile aggiungere più pool IP in un secondo momento. Per i requisiti dettagliati, vedere panoramica dell'estensione MetalLB Arc.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Considerazioni sulle reti LNET per cluster del servizio Azure Kubernetes e macchine virtuali Arc
Le reti logiche in locale di Azure vengono usate sia dai cluster del servizio Azure Kubernetes che dalle macchine virtuali Arc. È possibile configurare reti logiche in uno dei due modi seguenti:
- Condividere una rete logica tra il servizio Azure Kubernetes e le macchine virtuali Arc.
- Definire reti logiche separate per cluster del servizio Azure Kubernetes e macchine virtuali Arc.
La condivisione di una rete logica tra il servizio Azure Kubernetes e le macchine virtuali Arc in Locale di Azure offre il vantaggio di semplificare la comunicazione, i risparmi sui costi e la gestione semplificata della rete. Tuttavia, questo approccio introduce anche potenziali sfide, ad esempio conflitti di risorse, rischi per la sicurezza e complessità nella risoluzione dei problemi.
Criteri | Condivisione di una rete logica | Definizione di reti logiche separate |
---|---|---|
Complessità della configurazione | Configurazione più semplice con una singola rete, riducendo la complessità della configurazione. | Configurazione più complessa, perché è necessario configurare più reti logiche per le macchine virtuali e i cluster del servizio Azure Kubernetes. |
Scalabilità | Le potenziali limitazioni di scalabilità come macchine virtuali Arc e cluster del servizio Azure Kubernetes condividono le risorse di rete. | Più scalabile poiché le risorse di rete sono separate e possono essere ridimensionate in modo indipendente. |
Gestione dei criteri di rete | Più facile da gestire con un set di criteri di rete, ma più difficile isolare i carichi di lavoro. | Più facile isolare i carichi di lavoro, perché è possibile applicare criteri separati per ogni rete logica. |
Considerazioni relative alla sicurezza | Aumento del rischio di vulnerabilità di comunicazione incrociata se non è stato segmentato correttamente. | Maggiore sicurezza perché ogni rete può essere segmentata e isolata più rigorosamente. |
Impatto degli errori di rete | Un errore nella rete condivisa può influire simultaneamente sia sul servizio Azure Kubernetes che sulle macchine virtuali Arc. | Un errore in una rete influisce solo sui carichi di lavoro all'interno di tale rete, riducendo il rischio complessivo. |
Allocazione dell'intervallo di indirizzi IP per CIDR pod e CIDR del servizio
Questa sezione descrive gli intervalli di indirizzi IP usati da Kubernetes per la comunicazione tra pod e servizi all'interno di un cluster. Questi intervalli di indirizzi IP vengono definiti durante il processo di creazione del cluster del servizio Azure Kubernetes e vengono usati per assegnare indirizzi IP univoci a pod e servizi all'interno del cluster.
CIDR di rete pod
CiDR di rete pod è un intervallo di indirizzi IP usati da Kubernetes per assegnare indirizzi IP univoci ai singoli pod in esecuzione all'interno di un cluster Kubernetes. Ogni pod ottiene il proprio indirizzo IP all'interno di questo intervallo, consentendo ai pod di comunicare tra loro e con i servizi all'interno del cluster. Nel servizio Azure Kubernetes gli indirizzi IP dei pod vengono assegnati tramite Calico CNI in modalità VXLAN. Calico VXLAN consente di creare reti overlay, in cui gli indirizzi IP dei pod (dalla rete pod CIDR) vengono virtualizzati e sottoposti a tunneling attraverso la rete fisica. In questa modalità, a ogni pod viene assegnato un indirizzo IP dal CIDR di rete pod, ma questo indirizzo IP non è direttamente instradabile nella rete fisica. Al contrario, viene incapsulato all'interno dei pacchetti di rete e inviato tramite la rete fisica sottostante per raggiungere il pod di destinazione in un altro nodo.
Il servizio Azure Kubernetes fornisce un valore predefinito 10.244.0.0/16 per il CIDR della rete pod. Il servizio Azure Kubernetes supporta le personalizzazioni per il CIDR della rete pod. È possibile impostare un valore personalizzato usando il --pod-cidr
parametro durante la creazione del cluster del servizio Azure Kubernetes. Assicurarsi che l'intervallo IP CIDR sia sufficientemente grande da contenere il numero massimo di pod per nodo e nel cluster Kubernetes.
CIDR di rete del servizio
Il CIDR di rete del servizio è l'intervallo di indirizzi IP riservati per i servizi Kubernetes, ad esempio LoadBalancers, ClusterIP e NodePort all'interno di un cluster. Kubernetes supporta i tipi di servizio seguenti:
- ClusterIP: tipo di servizio predefinito, che espone il servizio all'interno del cluster. L'INDIRIZZO IP assegnato dal CIDR della rete del servizio è accessibile solo all'interno del cluster Kubernetes.
- NodePort: espone il servizio su una porta specifica sull'indirizzo IP di ogni nodo. ClusterIP viene ancora usato internamente, ma l'accesso esterno avviee tramite gli INDIRIZZI IP del nodo e una porta specifica.
- LoadBalancer: questo tipo crea un servizio di bilanciamento del carico gestito dal provider di servizi cloud ed espone il servizio esternamente. Il provider di servizi cloud gestisce in genere l'assegnazione IP esterna, mentre ClusterIP interno rimane all'interno del CIDR della rete del servizio.
Il servizio Azure Kubernetes fornisce un valore predefinito 10.96.0.0/12 per il CIDR di rete del servizio. Il servizio Azure Kubernetes non supporta attualmente le personalizzazioni per il CIDR della rete del servizio.
Passaggi successivi
Creare reti logiche per i cluster Kubernetes in Azure Locale, versione 23H2