Concetti di rete per le applicazioni in servizio Azure Kubernetes (servizio Azure Kubernetes)

In un approccio basato su contenitori, i microservizi allo sviluppo di applicazioni interagiscono tra loro per elaborare le 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 il routing 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. Questo comporta i seguenti aspetti chiave:

  • 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: in esecuzione in ogni nodo, kube-proxy è responsabile della fornitura delle funzionalità di rete necessarie.

Per informazioni sulle funzionalità specifiche di Kubernetes:

  • Servizi: vengono usati per raggruppare logicamente i pod, consentendo l'accesso diretto a tali pod tramite un indirizzo IP specifico o un nome DNS su una porta designata.
  • Tipi di servizio: questa funzionalità consente di specificare il tipo di servizio che si vuole creare.
  • 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 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.

Servizi

Per semplificare la configurazione di rete per i carichi di lavoro delle applicazioni, Kubernetes usa servizi per raggruppare dal punto di vista logico un set di pod e fornire la connettività di rete. È possibile specificare un servicetype Kubernetes per specificare il tipo di servizio desiderato, ad esempio se si vuole esporre un servizio in un indirizzo IP esterno esterno al cluster. Per altre informazioni, vedere la documentazione di Kubernetes per Publishing Services (ServiceTypes).For more information, see the Kubernetes documentation for Publishing Services (ServiceTypes).

Sono disponibili i seguenti servicetype:

  • ClusterIP

    Indirizzo IP del cluster crea un indirizzo IP interno da usare nel cluster del servizio Azure Kubernetes. Questo servizio è utile per applicazioni solo interne che supportano altri carichi di lavoro all'interno del cluster. Si tratta dell'impostazione predefinita usata se non si specifica in modo esplicito un tipo per un servizio.

    Diagram showing ClusterIP traffic flow in an AKS cluster

  • NodePort

    NodePort crea un mapping delle porte nel nodo sottostante che consente l'accesso diretto all'applicazione con l'indirizzo IP e la porta del nodo.

    Diagram showing NodePort traffic flow in an AKS cluster

  • LoadBalancer

    LoadBalancer crea una risorsa di bilanciamento del carico di Azure, configura un indirizzo IP esterno e connette i pod richiesti al pool back-end del bilanciamento del carico. Per consentire al traffico dei clienti di raggiungere l'applicazione, vengono create regole di bilanciamento del carico nelle porte desiderate.

    Diagram showing Load Balancer traffic flow in an AKS cluster

    Per il bilanciamento del carico HTTP del traffico in ingresso, un'altra opzione consiste nell'usare un controller in ingresso.

  • ExternalName

    Crea una voce DNS specifica per semplificare l'accesso alle applicazioni.

È possibile assegnare dinamicamente i servizi di bilanciamento del carico e l'indirizzo IP dei servizi oppure specificare un indirizzo IP statico esistente. È possibile assegnare indirizzi IP statici interni ed esterni. Gli indirizzi IP statici esistenti sono spesso associati a una voce DNS.

È possibile creare servizi di bilanciamento del carico sia interni che esterni. Ai servizi di bilanciamento del carico interno viene assegnato solo un indirizzo IP privato, quindi non è possibile accedervi da Internet.

Altre informazioni sui servizi sono disponibili nella documentazione di Kubernetes.

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:

  1. I nodi ricevono un indirizzo IP dalla subnet della rete virtuale di Azure.
  2. I pod ricevono un indirizzo IP da uno spazio indirizzi logicamente diverso rispetto alla subnet della rete virtuale di Azure dei nodi.
  3. Viene poi configurato il protocollo NAT (Network Address Translation) in modo che i pod possano raggiungere le risorse nella rete virtuale di Azure.
  4. 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 del Rete virtuale e il nome della subnet devono essere di almeno 63 caratteri.

A differenza di kubenet, il traffico verso gli endpoint nella stessa rete virtuale non corrisponde all'INDIRIZZO 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.

Diagram showing two nodes with bridges connecting each to a single Azure VNet

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. A tale scopo, assegnare indirizzi IP CIDR privati ai pod, che sono separati dalla rete virtuale e possono essere riutilizzati in più cluster. Inoltre, la sovrimpressione CNI di Azure può superare il limite di 400 nodi applicato nei cluster Kubenet. La sovrimpressione CNI di Azure è l'opzione consigliata per la maggior parte dei cluster.

Azure CNI con tecnologia Cilium

Azure CNI Powered by Cilium usa Cilium 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 (Gestione indirizzi IP)

Cilium applica inoltre i criteri di rete per impostazione predefinita, senza richiedere un motore di criteri di rete separato. Usando programmi eBPF e una struttura di oggetti API più efficiente, Azure CNI powered by Cilium può essere ridimensionato oltre i limiti di Azure Network Policy Manager di 250 nodi/pod 20K.

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 di terze parti 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. Tuttavia, esistono vantaggi e svantaggi per ognuno di essi. 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.

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
Esposizione dei servizi Kubernetes tramite un servizio di bilanciamento del carico, un gateway applicazione o un controller in ingresso Supportata Supportata Nessun supporto del controller in ingresso (AGIC) gateway applicazione 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.

Per i plug-in Kubenet e Azure CNI, il servizio DNS viene fornito da CoreDNS, una distribuzione in esecuzione nel servizio Azure Kubernetes con il proprio ridimensionamento automatico. Per altre informazioni su CoreDNS in Kubernetes, vedere Personalizzazione del servizio DNS. CoreDNS per impostazione predefinita è configurato per inoltrare domini sconosciuti alla funzionalità DNS del Rete virtuale di Azure in cui viene distribuito il cluster del servizio Azure Kubernetes. Di conseguenza, DNS di Azure e zone private funzioneranno per i pod in esecuzione nel servizio Azure Kubernetes.

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.

Diagram showing Ingress traffic flow in an AKS cluster

Creare una risorsa in ingresso

Nel servizio Azure Kubernetes è possibile creare una risorsa in ingresso usando NGINX, uno strumento simile o la funzionalità di routing delle applicazioni HTTP del servizio Azure Kubernetes. Quando si abilita il routing delle applicazioni HTTP per un cluster del servizio Azure Kubernetes, la piattaforma Azure crea il controller di ingresso e un controller EXTERNAL-DNS . Man mano che vengono create nuove risorse in ingresso in Kubernetes, i record DNS A necessari vengono creati in una zona DNS specifica del cluster.

Per altre informazioni, vedere Distribuire il routing delle applicazioni HTTP.

controller di ingresso (AGIC) gateway applicazione

Con il componente aggiuntivo AGIC (Ingress Controller) di gateway applicazione, è possibile usare il servizio di bilanciamento del carico nativo di Azure gateway applicazione livello 7 per esporre il software cloud a Internet. AGIC viene eseguito come pod all'interno del cluster del servizio Azure Kubernetes. Usa le risorse di ingresso kubernetes e le converte in una configurazione gateway applicazione, che consente al gateway di bilanciare il carico del traffico verso i pod Kubernetes.

Per altre informazioni sul componente aggiuntivo AGIC per il servizio Azure Kubernetes, vedere Che cos'è gateway applicazione Controller di ingresso?.

Terminazione SSL/TLS

La terminazione SSL/TLS è un'altra funzionalità comune di ingresso. Nelle applicazioni Web di grandi dimensioni a cui si accede tramite HTTPS, la risorsa Ingress gestisce la terminazione TLS anziché all'interno dell'applicazione stessa. Per fornire la generazione e la configurazione automatica della certificazione TLS, è possibile configurare la risorsa in ingresso per l'uso di provider come "Let's Encrypt".

Per altre informazioni sulla configurazione di un controller di ingresso NGINX con Let's Encrypt, vedere Ingresso e TLS.

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 una richiesta di un client a un contenitore nel cluster del servizio Azure Kubernetes, l'INDIRIZZO IP di origine originale di tale richiesta non è disponibile per il contenitore di destinazione. Quando si abilita la conservazione ip di origine client, l'INDIRIZZO IP di origine per il client è disponibile nell'intestazione della richiesta in X-Forwarded-For.

Se si usa la conservazione ip di origine client nel controller di ingresso, non è possibile usare il pass-through TLS. La conservazione 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 nel servizio Azure Kubernetes.

Gruppi di sicurezza di rete

Un gruppo di sicurezza di rete filtra il traffico per macchine virtuali come i nodi del servizio Azure Kubernetes. Durante la creazione di servizi, ad esempio loadBalancer, la piattaforma Azure configura automaticamente le regole del gruppo 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 l'inoltro necessari come parte dei manifesti del servizio Kubernetes e consentire alla piattaforma Azure di creare o aggiornare 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 controllano il flusso del traffico, ad esempio:

  • Le applicazioni back-end vengono esposte solo ai servizi front-end necessari.
  • I componenti di 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 di traffico tra i pod. È possibile consentire o negare il traffico verso il pod in base a impostazioni quali etichette assegnate, spazio dei nomi o porta del 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: