Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: AKS su Windows Server
I componenti dell'applicazione devono collaborare per elaborare le attività in un approccio basato su microservizi a contenitore. Kubernetes fornisce risorse che consentono le comunicazioni dell'applicazione e consentono di connettersi ed esporre applicazioni internamente o esternamente. È possibile bilanciare il carico delle applicazioni per creare applicazioni ad alta disponibilità.
Le applicazioni più complesse potrebbero richiedere la configurazione del traffico in ingresso per la terminazione SSL/TLS o il routing di più componenti. Potrebbe anche essere necessario limitare il flusso del traffico di rete tra pod e nodi per la sicurezza.
Questo articolo introduce i concetti di base che forniscono funzionalità di rete alle applicazioni in AKS su Windows Server.
- Servizi Kubernetes
- Controller di ingresso
- Criteri di rete
Servizi Kubernetes
Per semplificare la configurazione di rete per i carichi di lavoro dell'applicazione, Kubernetes usa i servizi per raggruppare logicamente un set di pod e fornire connettività di rete. Sono disponibili i tipi di servizio seguenti:
IP del cluster: crea un indirizzo IP interno da usare all'interno del cluster Kubernetes. Usare l'indirizzo IP del cluster per applicazioni solo interne che supportano altri carichi di lavoro all'interno del cluster.
NodePort: crea un mapping delle porte sul nodo sottostante che consente l'accesso diretto all'applicazione con l'indirizzo IP e la porta del nodo.
LoadBalancer: crea una risorsa del servizio di bilanciamento del carico di Azure, configura un indirizzo IP esterno e connette i pod richiesti al pool back-end del servizio di bilanciamento del carico. Per consentire al traffico dei clienti di raggiungere l'applicazione, vengono create regole di bilanciamento del carico nelle porte desiderate.
Per altri controlli e routing del traffico in ingresso, è possibile usare un controller di ingresso.
Nota
Quando si distribuisce un cluster di destinazione che condivide una rete con un altro cluster di destinazione, è possibile che si verifichi un conflitto di indirizzi IP del servizio di bilanciamento del carico.
Ciò può verificarsi se si distribuiscono due carichi di lavoro che usano porte diverse nei cluster di destinazione che condividono lo stesso AksHciClusterNetwork
oggetto. A causa del modo in cui gli indirizzi IP e i mapping delle porte vengono allocati all'interno di HA Proxy, questo può portare a una duplicazione di assegnazioni di indirizzi IP. In questo caso, uno o entrambi i carichi di lavoro possono riscontrare problemi di connettività di rete casuali fino a quando non si distribuiscono nuovamente i carichi di lavoro. Quando si distribuiscono nuovamente i carichi di lavoro, è possibile usare la stessa porta che fa sì che ogni carico di lavoro riceva un indirizzo IP del servizio separato oppure è possibile ridribuire i carichi di lavoro nei cluster di destinazione che usano oggetti diversi AksHciClusterNetwork
.
ExternalName: crea una voce DNS specifica per semplificare l'accesso alle applicazioni. Gli indirizzi IP per i servizi e i servizi di bilanciamento del carico possono essere interni o esterni a seconda della configurazione di rete complessiva e possono essere assegnati dinamicamente. In alternativa, è possibile specificare un indirizzo IP statico esistente da usare. Un indirizzo IP statico esistente è spesso associato a una voce DNS. Ai servizi di bilanciamento del carico interno viene assegnato solo un indirizzo IP privato, quindi non è possibile accedervi da Internet.
Nozioni di base sulla rete kubernetes
Per consentire l'accesso alle applicazioni o per fare in modo che i componenti dell'applicazione comunichino tra loro, Kubernetes offre un livello di astrazione nella rete virtuale. I nodi Kubernetes sono connessi alla rete virtuale e possono fornire connettività in ingresso e in uscita per i pod. Il componente kube-proxy in esecuzione in ogni nodo fornisce queste funzionalità di rete.
In Kubernetes, i servizi raggruppano logicamente i pod per consentire:
- Accesso diretto tramite un singolo indirizzo IP o un nome DNS e una porta specifica.
- Distribuire il traffico usando un servizio di bilanciamento del carico tra più pod che ospitano lo stesso servizio o applicazione.
Quando crei un cluster AKS, creiamo e configuriamo anche una risorsa di bilanciamento del carico sottostante HAProxy
. Quando si distribuiscono applicazioni in un cluster Kubernetes, gli indirizzi IP sono configurati per i pod e i servizi Kubernetes come endpoint in questo servizio di bilanciamento del carico.
Risorse dell'indirizzo IP
Per semplificare la configurazione di rete per i carichi di lavoro dell'applicazione, Azure Kubernetes Service (AKS) Arc assegna gli indirizzi IP ai seguenti oggetti in un'implementazione:
- Server API del cluster Kubernetes: il server API è un componente del piano di controllo Kubernetes che espone l'API Kubernetes. Il server API è il front-end per il piano di controllo Kubernetes. Gli indirizzi IP statici vengono sempre allocati ai server API indipendentemente dal modello di rete sottostante.
- Nodi Kubernetes (macchine virtuali): un cluster Kubernetes è costituito da un set di computer di lavoro, denominati nodi e nodi che ospitano applicazioni in contenitori. Oltre ai nodi del piano di controllo, ogni cluster ha almeno un nodo di lavoro. Per un cluster AKS, i nodi Kubernetes vengono configurati come macchine virtuali. Queste macchine virtuali vengono create come macchine virtuali a disponibilità elevata. Per altre informazioni, vedere Concetti relativi alla rete dei nodi.
- Servizi Kubernetes: in Kubernetes, i servizi raggruppano logicamente gli indirizzi IP dei pod per consentire l'accesso diretto tramite un singolo indirizzo IP o un nome DNS su una porta specifica. I servizi possono anche distribuire il traffico usando un servizio di bilanciamento del carico. Gli indirizzi IP statici vengono sempre allocati ai servizi Kubernetes indipendentemente dal modello di rete sottostante.
- Servizi di bilanciamento del carico HAProxy: HAProxy è un servizio di bilanciamento del carico TCP/HTTP e un server proxy che distribuisce le richieste in ingresso tra più endpoint. Ogni cluster del carico di lavoro in una distribuzione del servizio Azure Kubernetes in Windows Server ha un servizio di bilanciamento del carico HAProxy distribuito e configurato come macchina virtuale specializzata.
- Servizio cloud locale Microsoft: provider di servizi cloud che consente la creazione e la gestione dell'ambiente virtualizzato che ospita Kubernetes in un cluster Windows Server locale. Il modello di rete seguito dal cluster Windows Server determina il metodo di allocazione degli indirizzi IP usato dal servizio cloud locale Microsoft. Per altre informazioni sui concetti di rete implementati dal servizio cloud locale Microsoft, vedere Concetti relativi alla rete dei nodi.
Reti Kubernetes
In AKS su Windows Server, puoi distribuire un cluster che usa uno dei modelli di rete seguenti:
- Rete overlay flannel: le risorse di rete vengono in genere create e configurate durante la distribuzione del cluster.
- Rete di Project Calico: questo modello offre funzionalità di rete aggiuntive, ad esempio criteri di rete e controllo del flusso.
Entrambe le implementazioni di rete usano un modello di configurazione di rete sovrapposto, che fornisce un'assegnazione di indirizzo IP disconnessa dal resto della rete del data center.
Per altre informazioni sulla rete di sovrimpressione, vedere Introduzione alla rete di sovrimpressione Kubernetes per Windows.
Per ulteriori informazioni sul plug-in Calico Network e sulle politiche, consulta Introduzione alla Calico Network Policy.
Confronto tra modelli di rete
Flanella
Nota
Flannel CNI è stato ritirato nel dicembre 2023.
Flannel è un livello di rete virtuale progettato appositamente per i contenitori. Flannel crea una rete flat che si sovrappone alla rete host. A tutti i contenitori/pod viene assegnato un indirizzo IP in questa rete di sovrapposizione e comunica direttamente connettendosi all'indirizzo IP dell'altro.
Calicò
Calico è una soluzione di rete e sicurezza di rete open source per contenitori, macchine virtuali e carichi di lavoro nativi basati su host. Calico supporta più piani dati, tra cui: un piano dati Linux eBPF, un piano dati di rete Linux e un piano dati HNS Windows.
Funzionalità
Capacità | Flanella | Calicò |
---|---|---|
Criteri di rete | NO | Sì |
IPv6 | NO | Sì |
Livelli usati | L2 (VxLAN) | L2 (VxLAN) |
Distribuzione del cluster in una rete virtuale esistente o nuova | Sì | Sì |
Supporto di Windows | Sì | Sì |
Connessione pod-pod | Sì | Sì |
Connessione pod-VM, macchina virtuale nella stessa rete | NO | Sì |
Connessione pod-VM, macchina virtuale in una rete diversa | Sì | Sì |
Servizi Kubernetes | Sì | Sì |
Esporre tramite bilanciatore di carico | Sì | Sì |
Reti | Molte reti nello stesso cluster con multidaemon | Molte reti nello stesso cluster |
Distribuzione | Linux: DaemonSet | Linux: DaemonSet |
Windows: Servizio | Windows: Servizio | |
Riga di comando | Nessuno | calicoctl |
Importante
Attualmente, la selezione predefinita consiste nell'usare Calico in modalità di rete di sovrapposizione. Per abilitare Flannel, usare il -primaryNetworkPlugin
parametro del New-AksHciCluster
comando di PowerShell e specificare flannel
come valore. Questo valore non può essere modificato dopo la distribuzione del cluster e si applica ai nodi del cluster Windows e Linux.
Ad esempio:
New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'
Passaggi successivi
Questo articolo illustra i concetti di rete per i contenitori nei nodi del servizio Azure Kubernetes in Windows Server. Per ulteriori informazioni sui concetti di AKS su Windows Server, vedere gli articoli seguenti: