Architettura di rete dell'applicazione Azure Kubernetes (anteprima)

Importante

Le funzionalità di anteprima di AKS sono disponibili su base self-service, su scelta. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

L'architettura di rete delle applicazioni di Azure Kubernetes è organizzata in tre livelli: un piano di gestione, un piano di controllo e un piano dati. Ogni livello ha responsabilità distinte che insieme forniscono una soluzione di rete del servizio basata su ambiente completamente gestita per il servizio Azure Kubernetes. Questa architettura consente la comunicazione sicura basata su criteri tra i servizi senza richiedere sidecar o modifiche alle applicazioni.

Questo articolo offre una panoramica dei livelli architetturali della rete applicativa di Azure Kubernetes, del modo in cui interagiscono e del modello di individuazione dei servizi multi-cluster che consente la comunicazione tra cluster scalabili. Per ulteriori informazioni su Azure Kubernetes Application Network, consultare la panoramica di Azure Kubernetes Application Network per AKS.

Panoramica dei livelli architetturali di Application Network

I livelli architetturali gestiscono le responsabilità seguenti:

Piano di gestione: gestisce le operazioni delle risorse di Azure, ad esempio la creazione, l'aggiornamento e l'eliminazione delle risorse di rete delle applicazioni e la gestione dell'appartenenza al cluster.
Piano di controllo: gestisce la configurazione mesh, il ciclo di vita dei certificati e l'individuazione dei servizi per ogni cluster membro.
Piano dati: protegge il traffico tra servizi direttamente nel cluster membro utilizzando la modalità ambientale, che non richiede sidecar o modifiche alle applicazioni.

Per le distribuzioni multi-cluster, La rete applicazioni sincronizza le informazioni di individuazione dei servizi tra cluster membri in modo che i servizi possano comunicare in modo trasparente attraverso i limiti del cluster.

Il diagramma seguente illustra i livelli architetturali della rete applicativa di Azure Kubernetes e il modo in cui interagiscono tra loro e con i cluster del servizio Azure Kubernetes:

Piano di gestione

Il piano di gestione è il provider di risorse di Azure che gestisce tutte le operazioni delle risorse di rete delle applicazioni. Quando si crea una risorsa di rete dell'applicazione o si aggiunge a un cluster membro, il piano di gestione convalida la richiesta, effettua il provisioning delle risorse di Azure, ad esempio Azure Key Vault per l'archiviazione dei certificati e orchestra la creazione di un piano di controllo a livello di area per il membro.

Si interagisce con il piano di gestione tramite l'interfaccia della riga di comando di Azure (az appnet) o l'API ARM. Il piano di gestione coordina tutto il provisioning downstream in modo che i componenti del piano di controllo e del piano dati vengano distribuiti senza intervento manuale.

Piano di controllo

Il piano di controllo è un'infrastruttura completamente gestita che viene eseguita all'esterno del cluster AKS. Quando un cluster membro viene aggiunto a una rete di applicazioni, viene effettuato il provisioning di un piano di controllo dedicato nella stessa area di Azure del cluster membro, mantenendo bassa la latenza tra i componenti del piano dati e di controllo.

Annotazioni

I membri in aree di Azure diverse hanno piani di controllo distribuiti nelle rispettive aree.

Il piano di controllo include i componenti seguenti:

Istiod: si connette al server API Kubernetes del cluster membro per individuare i servizi e controllare le modifiche alla configurazione. Esegue il push della configurazione xDS verso i proxy ztunnel e waypoint nel piano dati. Nelle distribuzioni multi-cluster, Istiod si connette anche ai server API Kubernetes di altri cluster membri per ottenere informazioni sull'individuazione dei servizi, abilitando l'individuazione dei servizi tra cluster.
Gestione dei certificati: effettua il provisioning e ruota i certificati CA supportati da Azure Key Vault. Una CA radice stabilisce un limite di attendibilità condiviso tra tutti i cluster membri e ogni membro riceve una CA intermedia che rilascia certificati di carico di lavoro di breve durata. Per altre informazioni, vedere Panoramica della sicurezza della rete delle applicazioni di Azure Kubernetes.
Gestione del ciclo di vita: distribuisce e aggiorna tutti i componenti del piano dati nel cluster membro, tra cui ztunnel, Istio CNI, proxy waypoint e definizioni di risorse personalizzate. Per altre informazioni, vedere Configurare gli aggiornamenti per i membri della rete dell'applicazione Azure Kubernetes.

Piano dati

Il piano dati è costituito da componenti distribuiti nello spazio dei nomi del cluster applink-system membro. La Application Network utilizza la modalità ambiente Istio, pertanto non vengono iniettati sidecar nei carichi di lavoro.

Il piano dati include i componenti seguenti:

Ztunnel: un proxy L4 a livello di nodo distribuito come DaemonSet. Ztunnel intercetta il traffico da servizio a servizio nel nodo, stabilisce le connessioni mTLS in modo trasparente e applica i criteri di autorizzazione L4.
Proxy waypoint: proxy L7 facoltativi per spazio dei nomi che forniscono routing HTTP, ridistribuzione del traffico, iniezione di guasti e autorizzazione L7. I proxy waypoint vengono distribuiti solo quando le policy L7 sono configurate per un namespace.
Gateway est-ovest: gestisce il traffico tra i cluster nelle distribuzioni multi-cluster. Sei responsabile del collegamento di rete tra i gateway east-west nei cluster membri. Per altre informazioni, vedere Individuazione di servizi multi-cluster.
Istio CNI: DaemonSet che configura la rete dei pod per l'intercettazione del traffico mesh di ambiente.
CRD: definizioni di risorse personalizzate Kubernetes per la configurazione della gestione del traffico e dei criteri di sicurezza.

Quando viene effettuata una richiesta tra i servizi, ztunnel intercetta il traffico, stabilisce una connessione mTLS con lo ztunnel della destinazione e recapita la richiesta al carico di lavoro di destinazione. Se i criteri L7 sono configurati, il traffico viene instradato attraverso un proxy waypoint prima di raggiungere la destinazione. Per il traffico tra cluster, ztunnel instrada attraverso il gateway east-west per raggiungere i carichi di lavoro nei cluster membri remoti.

Individuazione di servizi multi-cluster

La Application Network supporta la connessione di più cluster AKS in una mesh di servizi unificata. I servizi in un cluster membro possono comunicare con i servizi in altri cluster membri, con mTLS applicato end-to-end oltre i limiti del cluster.

Nelle distribuzioni di istio multi-cluster open source i piani di controllo si connettono in genere ai server API Kubernetes di altri cluster per individuare i servizi e le modifiche alla configurazione. La rete delle applicazioni segue un modello di individuazione dei servizi simile, in cui i piani di controllo ottengono informazioni sul servizio dai cluster membri in modo che i servizi possano essere individuati attraverso i limiti del cluster. Questo approccio consente ai carichi di lavoro in un cluster membro di risolvere e comunicare con i servizi in esecuzione in altri cluster senza richiedere modifiche all'applicazione. L'aggiunta di un nuovo cluster membro espande l'appartenenza alla mesh in modo che i servizi nel nuovo cluster diventino individuabili da altri membri.

Il traffico tra cluster attraversa i gateway est-west distribuiti in ogni cluster membro. L'utente è responsabile di fornire la raggiungibilità della rete tra i gateway east-west dei propri cluster membri, ad esempio tramite peering VNet, VPN o altre soluzioni di connettività. Tutto il traffico tra cluster viene crittografato con mTLS.

Interazione dei componenti

Il piano di controllo si connette al server API Kubernetes del cluster membro, controlla le modifiche al servizio e alla configurazione ed esegue il push degli aggiornamenti xDS ai proxy ztunnel e waypoint. Quando esistono più membri, ogni piano di controllo scambia anche informazioni sul servizio tramite messaggistica gestita in modo che ogni membro abbia una visualizzazione coerente di tutti i servizi nella mesh.

La gestione dei certificati effettua il provisioning di una CA radice quando viene creata la risorsa di rete dell'applicazione e rilascia ca intermedie per ogni cluster membro. I certificati del carico di lavoro vengono rilasciati con un periodo di validità di 24 ore e ruotati automaticamente ogni 12 ore. L'intero ciclo di vita del certificato, dalla CA radice ai certificati intermedi e del carico di lavoro, viene gestito senza intervento manuale.

Per la pianificazione completa della gerarchia dei certificati e della rotazione, vedere Panoramica della sicurezza della rete di applicazioni di Azure Kubernetes.

Per altre informazioni sulla rete dell'applicazione Azure Kubernetes, vedere gli articoli seguenti:

Commenti e suggerimenti

Questa pagina è stata utile?

Ultimo aggiornamento: 2026-03-23