Concetti di rete del contenitore

Articolo
04/19/2024

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

I componenti dell'applicazione devono collaborare per elaborare le proprie attività in un approccio di microservizi basato su contenitori. Kubernetes fornisce risorse che consentono le comunicazioni dell'applicazione e consentono di connettersi ed esporre le applicazioni internamente o esternamente. È possibile bilanciare il carico delle applicazioni per creare applicazioni a disponibilità elevata.

Le applicazioni più complesse possono 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 di traffico di rete in o tra pod e nodi per la sicurezza.

Questo articolo presenta i concetti di base che forniscono la rete alle applicazioni nel servizio Azure Kubernetes abilitato da Arc:

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 all'applicazione di accedere direttamente 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 in ingresso.

Nota

Quando si distribuisce un cluster di destinazione che condivide una rete con un altro cluster di destinazione, esiste la possibilità di 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 del proxy HA, ciò può causare un'assegnazione di indirizzo IP duplicata. In questo caso, uno o entrambi i carichi di lavoro possono riscontrare problemi di connettività di rete casuali finché non si distribuiscono nuovamente i carichi di lavoro. Quando si distribuiscono nuovamente i carichi di lavoro, è possibile usare la stessa porta che causa la ricezione di un indirizzo IP del servizio separato oppure è possibile distribuire nuovamente 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 indirizzi interni o esterni a seconda della configurazione generale della rete 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. I servizi di bilanciamento del carico interno vengono assegnati solo a un indirizzo IP privato, quindi non possono essere accessibili da Internet.

Nozioni di base sulla rete Kubernetes in Azure Stack HCI

Per consentire l'accesso alle applicazioni o per consentire ai componenti dell'applicazione di comunicare tra loro, Kubernetes offre un livello di astrazione per funzionalità di 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 pod del gruppo logico di Servizi per consentire:

Accesso diretto tramite un singolo indirizzo IP o 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.

La piattaforma Azure Stack HCI consente anche di semplificare la rete virtuale per il servizio Azure Kubernetes nei cluster HCI di Azure Stack fornendo la rete "underlay" in modo a disponibilità elevata. Quando si crea un cluster del servizio Azure Kubernetes, viene creata e configurata anche una risorsa del servizio 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, AKS Arc assegna indirizzi IP agli oggetti seguenti in una distribuzione:

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 macchine di lavoro, denominate nodi e i nodi ospitano applicazioni in contenitori. Oltre ai nodi del piano di controllo, ogni cluster ha almeno un nodo di lavoro. Per un cluster del servizio Azure Kubernetes, i nodi Kubernetes sono configurati come macchine virtuali. Queste macchine virtuali vengono create come macchine virtuali a disponibilità elevata in Azure Stack HCI, per altre informazioni, vedere Concetti di rete dei nodi.
Servizi Kubernetes: in Kubernetes, i servizi raggruppano logicamente gli indirizzi IP pod per consentire l'accesso diretto tramite un singolo indirizzo IP o un nome DNS in 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.
Servizio di bilanciamento del carico HAProxy: HAProxy è un server di bilanciamento del carico TCP/HTTP che distribuisce le richieste in ingresso in più endpoint. Ogni cluster del carico di lavoro in un servizio Azure Stack HCI in una distribuzione di Azure Stack HCI dispone di un servizio di bilanciamento del carico HAProxy distribuito e configurato come macchina virtuale specializzata.
Servizio cloud locale Microsoft: si tratta del provider cloud Azure Stack HCI che consente la creazione e la gestione dell'ambiente virtualizzato che ospita Kubernetes in un cluster HCI di Azure Stack HCI locale o in un cluster Windows Server. Il modello di rete seguito dal cluster Azure Stack HCI o 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 di rete dei nodi.

Reti Kubernetes

Nel servizio Azure Kubernetes in Azure Stack HCI è possibile distribuire un cluster che usa uno dei modelli di rete seguenti:

Rete di sovrapposizione flannel: le risorse di rete vengono in genere create e configurate come il cluster viene distribuito.
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 sovrapposizione, vedere Introduzione alla rete di sovrapposizione kubernetes per Windows.

Per altre informazioni sul plug-in e i criteri di rete Calico, vedere Introduzione ai criteri di rete calico.

Confronto dei modelli di rete

Flanella

Flannel è un livello di rete virtuale progettato in modo specifico per i contenitori. Flannel crea una rete flat che sovrappone la rete host. Tutti i contenitori/pod vengono assegnati un indirizzo IP in questa rete di sovrapposizione e comunicano direttamente connettendosi all'indirizzo IP dell'altro.

Calico

Calico è una soluzione di rete open source e sicurezza di rete per contenitori, macchine virtuali e carichi di lavoro basati su host nativi. Calico supporta più piani dati, tra cui un piano dati Linux eBPF, un piano dati di rete Linux e un piano dati di Windows HNS.

Funzionalità

Funzionalità	Flanella	Calico
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ì
Pod-Pod connessione	Sì	Sì
Connessione pod-VM, macchina virtuale nella stessa rete	No	Sì
Connessione pod-VM, macchina virtuale in rete diversa	Sì	Sì
Servizi Kubernetes	Sì	Sì
Esporre tramite load balancer	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 sovrimpressione. 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 Azure Stack HCI. Per altre informazioni sui concetti del servizio Azure Kubernetes in Azure Stack HCI, vedere gli articoli seguenti: