Considerazioni sulla topologia di rete e sulla connettività per il servizio Azure Kubernetes

Considerazioni relative alla progettazione

servizio Azure Kubernetes (servizio Azure Kubernetes) offre tre diversi modelli di rete per la rete dei contenitori: Kubenet, CNI Overlay e CNI. Ognuno di questi modelli ha un set unico di funzionalità e vantaggi, offrendo opzioni di flessibilità e scalabilità per la rete dei contenitori nel servizio Azure Kubernetes.

Kubenet

Kubenet è una soluzione di rete di base che consente di risparmiare spazio indirizzi IP e offre una configurazione semplice. È ideale per i cluster del servizio Azure Kubernetes di piccole dimensioni con meno di 400 nodi, in cui la gestione manuale e la gestione delle route definite dall'utente sono accettabili. È adatto per scenari in cui i servizi di bilanciamento del carico interni o esterni sono sufficienti per raggiungere i pod dall'esterno del cluster.

Azure CNI

Azure CNI è un modello di rete progettato per la rete avanzata. Offre connettività di rete virtuale completa per i pod, consentendo la connettività da pod a pod e pod-to-VM. È ideale per gli scenari in cui sono necessarie funzionalità avanzate del servizio Azure Kubernetes, ad esempio nodi virtuali. È adatto per gli scenari in cui è disponibile spazio di indirizzi IP sufficiente e le risorse esterne devono raggiungere direttamente i pod. I criteri di rete del servizio Azure Kubernetes sono supportati anche con Azure CNI.

Sovrimpressione di Azure CNI

La sovrimpressione CNI di Azure è progettata per risolvere la carenza di indirizzi IP e semplificare la configurazione di rete. È adatto per scenari in cui è sufficiente aumentare fino a 1000 nodi e 250 pod per nodo e un hop aggiuntivo per la connettività dei pod è accettabile. I requisiti in uscita del servizio Azure Kubernetes possono essere soddisfatti anche con la sovrimpressione CNI di Azure.

Per un riepilogo dei casi d'uso consigliati per ogni modello di rete, vedere Confrontare i modelli di rete nel servizio Azure Kubernetes.

Inoltre, quando si progetta il cluster del servizio Azure Kubernetes, è importante pianificare attentamente l'indirizzamento IP e le dimensioni della subnet della rete virtuale per supportare il ridimensionamento. Per il dimensionamento rapido del cluster possono essere usati nodi virtuali, ma esistono alcune limitazioni note.

I cluster del servizio Azure Kubernetes supportano SKU Basic e Azure Load Balancer Standard e i servizi possono essere esposti con servizi di bilanciamento del carico pubblici o interni. Il servizio Azure Kubernetes usa CoreDNS per fornire la risoluzione dei nomi ai pod in esecuzione nel cluster e il traffico di rete in uscita (in uscita) può essere inviato tramite un cluster di appliance virtuale di rete o Firewall di Azure.

Per impostazione predefinita, tutti i pod in un cluster del servizio Azure Kubernetes possono inviare e ricevere traffico senza limitazioni. Tuttavia, i criteri di rete Kubernetes possono essere usati per migliorare la sicurezza e filtrare il traffico di rete tra i pod in un cluster del servizio Azure Kubernetes. Sono disponibili due modelli di criteri di rete per il servizio Azure Kubernetes: criteri di rete di Azure e Calico.

Infine, il servizio Azure Kubernetes configura un gruppo di sicurezza di rete (NSG) nella subnet in cui viene distribuito il cluster. È consigliabile non modificare manualmente questo gruppo di sicurezza di rete, ma i servizi distribuiti nel servizio Azure Kubernetes possono influenzarlo.

In generale, selezionando il modello di rete appropriato e pianificando attentamente le risorse di rete, è possibile ottimizzare le prestazioni, la sicurezza e i costi del cluster del servizio Azure Kubernetes.

Cluster privati

La visibilità IP del cluster del servizio Azure Kubernetes può essere pubblica o privata. I cluster privati espongono l'API Kubernetes su un indirizzo IP privato, ma non su uno pubblico. Questo indirizzo IP privato è rappresentato nella rete virtuale del servizio Azure Kubernetes tramite un endpoint privato. L'API Kubernetes non deve essere accessibile tramite il relativo indirizzo IP, ma tramite il nome di dominio completo (FQDN). La risoluzione dall'FQDN dell'API Kubernetes al relativo indirizzo IP viene in genere eseguita da una zona DNS privato di Azure. Questa zona DNS può essere creata da Azure nel gruppo di risorse del nodo del servizio Azure Kubernetes oppure è possibile specificare una zona DNS esistente.

Seguendo procedure comprovate su scala aziendale, la risoluzione DNS per i carichi di lavoro di Azure viene offerta dai server DNS centralizzati distribuiti nella sottoscrizione di connettività, in una rete virtuale hub o in una rete virtuale di servizi condivisi connessa a un rete WAN virtuale di Azure. Questi server risolveranno in modo condizionale i nomi pubblici e specifici di Azure usando DNS di Azure (indirizzo IP 168.63.129.16) e i nomi privati usando server DNS aziendali. Tuttavia, questi server DNS centralizzati non saranno in grado di risolvere il nome di dominio completo dell'API del servizio Azure Kubernetes fino a quando non sono connessi con la zona privata DNS creata per il cluster del servizio Azure Kubernetes. Ogni servizio Azure Kubernetes ha una zona privata DNS univoca, poiché un GUID casuale viene anteporto al nome della zona. Pertanto, per ogni nuovo cluster del servizio Azure Kubernetes, la zona DNS privata corrispondente deve essere connessa alla rete virtuale in cui si trovano i server DNS centrali.

Tutte le reti virtuali devono essere configurate per l'uso di questi server DNS centrali per la risoluzione dei nomi. Tuttavia, se la rete virtuale del servizio Kubernetes è configurata per l'uso dei server DNS centrali e questi server DNS non sono ancora connessi alla zona DNS privato, i nodi del servizio Azure Kubernetes non saranno in grado di risolvere il nome di dominio completo dell'API Kubernetes e la creazione del cluster del servizio Azure Kubernetes avrà esito negativo. La rete virtuale del servizio Azure Kubernetes deve essere configurata per l'uso dei server DNS centrali solo dopo la creazione del cluster.

Dopo aver creato il cluster, viene creata la connessione tra la zona DNS privato e la rete virtuale in cui vengono distribuiti i server DNS centrali. La rete virtuale del servizio Azure Kubernetes è stata anche configurata per l'uso dei server DNS centrali nella sottoscrizione di connettività e l'accesso amministratore all'API Kubernetes del servizio Azure Kubernetes seguirà questo flusso:

Nota

Le immagini di questo articolo riflettono una progettazione che usa il modello di connettività hub-spoke tradizionale. Le zone di destinazione di livello aziendale possono optare per un modello di connettività della rete WAN virtuale, in cui i server DNS centrali si trovano in una rete virtuale di servizi condivisi connessa a un hub della rete WAN virtuale.

1. L'amministratore risolve il nome di dominio completo dell'API Kubernetes. I server DNS locali inoltrano la richiesta ai server autorevoli: i resolver DNS in Azure. Questi server inoltrano la richiesta al server DNS di Azure (168.63.129.16), che otterrà l'indirizzo IP dalla zona DNS privato di Azure.
2. Dopo aver risolto l'indirizzo IP, il traffico verso l'API Kubernetes viene instradato dall'ambiente locale alla VPN o al gateway ExpressRoute in Azure, a seconda del modello di connettività.
3. L'endpoint privato avrà introdotto una /32 route nella rete virtuale hub. I gateway VPN e ExpressRoute inviano il traffico direttamente all'endpoint privato dell'API Kubernetes distribuito nella rete virtuale del servizio Azure Kubernetes.

Traffico dagli utenti dell'applicazione al cluster

Per esporre le applicazioni in esecuzione nei cluster del servizio Azure Kubernetes possono essere usati controller in ingresso.

• I controller in ingresso forniscono il routing a livello di applicazione con un leggero aumento della complessità.
• I controller in ingresso possono incorporare la funzionalità Web Application Firewall (WAF).
• I controller di ingresso possono essere eseguiti fuori cluster e in-cluster:
  • Un controller in ingresso esterno al cluster scarica le risorse di calcolo (ad esempio il routing del traffico HTTP o la terminazione TLS) in un altro servizio esterno al servizio Azure Kubernetes, ad esempio il componente aggiuntivo Azure Application Gateway Ingress Controller (AGIC).
  • Una soluzione interna al cluster usa le risorse del cluster del servizio Azure Kubernetes per il calcolo, ad esempio il routing del traffico HTTP o la terminazione TLS. I controller in ingresso nel cluster possono offrire costi inferiori, ma richiedono un'attenta pianificazione e manutenzione delle risorse.
• Il componente aggiuntivo di routing delle applicazioni HTTP di base è facile da usare, ma presenta alcune restrizioni, come documentato in Routing delle applicazioni HTTP.

I controller in ingresso possono esporre applicazioni e API con un indirizzo IP pubblico o privato.

• La configurazione deve essere allineata alla progettazione dei filtri in uscita per evitare il routing asimmetrico. Le route definite dall'utente possono causare potenzialmente un routing asimmetrico, ma non necessariamente. gateway applicazione possibile eseguire SNAT sul traffico, ovvero il traffico restituito torna al nodo gateway applicazione e non alla route definita dall'utente se la route definita dall'utente è configurata solo per il traffico Internet.
• Se è necessaria la terminazione TLS, occorre considerare la gestione dei certificati TLS.

Il traffico dell'applicazione può arrivare da internet locale o pubblico. L'immagine seguente descrive un esempio in cui un gateway applicazione di Azure è configurato per connessioni proxy inverso ai cluster sia dall'ambiente locale che dalla rete Internet pubblica.

Il traffico dall'ambiente locale segue il flusso dei callout blu numerati nel diagramma precedente.

1. Il client risolve il nome di dominio completo assegnato all'applicazione, usando i server DNS distribuiti nella sottoscrizione di connettività o nei server DNS locali.
2. Dopo aver risolto l'FQDN dell'applicazione in un indirizzo IP (l'indirizzo IP privato del gateway applicazione), il traffico viene instradato tramite una VPN o un gateway ExpressRoute.
3. Il routing nella subnet del gateway è configurato per inviare la richiesta al web application firewall.
4. Il web application firewall invia richieste valide al carico di lavoro in esecuzione nel cluster del servizio Azure Kubernetes.

Il gateway applicazione di Azure in questo esempio può essere distribuito nella stessa sottoscrizione del cluster del servizio Azure Kubernetes, poiché la configurazione è strettamente correlata ai carichi di lavoro distribuiti nel servizio Azure Kubernetes e viene quindi gestita dallo stesso team dell'applicazione. L'accesso da Internet segue il flusso dei callout verdi numerati nel diagramma precedente.

1. I client da Internet pubblico risolvono il nome DNS per l'applicazione mediante Gestione traffico di Azure. In alternativa, è possibile usare altre tecnologie di bilanciamento del carico globale come Frontdoor di Azure.
2. L'FQDN pubblico dell'applicazione verrà risolto da Gestione traffico all'indirizzo IP pubblico del gateway applicazione, a cui i client accedono tramite Internet pubblico.
3. Il gateway applicazione accede al carico di lavoro distribuito nel servizio Azure Kubernetes.

Nota

Questi flussi sono validi solo per le applicazioni Web. Le applicazioni non Web esulano da questo articolo e possono essere esposte tramite il Firewall di Azure nella rete virtuale dell'hub o nell'hub virtuale sicuro se si usa il modello di connettività della rete WAN virtuale.

In alternativa, è possibile creare flussi di traffico per applicazioni basate sul Web per attraversare sia il Firewall di Azure nella sottoscrizione di connettività che il web application firewall nella rete virtuale del servizio Azure Kubernetes. Questo approccio ha il vantaggio di offrire una maggiore protezione, ad esempio l'uso di un filtro basato sull'intelligence di Firewall di Azure per eliminare il traffico da indirizzi IP dannosi noti in Internet. Tuttavia, presenta anche alcuni svantaggi. Ad esempio, la perdita dell'indirizzo IP del client originale e l'ulteriore coordinamento necessario tra il firewall e i team dell'applicazione durante l'esposizione delle applicazioni. Ciò è dovuto al fatto che nel Firewall di Azure saranno necessarie regole DNAT (Destination Network Address Translation).

Traffico dai pod del servizio Azure Kubernetes a servizi back-end

I pod in esecuzione all'interno del cluster del servizio Azure Kubernetes potrebbero dover accedere a servizi back-end quali Archiviazione di Azure, database SQL di Azure o database NoSQL di Azure Cosmos DB. Gli endpoint servizio di rete virtuale e il collegamento privato possono essere usati per proteggere la connettività a questi servizi gestiti di Azure.

Se si usano endpoint privati di Azure per il traffico back-end, è possibile eseguire la risoluzione DNS per i servizi di Azure usando le zone di Azure DNS privato. Poiché i resolver DNS per l'intero ambiente si trovano nella rete virtuale hub (o nella rete virtuale dei servizi condivisi se si usa il modello di connettività della rete WAN virtuale), queste zone private devono essere create nella sottoscrizione di connettività. Per creare il record A necessario per risolvere il nome di dominio completo del servizio privato, è possibile associare la zona DNS privato (nella sottoscrizione di connettività) all'endpoint privato (nella sottoscrizione dell'applicazione). Questa operazione richiede determinati privilegi in tali sottoscrizioni.

È possibile creare manualmente i record A, ma l'associazione della zona DNS privato all'endpoint privato comporta una configurazione meno incline a errori di configurazione.

La connettività back-end dai pod del servizio Azure Kubernetes ai servizi PaaS di Azure esposti tramite endpoint privati segue questa sequenza:

1. I pod del servizio Azure Kubernetes risolvono il nome di dominio completo della piattaforma distribuita come servizio (PaaS) usando i server DNS centrali nella sottoscrizione di connettività, definiti come server DNS personalizzati nella rete virtuale del servizio Azure Kubernetes.
2. L'INDIRIZZO IP risolto è l'indirizzo IP privato degli endpoint privati a cui si accede direttamente dai pod del servizio Azure Kubernetes.

Il traffico tra i pod del servizio Azure Kubernetes e gli endpoint privati per impostazione predefinita non passerà attraverso il Firewall di Azure nella rete virtuale hub (o l'hub virtuale sicuro se si usa rete WAN virtuale), anche se il cluster del servizio Azure Kubernetes è configurato per il filtro in uscita con Firewall di Azure. Il motivo è che l'endpoint privato crea una /32 route nelle subnet della rete virtuale dell'applicazione, in cui viene distribuito il servizio Azure Kubernetes.

Suggerimenti per la progettazione

• Se i criteri di sicurezza impongono che l'API Kubernetes abbia un indirizzo IP privato anziché un indirizzo IP pubblico, distribuire un cluster del servizio Azure Kubernetes privato.
  • Usare zone DNS privato personalizzate durante la creazione di un cluster privato, anziché consentire al processo di creazione di usare una zona DNS privato del sistema.
• Usare Azure Container Networking Interface (CNI) come modello di rete, a meno che non si disponga di un intervallo limitato di indirizzi IP che possono essere assegnati al cluster del servizio Azure Kubernetes.
  • Seguire la documentazione sulla pianificazione degli indirizzi IP con CNI.
  • Per usare pool di nodi di Windows Server e nodi virtuali per verificare eventuali limitazioni, vedere le domande frequenti sul supporto per il servizio Azure Kubernetes di Windows.
• Usare Protezione DDoS di Azure per proteggere la rete virtuale usata per il cluster del servizio Azure Kubernetes, a meno che non si usi Firewall di Azure o WAF in una sottoscrizione centralizzata.
• Usare la configurazione DNS collegata alla configurazione di rete complessiva con rete WAN virtuale di Azure o architettura hub-spoke, zone DNS di Azure e la propria infrastruttura DNS.
• Usare il collegamento privato per proteggere le connessioni di rete e usare la connettività privata basata su IP ad altri servizi di Azure gestiti che supportano il collegamento privato, ad esempio Archiviazione di Azure, Registro Azure Container, Database SQL di Azure e Azure Key Vault.
• Usare un controller in ingresso per garantire sicurezza e routing HTTP avanzati e offrire un singolo endpoint per le applicazioni.
• Tutte le applicazioni Web configurate per l'uso di un ingresso devono usare la crittografia TLS e non consentire l'accesso tramite HTTP non crittografato. Questo criterio è già applicato se la sottoscrizione include i criteri consigliati in Criteri inclusi: implementazioni di riferimento delle zone di destinazione su scala aziendale.
• Facoltativamente, per conservare le risorse di calcolo e di archiviazione del cluster del servizio Azure Kubernetes, usare un controller in ingresso esterno al cluster.
  • Usare il componente aggiuntivo Azure Application Gateway Ingress Controller (AGIC), ovvero un servizio di Azure gestito di proprietà.
  • Con AGIC, distribuire un gateway di app Azure lication dedicato per ogni cluster del servizio Azure Kubernetes e non condividere lo stesso gateway applicazione tra più cluster del servizio Azure Kubernetes.
  • Se non sono presenti vincoli operativi o di risorse o AGIC non fornisce le funzionalità necessarie, usare una soluzione controller in ingresso in cluster come NGINX, Traefik o qualsiasi altra soluzione supportata da Kubernetes.
• Per le applicazioni Web interne con connessione Internet e critiche per la sicurezza, usare un web application firewall con il controller in ingresso.
  • Gateway applicazione di Azure e Frontdoor di Azure integrano entrambi Web application firewall di Azure per proteggere applicazioni basate sul Web.
• Se i criteri di sicurezza impongono l'ispezione di tutto il traffico Internet in uscita generato nel cluster del servizio Azure Kubernetes, proteggere il traffico di rete in uscita tramite Firewall di Azure o un'appliance virtuale di rete di terze parti distribuita nella rete virtuale dell'hub gestito. Per altre informazioni, vedere Limitare il traffico in uscita. Il tipo in uscita del servizio Azure Kubernetes richiede l'associazione di una tabella di route alla subnet del nodo del servizio Azure Kubernetes, quindi non può essere usata oggi con l'inserimento di route dinamico supportato da Azure rete WAN virtuale o dal server di route di Azure.
• Per i cluster non privati, usare intervalli IP autorizzati.
• Usare il livello Standard anziché il livello Basic di Azure Load Balancer.
• Quando si progetta un cluster Kubernetes in Azure, una delle considerazioni principali consiste nel selezionare il modello di rete appropriato per i requisiti specifici. servizio Azure Kubernetes (AKS) offre tre diversi modelli di rete: Kubenet, Azure CNI e Sovrimpressione CNI di Azure. Per prendere una decisione informata, è essenziale comprendere le funzionalità e le caratteristiche di ogni modello.

Per un confronto delle funzionalità tra i tre modelli di rete nel servizio Azure Kubernetes; Kubenet, Azure CNI e Azure CNI Overlay, vedere Confrontare i modelli di rete nel servizio Azure Kubernetes.