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.
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 di routing del servizio: a seconda del piano dati di rete, i nodi usano
kube-proxyo Cilium per il routing del servizio Kubernetes. I cluster AKS che usano Azure CNI basata su Cilium non usanokube-proxy.
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 (servizio Azure Kubernetes).
- La creazione di un servizio di bilanciamento del carico Kubernetes in Azure configura simultaneamente la risorsa di bilanciamento del carico corrispondente Azure.
- Quando si crea un Kubernetes
LoadBalancerService, Azure configura le regole del gruppo di sicurezza di rete necessarie al traffico del servizio nelle risorse gestite da AKS. - Azure può anche gestire le configurazioni DNS esterne per il routing delle applicazioni HTTP quando vengono stabilite nuove route di ingresso.
Azure reti virtuali
Nel servizio Azure Kubernetes è possibile distribuire un cluster che usa uno dei modelli di rete seguenti:
- Modello di rete overlay: la rete sovrapposta è il modello di rete più comune usato in Kubernetes. Ai pod viene assegnato un indirizzo IP da un CIDR privato e logicamente separato dalla sottorete della rete virtuale di Azure in cui sono distribuiti i nodi di AKS. Questo modello consente una scalabilità più semplice e migliorata rispetto al modello di rete piatto.
- Modello di rete flat: un modello di rete flat nel servizio Azure Kubernetes assegna indirizzi IP a pod da una subnet nella stessa rete virtuale Azure dei nodi del servizio Azure Kubernetes. Per il traffico di rete privata, l'indirizzo IP di origine visualizzato da una destinazione dipende dall'opzione Gestione indirizzi IP . Azure CNI Pod Subnet mantiene l'indirizzo IP del pod attraverso reti virtuali connesse. Con Azure CNI Node Subnet, le destinazioni nella rete virtuale del cluster vedono l'indirizzo IP del pod, ma le destinazioni al di fuori della rete virtuale del cluster vedono l'indirizzo IP del nodo. Per l'uscita internet, il metodo in uscita configurato determina l'indirizzo IP di origine pubblico visualizzato dalle destinazioni Internet.
Per altre informazioni sui modelli di rete nel servizio Azure Kubernetes, vedere Rete CNI 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 da servizi esterni a tale rete virtuale, quasi completamente definiti con nomi di dominio completi (FQDN). Il servizio Azure Kubernetes offre diverse opzioni di configurazione in uscita che consentono di personalizzare la modalità di accesso a queste risorse esterne.
Importante
A partire da March 31, 2026, Servizio Azure Kubernetes (AKS) non supporta più l'accesso in uscita predefinito per le macchine virtuali. I nuovi cluster AKS che usano l'opzione rete virtuale gestita da AKS inseriscono le subnet del cluster in subnet private per impostazione predefinita (defaultOutboundAccess = false). Questa impostazione non influisce sul traffico del cluster gestito dal servizio Azure Kubernetes, che usa percorsi in uscita configurati in modo esplicito. Potrebbe influire su scenari non supportati, ad esempio la distribuzione di altre risorse nella stessa subnet. I cluster che usano reti virtuali BYO non sono interessati da questa modifica. Nelle configurazioni supportate non è necessaria alcuna azione. Per ulteriori informazioni sulla disattivazione, vedere l'annuncio di disattivazione degli aggiornamenti di Azure. Per rimanere informati sugli annunci e aggiornamenti, seguite le note di rilascio di AKS.
Opzioni di configurazione in uscita
Per altre informazioni sui tipi di configurazione in uscita del cluster del servizio Azure Kubernetes supportati, vedere Personalizzare l'uscita del cluster con tipi in uscita nel servizio Azure Kubernetes.
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 su come limitare il traffico in uscita dal cluster, vedere Controllare il traffico in uscita per i nodi del cluster nel 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 un LoadBalancer, la piattaforma Azure configura automaticamente le regole del gruppo di sicurezza di rete necessarie per il traffico di servizio sulle risorse gestite da AKS.
AKS non applica gruppi di sicurezza di rete alla subnet né modifica i gruppi di sicurezza di rete che associ a una subnet fornita dal cliente. Se si associa un gruppo di sicurezza di rete a una subnet personalizzata, è necessario assicurarsi che le relative regole consentano il traffico del nodo e del pod necessari. Per ulteriori informazioni, vedi Prerequisiti di rete CNI per AKS.
È 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.
Requisiti di rete virtuale personalizzati
Quando si utilizza una rete virtuale personalizzata con cluster AKS, se si aggiungono regole del gruppo di sicurezza di rete per limitare il traffico tra le subnet, assicurarsi che le regole consentano il traffico richiesto dalla configurazione del cluster.
L'integrazione della rete virtuale del server API è preconfigurata in AKS Automatic. In AKS Standard la funzionalità è facoltativa ed è necessario abilitarla in modo esplicito. Quando il cluster utilizza l'Integrazione VNet del server API, consenti il traffico seguente:
| Destinazione | Fonte | Protocollo | Porto | Utilizzo |
|---|---|---|---|---|
| CIDR subnet APIServer | Subnet del cluster | TCP | 443 e 4443 | Obbligatorio per abilitare la comunicazione tra i nodi e il server API. |
| CIDR subnet APIServer | Azure Load Balancer | TCP | 9988 | Obbligatorio per abilitare la comunicazione tra Azure Load Balancer e il server API. È anche possibile abilitare tutte le comunicazioni tra la Azure Load Balancer e il CIDR della subnet del server API. |
Per altre informazioni, vedere Integrazione rete virtuale del server API.
Per la comunicazione tra nodi e pod, consentire il traffico seguente quando le regole del gruppo di sicurezza di rete limitano gli intervalli CIDR corrispondenti:
| Destinazione | Fonte | Protocollo | Porto | Utilizzo |
|---|---|---|---|---|
| CIDR nodo | CIDR nodo | Tutti i protocolli | Tutte le porte | Obbligatorio per abilitare la comunicazione tra nodi. |
| CIDR pod | CIDR nodo | Tutti i protocolli | Tutte le porte | Obbligatorio per il routing del traffico del servizio. |
| CIDR pod | CIDR pod | Tutti i protocolli | Tutte le porte | Obbligatorio per il traffico da Pod a Pod e da Pod a Servizio, incluso il traffico DNS. |
Gli intervalli CIDR del nodo e del pod applicabili dipendono dal modello di rete del cluster. Per altre informazioni, vedi prerequisiti di rete CNI di AKS.
Risoluzione DNS
La risoluzione DNS è essenziale per la scoperta e la comunicazione dei servizi in AKS. Per impostazione predefinita, AKS utilizza CoreDNS per fornire la risoluzione dei nomi interna per i pod e i servizi.
Per migliorare le prestazioni e l'affidabilità del DNS, AKS offre LocalDNS, che distribuisce un proxy DNS su ogni nodo. LocalDNS risolve le query in locale, riducendo la latenza ed eliminando la pressione della conntrack tabella dal traffico DNS. È possibile configurare LocalDNS per gestire le risposte memorizzate nella cache durante le interruzioni DNS upstream, ma la memorizzazione nella cache delle risposte non aggiornate funziona in modo ottimale. LocalDNS è particolarmente utile in cluster o ambienti di grandi dimensioni con volumi di query DNS elevati.
LocalDNS è preconfigurato in AKS Automatic. In AKS Standard, LocalDNS è facoltativo e configurato per pool di nodi. Prima di abilitarlo nel servizio Azure Kubernetes Standard, verificare la versione di Kubernetes, il sistema operativo del nodo e i prerequisiti dello SKU della macchina virtuale. L'abilitazione di LocalDNS in un pool di nodi esistente ricrea l'immagine dei nodi. Per i prerequisiti e la pianificazione dell'implementazione, vedere Configurare LocalDNS.
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.
I criteri di rete sono una funzionalità Kubernetes disponibile nel servizio Azure Kubernetes che consente di controllare il flusso del traffico tra 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. Sebbene i gruppi di sicurezza di rete siano migliori per i nodi del servizio Azure Kubernetes, i criteri di rete sono un modo nativo del cloud 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 ulteriori informazioni, vedere Traffico sicuro tra pod utilizzando criteri di rete in Servizio Azure Kubernetes (AKS).
Passaggi successivi
Per iniziare a usare la rete del servizio Azure Kubernetes, creare e configurare un cluster del servizio Azure Kubernetes con intervalli di indirizzi IP personalizzati usando Azure overlay CNI 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: