Concetti relativi al networking per le applicazioni nel servizio Azure Kubernetes (AKS)
In un approccio allo sviluppo delle applicazioni come microservizi basati su contenitori, i componenti dell'applicazione devono interagire per elaborare le proprie attività. Kubernetes offre diverse risorse che consentono questa cooperazione:
- È possibile connettersi alle applicazioni ed esporle internamente o esternamente.
- È possibile creare applicazioni a disponibilità elevata bilanciando il carico delle applicazioni.
- È possibile limitare il flusso del traffico di rete verso o tra pod e nodi per migliorare la sicurezza.
- È possibile configurare il traffico in ingresso per la terminazione SSL/TLS o l'instradamento di più componenti per le applicazioni più complesse.
Questo articolo introduce i concetti di base correlati alle funzionalità di rete per le applicazioni nel servizio Azure Kubernetes:
Nozioni di base sulla rete kubernetes
Kubernetes usa un livello di rete virtuale per gestire l'accesso all'interno e tra le applicazioni o i relativi componenti:
Nodi Kubernetes e rete virtuale: i nodi Kubernetes sono connessi a una rete virtuale. Questa configurazione consente ai pod (unità di base di distribuzione in Kubernetes) di avere connettività in ingresso e in uscita.
Componente Kube-proxy: kube-proxy viene eseguito in ogni nodo ed è responsabile della fornitura delle funzionalità di rete necessarie.
Per informazioni sulle funzionalità specifiche di Kubernetes:
- Bilanciamento del carico: è possibile usare un servizio di bilanciamento del carico per distribuire il traffico di rete in modo uniforme tra varie risorse.
- Controller di ingresso: facilitano il routing di livello 7, essenziale per indirizzare il traffico dell'applicazione.
- Controllo del traffico in uscita: Kubernetes consente di gestire e controllare il traffico in uscita dai nodi del cluster.
- Criteri di rete: questi criteri consentono misure di sicurezza e filtri per il traffico di rete nei pod.
Nel contesto della piattaforma Azure:
- Azure semplifica la rete virtuale per i cluster del servizio Azure Kubernetes.
- La creazione di un servizio di bilanciamento del carico Kubernetes in Azure configura contemporaneamente la risorsa del servizio di bilanciamento del carico di Azure corrispondente.
- Quando si aprono le porte di rete ai pod, Azure configura automaticamente le regole del gruppo di sicurezza di rete necessarie.
- Azure può anche gestire le configurazioni DNS esterne per il routing delle applicazioni HTTP quando vengono stabilite nuove route in ingresso.
Reti virtuali di Azure
Nel servizio Azure Kubernetes è possibile distribuire un cluster che usa uno dei modelli di rete seguenti:
Rete Kubenet
Le risorse di rete vengono in genere create e configurate durante la distribuzione del cluster del servizio Azure Kubernetes.
Rete Azure Container Networking Interface
il cluster del servizio Azure Kubernetes viene connesso alle risorse di rete virtuale e alle configurazioni esistenti.
Funzionalità di rete kubenet (di base)
L'opzione per le funzionalità di rete kubenet è la configurazione predefinita per la creazione del cluster del servizio Azure Kubernetes. Con kubenet:
- I nodi ricevono un indirizzo IP dalla subnet della rete virtuale di Azure.
- I pod ricevono un indirizzo IP da uno spazio indirizzi logicamente diverso rispetto alla subnet della rete virtuale di 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 viene traslato nell'indirizzo IP primario del nodo.
I nodi usano il plug-in kubenet di Kubernetes. La piattaforma Azure può creare e configurare le reti virtuali automaticamente. In alternativa, è possibile distribuire il cluster del servizio Azure Kubernetes nella subnet di una rete virtuale esistente.
Solo i nodi ricevono un indirizzo IP instradabile. I pod usano NAT per comunicare con altre risorse all'esterno del cluster del servizio Azure Kubernetes. Questo approccio riduce il numero di indirizzi IP che è necessario riservare nello spazio di rete per i pod da usare.
Nota
Mentre kubenet è l'opzione di rete predefinita per un cluster del servizio Azure Kubernetes per creare una rete virtuale e una subnet, non è consigliabile per le distribuzioni di produzione. Per la maggior parte delle distribuzioni di produzione, è consigliabile pianificare e usare la rete CNI di Azure grazie alle caratteristiche di scalabilità e prestazioni superiori.
Per altre informazioni, vedere Configurare funzionalità di rete kubenet per un cluster del servizio Azure Kubernetes.
Funzionalità di rete Azure CNI (avanzata)
Con l'interfaccia CNI di Azure, ogni pod ottiene un indirizzo IP dalla subnet ed è possibile accedervi direttamente. Questi indirizzi IP devono essere pianificati in anticipo e univoci in tutto lo spazio di rete. Ogni nodo ha un parametro di configurazione per il numero massimo di pod supportati. Il numero equivalente di indirizzi IP per nodo viene quindi riservato in anticipo. Questo approccio può causare l'esaurimento degli indirizzi IP o la necessità di ricompilare i cluster in una subnet più grande man mano che le richieste dell'applicazione aumentano, quindi è importante pianificare correttamente. Per evitare questi problemi di pianificazione, è possibile abilitare la funzionalità Rete CNI di Azure per l'allocazione dinamica di indirizzi IP e il supporto avanzato delle subnet.
Nota
A causa delle limitazioni di Kubernetes, il nome del gruppo di risorse, il nome della rete virtuale e il nome della subnet devono essere di almeno 63 caratteri.
A differenza di kubenet, il traffico verso gli endpoint della stessa rete virtuale non viene tradotto (NAT) sull'IP primario del nodo. L'indirizzo di origine per il traffico all'interno della rete virtuale è l'indirizzo IP del pod. Il traffico esterno alla rete virtuale continua a raggiungere l'indirizzo IP primario del nodo.
I nodi usano il plug-in Kubernetes CNI di Azure.
Per altre informazioni, vedere Configurare Azure CNI in un cluster del servizio Azure Kubernetes.
Rete di sovrimpressione CNI di Azure
La sovrimpressione CNI di Azure rappresenta un'evoluzione di Azure CNI, risolvendo i problemi di scalabilità e pianificazione derivanti dall'assegnazione di indirizzi IP di rete virtuale ai pod. Azure CNI Overlay assegna indirizzi IP privati CIDR ai pod. Gli indirizzi IP privati sono separati dalla rete virtuale e possono essere riutilizzati in più cluster. Azure CNI Overlay può superare il limite di 400 nodi applicato nei cluster Kubenet. Azure CNI Overlay è l'opzione consigliata per la maggior parte dei cluster.
Azure CNI con tecnologia Cilium
Azure CNI Powered by Cilium usaCilium per fornire funzionalità di rete, osservabilità e applicazione dei criteri di rete ad alte prestazioni. Si integra in modo nativo con la sovrimpressione CNI di Azure per la gestione degli indirizzi IP scalabili.
Inoltre, Cilium applica i criteri di rete per impostazione predefinita, senza richiedere un motore dei criteri di rete separato. Azure CNI Powered by Cilium può essere ridimensionato oltre i limiti di Azure Network Policy Manager di 250 nodi/pod da 20 K usando programmi ePBF e una struttura a oggetti API più efficiente.
Azure CNI Powered by Cilium è l'opzione consigliata per i cluster che richiedono l'imposizione dei criteri di rete.
Usare un CNI personalizzato
È possibile installare nel servizio Azure Kubernetes un CNI non Microsoft usando la funzionalità Bring Your Own CNI.
Confrontare i modelli di rete
Kubenet e Azure CNI forniscono connettività di rete per i cluster del servizio Azure Kubernetes. Ogni metodo presenta, tuttavia, vantaggi e svantaggi. A livello generale, si applicano le considerazioni seguenti:
kubenet
- Consente di risparmiare spazio indirizzi IP.
- Usa i servizi di bilanciamento del carico interni o esterni di Kubernetes per raggiungere i pod dall'esterno del cluster.
- Le route definite dall'utente vengono gestite e gestite manualmente.
- Massimo 400 nodi per cluster.
Azure CNI
- I pod ottengono la connettività di rete virtuale completa e possono essere raggiunti direttamente tramite l'indirizzo IP privato dalle reti connesse.
- Richiede più spazio indirizzi IP.
| Modello di rete | Quando utilizzare |
|---|---|
| Kubenet | • La conversazione dello spazio indirizzi IP è una priorità. • Configurazione semplice. • Meno di 400 nodi per cluster. • I servizi di bilanciamento del carico interni o esterni di Kubernetes sono sufficienti per raggiungere i pod dall'esterno del cluster. • La gestione manuale e la gestione delle route definite dall'utente è accettabile. |
| Azure CNI | • La connettività di rete virtuale completa è necessaria per i pod. • Sono necessarie funzionalità avanzate del servizio Azure Kubernetes(ad esempio nodi virtuali). • È disponibile spazio di indirizzi IP sufficiente. • È necessaria la connettività da pod a pod e pod alla macchina virtuale. • Le risorse esterne devono raggiungere direttamente i pod. • Sono necessari criteri di rete del servizio Azure Kubernetes. |
| Sovrimpressione di Azure CNI | • La carenza di indirizzi IP è un problema. • È sufficiente ridimensionare fino a 1.000 nodi e 250 pod per nodo. • L'hop aggiuntivo per la connettività dei pod è accettabile. • Configurazione di rete più semplice. • È possibile soddisfare i requisiti in uscita del servizio Azure Kubernetes. |
Esistono le differenze di comportamento seguenti tra kubenet e Azure CNI:
| Funzionalità | Kubenet | Azure CNI | Sovrimpressione di Azure CNI | Azure CNI con tecnologia Cilium |
|---|---|---|---|---|
| Distribuzione del cluster in una rete virtuale esistente o nuova | Supportata; le route definite dall'utente sono applicate manualmente | Supportata | Supportato | Supportata |
| Connettività tra pod | Supportata | Supportato | Supportato | Supportata |
| Connettività tra pod e macchina virtuale, con la VM nella stessa rete virtuale | Funziona quando avviata dal pod | Si applica in entrambi i sensi | Funziona quando avviata dal pod | Funziona quando avviata dal pod |
| Connettività tra pod e macchina virtuale, con la VM in una rete virtuale con peering | Funziona quando avviata dal pod | Si applica in entrambi i sensi | Funziona quando avviata dal pod | Funziona quando avviata dal pod |
| Accesso locale tramite VPN o ExpressRoute | Funziona quando avviata dal pod | Si applica in entrambi i sensi | Funziona quando avviata dal pod | Funziona quando avviata dal pod |
| Accesso alle risorse protette mediante gli endpoint di servizio | Supportata | Supportato | Supportata | |
| Esposizione dei servizi Kubernetes tramite un servizio di bilanciamento del carico, un gateway applicazione o un controller in ingresso | Supportata | Supportato | Supportata | Stesse limitazioni quando si usa la modalità overlay |
| Supporto per i pool di nodi Windows | Non supportato | Supportata | Supportata | Disponibile solo per Linux e non per Windows. |
| DNS di Azure e zone private predefinite | Supportata | Supportato | Supportata |
Per altre informazioni su Azure CNI e kubenet e per determinare quale opzione è più adatta, vedere Configurare la rete CNI di Azure nel servizio Azure Kubernetes e Usare la rete kubenet nel servizio Azure Kubernetes.
Supporto dell'ambito tra i modelli di rete
Indipendentemente dal modello di rete usato, sia kubenet che Azure CNI possono essere distribuiti in uno dei modi seguenti:
- La piattaforma Azure può creare e configurare automaticamente le risorse di rete virtuale quando si crea un cluster del servizio Azure Kubernetes.
- È possibile creare e configurare manualmente le risorse della rete virtuale e collegarsi a tali risorse quando si crea il cluster del servizio Azure Kubernetes.
Sebbene le funzionalità come gli endpoint di servizio o le route definite dall'utente siano supportate sia con kubenet che con Azure CNI, i criteri di supporto per il servizio Azure Kubernetes definiscono le modifiche che è possibile apportare. Ad esempio:
- Se si creano manualmente le risorse di rete virtuale per un cluster del servizio Azure Kubernetes, è possibile configurare le route definite dall'utente o gli endpoint di servizio personalizzati.
- Se la piattaforma Azure crea automaticamente le risorse di rete virtuale per il cluster del servizio Azure Kubernetes, non è possibile modificare manualmente tali risorse gestite dal servizio Azure Kubernetes per configurare le route definite dall'utente o gli endpoint di servizio.
Controller in ingresso
Quando si crea un servizio di tipo LoadBalancer, si crea anche una risorsa del servizio di bilanciamento del carico di Azure sottostante. Il bilanciamento del carico viene configurato per distribuire il traffico verso i pod nel servizio su una porta specifica.
Il LoadBalancer funziona solo al livello 4. Al livello 4, il servizio non è a conoscenza delle applicazioni reali e non può fare altre considerazioni sul routing.
I controller di ingresso operano sul livello 7 e possono usare regole più intelligenti per distribuire il traffico delle applicazioni. I controller di ingresso in genere instradano il traffico HTTP a applicazioni diverse in base all'URL in ingresso.
Confrontare le opzioni di ingresso
Nella tabella seguente sono elencate le differenze tra le diverse opzioni del controller di ingresso:
| Funzionalità | Componente aggiuntivo routing applicazioni | Gateway applicazione per contenitori | Mesh di servizi di Azure/Mesh di servizi basata su Istio |
|---|---|---|---|
| Controller di ingresso/gateway | Controller di ingresso NGINX | Gateway applicazione di Azure per contenitori | Gateway di ingresso Istio |
| API | API in ingresso | API in ingresso e API gateway | API gateway |
| Hosting | In-cluster | Azure ospitato | In-cluster |
| Ridimensionamento | Scalabilità automatica | Scalabilità automatica | Scalabilità automatica |
| Bilanciamento del carico | Interno/Esterno | Esterna | Interno/Esterno |
| Terminazione SSL | In-cluster | Sì: offload e SSL E2E | In-cluster |
| mTLS | N/D | Sì al back-end | N/D |
| Indirizzo IP statico | N/D | FQDN | N/D |
| Certificati SSL archiviati in Azure Key Vault | Sì | Sì | N/D |
| Integrazione dns di Azure per la gestione della zona DNS | Sì | Sì | N/D |
La tabella seguente elenca i diversi scenari in cui è possibile usare ogni controller di ingresso:
| Opzione in ingresso | Quando utilizzare |
|---|---|
| NGINX gestito - Componente aggiuntivo di routing delle applicazioni | • Controller in ingresso NGINX ospitati, personalizzabili e scalabili. • Funzionalità di bilanciamento del carico e routing di base. • Configurazione del servizio di bilanciamento del carico interno ed esterno. • Configurazione dell'indirizzo IP statico. • Integrazione con Azure Key Vault per la gestione dei certificati. • Integrazione con zone DNS di Azure per la gestione DNS pubblica e privata. • Supporta l'API in ingresso. |
| gateway applicazione per contenitori | • Gateway di ingresso ospitato in Azure. • Strategie di distribuzione flessibili gestite dal controller o bring your own gateway applicazione per contenitori. • Funzionalità avanzate di gestione del traffico, ad esempio tentativi automatici, resilienza della zona di disponibilità, autenticazione reciproca (mTLS) alla destinazione back-end, suddivisione del traffico/round robin ponderato e scalabilità automatica. • Integrazione con Azure Key Vault per la gestione dei certificati. • Integrazione con zone DNS di Azure per la gestione DNS pubblica e privata. • Supporta le API in ingresso e gateway. |
| Gateway di ingresso Istio | • Basato su Envoy, quando si usa con Istio per una mesh di servizi. • Funzionalità avanzate di gestione del traffico, ad esempio la limitazione della frequenza e l'interruzione del circuito. • Supporto per mTLS • Supporta l'API gateway. |
Creare una risorsa in ingresso
Il componente aggiuntivo di routing dell'applicazione è il modo consigliato per configurare un controller di ingresso nel servizio Azure Kubernetes. Il componente aggiuntivo di routing dell'applicazione è un controller di ingresso completamente gestito per servizio Azure Kubernetes (servizio Azure Kubernetes) che fornisce le funzionalità seguenti:
Configurazione semplice dei controller di ingresso NGINX gestiti basati sul controller di ingresso NGINX di Kubernetes.
Integrazione con DNS di Azure per la gestione delle zone pubbliche e private.
Terminazione SSL con certificati archiviati in Azure Key Vault.
Per altre informazioni sul componente aggiuntivo di routing dell'applicazione, vedere Ingresso NGINX gestito con il componente aggiuntivo di routing dell'applicazione.
Conservazione IP di origine client
Configurare il controller di ingresso per mantenere l'indirizzo IP di origine client nelle richieste ai contenitori nel cluster del servizio Azure Kubernetes. Quando il controller di ingresso instrada la richiesta di un client a un contenitore nel cluster AKS, l'IP di origine della richiesta non è disponibile per il contenitore di destinazione. Quando si abilita la conservazione dell’IP di origine client, l’IP di origine per il client è disponibile nell'intestazione della richiesta in X-Forwarded-For.
Se si usa la conservazione dell’IP di origine client nel controller di ingresso, non è possibile usare il pass-through TLS. La conservazione dell’IP di origine client e il pass-through TLS possono essere usati con altri servizi, ad esempio il tipo LoadBalancer.
Per altre informazioni sulla conservazione degli indirizzi IP di origine client, vedere Funzionamento della conservazione ip di origine client per i servizi LoadBalancer nel servizio Azure Kubernetes.
Controllare il traffico in uscita (in uscita)
I cluster del servizio Azure Kubernetes vengono distribuiti in una rete virtuale e hanno dipendenze in uscita dai servizi all'esterno di tale rete virtuale. Queste dipendenze in uscita sono quasi completamente definite con nomi di dominio completi (FQDN). Per impostazione predefinita, i cluster del servizio Azure Kubernetes hanno accesso a Internet in uscita senza restrizioni, che consente ai nodi e ai servizi eseguiti di accedere alle risorse esterne in base alle esigenze. Se lo si desidera, è possibile limitare il traffico in uscita.
Per altre informazioni, vedere Controllare il traffico in uscita per i nodi del cluster del servizio Azure Kubernetes.
Gruppi di sicurezza di rete
Un gruppo di sicurezza di rete filtra il traffico per le macchine virtuali, ad esempio i nodi del servizio Azure Kubernetes. Quando si creano servizi, ad esempio LoadBalancer, la piattaforma Azure configura automaticamente le eventuali regole dei gruppi di sicurezza di rete necessarie.
Non è necessario configurare manualmente le regole dei gruppi di sicurezza di rete per filtrare il traffico per i pod in un cluster del servizio Azure Kubernetes. È possibile definire le porte e gli inoltri necessari come parte dei manifesti del servizio Kubernetes e lasciare che la piattaforma Azure crei o aggiorni le regole appropriate.
È anche possibile usare i criteri di rete per applicare automaticamente le regole di filtro del traffico ai pod.
Per altre informazioni, vedere Come i gruppi di sicurezza di rete filtrano il traffico di rete.
Criteri di rete
Per impostazione predefinita, tutti i pod in un cluster del servizio Azure Kubernetes possono inviare e ricevere traffico senza limitazioni. Per una maggiore sicurezza, definire regole che controllino il flusso di traffico, come ad esempio:
- Le applicazioni back-end vengono esposte solo ai servizi front-end necessari.
- I componenti del database sono accessibili solo ai livelli applicazione a cui si connettono.
Criteri di rete è una funzionalità Kubernetes disponibile nel servizio Azure Kubernetes che consente di controllare il flusso di traffico tra i pod. È possibile consentire o negare il traffico al pod in base a impostazioni quali le etichette assegnate, lo spazio dei nomi o la porta di traffico. Anche se i gruppi di sicurezza di rete sono migliori per i nodi del servizio Azure Kubernetes, i criteri di rete sono un modo più adatto per controllare il flusso del traffico per i pod. Poiché i pod vengono creati dinamicamente in un cluster del servizio Azure Kubernetes, i criteri di rete necessari possono essere applicati automaticamente.
Per altre informazioni, vedere Proteggere il traffico tra i pod usando criteri di rete nel servizio Azure Kubernetes.
Passaggi successivi
Per iniziare a usare le funzionalità di rete del servizio Azure Kubernetes, creare e configurare un cluster del servizio Azure Kubernetes con gli intervalli di indirizzi IP esistenti usando kubenet o Azure CNI.
Per le procedure consigliate associate, vedere Procedure consigliate per la connettività di rete e la sicurezza nel servizio Azure Kubernetes.
Per altre informazioni sui concetti fondamentali di Kubernetes e del servizio Azure Kubernetes, vedere gli articoli seguenti: