Interfacce CNI (Container Networking Interface) legacy del servizio Azure Kubernetes

Nel servizio Azure Kubernetes, mentre Azure CNI Overlay e la subnet del pod di Azure CNI sono consigliate per la maggior parte degli scenari, i modelli di rete legacy come la subnet del nodo di Azure CNI e kubenet sono ancora disponibili e supportati. Questi modelli legacy offrono approcci diversi alla gestione e alla rete degli indirizzi IP dei pod, ognuno associato a specifiche considerazioni e set di funzionalità. Questo articolo offre una panoramica di queste opzioni di rete legacy e ne illustra in dettaglio i prerequisiti, i parametri di distribuzione e le caratteristiche principali, per comprendere i ruoli e come usarli in modo efficace all'interno dei cluster del servizio Azure Kubernetes.

Prerequisiti

Per la subnet del nodo di Azure CNI e kubenet sono necessari i prerequisiti seguenti:

• La rete virtuale per il cluster servizio Azure Kubernetes deve consentire la connettività Internet in uscita.

• I cluster del servizio Azure Kubernetes non possono usare 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 o 192.0.2.0/24 per l'intervallo di indirizzi del servizio Kubernetes, per l'intervallo di indirizzi del pod o per l'intervallo di indirizzi della rete virtuale del cluster.

• L'identità usata dal cluster del servizio Azure Kubernetes deve avere almeno autorizzazioni di Collaboratore di rete per la subnet all'interno della rete virtuale. Se si vuole definire un ruolo personalizzato invece di usare il ruolo predefinito Collaboratore di rete, sono necessarie le autorizzazioni seguenti:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write

• La subnet assegnata al pool di nodi del servizio Azure Kubernetes non può essere una subnet delegata.

• Il servizio Azure Kubernetes non applica i gruppi di sicurezza di rete (NSG) alla relativa subnet e non modifica alcun gruppo di sicurezza di rete associato a tale subnet. Se si specifica la propria subnet e si aggiungono i gruppi di sicurezza di rete associati a tale subnet, assicurarsi che le regole di sicurezza nei gruppi di sicurezza di rete consentano il traffico all'interno dell'intervallo CIDR del nodo. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Subnet del nodo di Azure CNI

Con Azure Container Networking Interface (CNI) ogni pod ottiene un indirizzo IP dalla subnet in modo che vi si possa accedere direttamente. I sistemi nella stessa rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del pod come indirizzo di origine per qualsiasi traffico proveniente dal pod. I sistemi esterni alla rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del nodo come indirizzo di origine per qualsiasi traffico proveniente dal pod. Questi indirizzi IP devono essere univoci nello spazio di indirizzi della rete e devono essere pianificati in anticipo. Ogni nodo ha un parametro di configurazione per il numero massimo di pod che supporta. Il numero equivalente di indirizzi IP per nodo viene quindi riservato anticipatamente per tale nodo. Questo approccio richiede una maggiore pianificazione e spesso conduce all'esaurimento degli indirizzi IP o alla necessità di riconfigurare i cluster in una subnet di dimensioni maggiori man mano che aumentano le richieste dell'applicazione.

Con la subnet del nodo di Azure CNI, ogni pod riceve un indirizzo IP nella subnet IP e può comunicare direttamente con altri pod e servizi. I cluster possono avere le stesse dimensioni dell'intervallo di indirizzi IP specificato. Questo intervallo di indirizzi IP deve però essere pianificato in anticipo e tutti gli indirizzi IP vengono utilizzati dai nodi del servizio Azure Kubernetes in base al numero massimo di pod che possono supportare. Le funzionalità e gli scenari di rete avanzati come i nodi virtuali o i criteri di rete (di Azure o Calico) non sono supportati con Azure CNI.

Parametri di distribuzione

Quando si crea un cluster servizio Azure Kubernetes, per la rete Azure CNI i parametri seguenti sono configurabili:

Rete virtuale: rete virtuale in cui si vuole distribuire il cluster Kubernetes. È possibile creare una nuova rete virtuale oppure usarne una esistente. Se si vuole usare una rete virtuale esistente, assicurarsi che si trovi nella stessa posizione e nella stessa sottoscrizione di Azure del cluster Kubernetes. Per altre informazioni su limiti e quote per una rete virtuale di Azure, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.

Subnet: subnet nella rete virtuale in cui si vuole distribuire il cluster. È possibile aggiungere nuove subnet nella rete virtuale durante il processo di creazione del cluster. Per la connettività ibrida, l'intervallo di indirizzi non deve sovrapporsi ad altre reti virtuali dell'ambiente in uso.

Plug-in di rete di Azure: quando si usa il plug-in di rete di Azure, non è possibile accedere al servizio LoadBalancer interno con "externalTrafficPolicy=Local" dalle macchine virtuali con un indirizzo IP in clusterCIDR che non appartiene al cluster del servizio Azure Kubernetes.

Intervallo di indirizzi del servizio Kubernetes: questo parametro è il set di indirizzi IP virtuali che Kubernetes assegna ai servizi interni nel cluster. Questo intervallo non può essere aggiornato dopo la creazione del cluster. È possibile usare qualsiasi intervallo di indirizzi privati che soddisfi i requisiti seguenti:

• Non deve essere compreso nell'intervallo di indirizzi IP della rete virtuale del cluster.
• Non deve sovrapporsi ad altre reti virtuali con cui la rete virtuale del cluster effettua il peering.
• Non deve sovrapporsi ad IP locali.
• Non deve essere compreso negli intervalli 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 o 192.0.2.0/24.

Anche se è possibile specificare un intervallo di indirizzi del servizio all'interno della stessa rete virtuale del cluster, non è consigliabile. Gli intervalli IP sovrapposti possono comportare un comportamento imprevedibile. Per altre informazioni, vedere la sezione Domande frequenti. Per altre informazioni sui servizi Kubernetes, vedere Services (Servizi) nella documentazione di Kubernetes.

Kubernetes DNS service IP address (Indirizzo IP del servizio DNS Kubernetes): indirizzo IP per il servizio DNS del cluster. Questo indirizzo deve essere compreso nell'intervallo degli indirizzi del servizio Kubernetes. Non usare il primo indirizzo IP nell'intervallo di indirizzi. Il primo indirizzo nell'intervallo della subnet è usato per l'indirizzo kubernetes.default.svc.cluster.local.

Kubenet

I cluster del servizio Azure Kubernetes usano kubenet e creano per modalità predefinita una rete virtuale e una subnet di Azure. Con kubenet i nodi ottengono un indirizzo IP dalla subnet della rete virtuale di Azure. I pod ricevono un indirizzo IP da uno spazio indirizzi logicamente diverso per la subnet della rete virtuale di Azure dei nodi. Network Address Translation (NAT) viene quindi configurata in modo che i pod possano raggiungere le risorse nella rete virtuale di Azure. L'indirizzo IP di origine del traffico viene convertito tramite NAT nell'indirizzo IP primario del nodo. Questo approccio riduce notevolmente il numero di indirizzi IP che è necessario riservare nello spazio della rete per i pod da utilizzare.

È possibile configurare il numero massimo di pod distribuibili in un nodo in fase di creazione del cluster o durante la creazione di nuovi pool di nodi. Se quando si creano nuovi pool di nodi non si specifica maxPods, si riceve un valore predefinito pari a 110 per kubenet.

Panoramica delle funzionalità di rete kubenet con la propria subnet

In molti ambienti sono state definite reti virtuali e subnet con intervalli di indirizzi IP allocati e si usano queste risorse per supportare più servizi e applicazioni. Per fornire connettività di rete, i cluster del servizio Azure Kubernetes possono usare kubenet (funzionalità di rete di base) o Azure CNI (funzionalità di rete avanzate).

Con kubenet solo i nodi ricevono un indirizzo IP nella subnet della rete virtuale. I pod non possono comunicare tra loro direttamente. Invece, per la connettività tra i pod nei vari nodi vengono usati il routing definito dall'utente (UDR) e l’handle per l'inoltro di indirizzi IP. Le UDR e la configurazione dell'inoltro IP vengono create e gestite dal servizio Azure Kubernetes per impostazione predefinita; tuttavia se si desidera, è possibile usare una propria tabella di route per la gestione delle route personalizzate. Si potrebbero anche distribuire i pod con un servizio che riceve un indirizzo IP assegnato e bilancia il carico del traffico dell'applicazione. Il diagramma seguente mostra che i nodi del servizio Azure Kubernetes ricevono un indirizzo IP nella subnet della rete virtuale, mentre i pod non lo ricevono:

Azure supporta un massimo di 400 route in una route definita dall'utente, quindi un cluster del servizio Azure Kubernetes non può avere più di 400 nodi. I nodi virtuali del servizio Azure Kubernetes e i Criteri di rete di Azure non sono supportati con kubenet. Sono supportati i Criteri di rete Calico.

Limitazioni e considerazioni per kubenet

• Nella progettazione di kubenet è necessario un hop aggiuntivo, che aggiunge una latenza minima alla comunicazione dei pod.
• Le tabelle di route e le route definite dall'utente sono necessarie per l'uso di kubenet e ciò aggiunge complessità alle operazioni.
  • Per altre informazioni, vedere Personalizzare l'uscita del cluster con una tabella di route definita dall'utente nel servizio Azure Kubernetes e Personalizzare l’uscita del cluster con i tipi in uscita nel servizio Azure Kubernetes.
• L'indirizzamento diretto dei pod non è supportato per kubenet a causa della progettazione di kubenet.
• A differenza dei cluster Azure CNI, più cluster kubenet non possono condividere una subnet.
• Il servizio Azure Kubernetes non applica gruppi di sicurezza di rete (NSG) alla sua subnet e non modifica i NSG associati a tale subnet. Se si specifica la propria subnet e si aggiungono NSG associati a questa subnet, è necessario assicurarsi che le regole di sicurezza negli NSG consentano il traffico tra il nodo e il CIDR del pod. Per informazioni dettagliate, vedere Gruppi di sicurezza di rete.
• Le funzionalità non supportate in kubenet includono:
  • Criteri di rete di Azure
  • Pool di nodi Windows
  • Componente aggiuntivo nodi virtuali

Disponibilità ed esaurimento degli indirizzi IP

Un problema comune con Azure CNI è che l'intervallo di indirizzi IP assegnati è troppo piccolo per potervi aggiungere in seguito altri nodi, al momento di scalare o aggiornare un cluster. Il team di rete inoltre potrebbe non essere in grado di rendere disponibile un intervallo di indirizzi IP abbastanza ampio da supportare le esigenze dell'applicazione previste. Come compromesso, è possibile creare un cluster del servizio Azure Kubernetes che usa kubenet e connettersi a una subnet di rete virtuale esistente. Questo approccio fa sì che i nodi ricevano indirizzi IP definiti, senza dover riservare anticipatamente un numero elevato di indirizzi IP per tutti i potenziali pod che potrebbero essere eseguiti nel cluster.

kubenet consente di usare un intervallo di indirizzi IP molto più ridotto ed essere in grado di supportare cluster di grandi dimensioni e più richieste delle applicazioni. Ad esempio, con un intervallo di indirizzi IP /27 nella subnet, è possibile eseguire un cluster di nodi da 20 a 25 con spazio sufficiente per ridimensionare o aggiornare. Queste dimensioni del cluster possono supportare fino a 2.200-2.750 pod (con un valore massimo predefinito di 110 pod per nodo). Il numero massimo di pod per nodo che è possibile configurare con kubenet nel servizio Azure Kubernetes è 250.

I seguenti calcoli di base mettono a confronto la differenza nei modelli di rete:

• kubenet: un intervallo di indirizzi IP /24 semplice può supportare fino a 251 nodi nel cluster. Ogni subnet di rete virtuale di Azure riserva i primi tre indirizzi IP per le operazioni di gestione. Questo numero di nodi può supportare fino a 27.610 pod, con un valore massimo predefinito di 110 pod per nodo.
• Azure CNI: lo stesso intervallo di indirizzi IP di base /24 della subnet può supportare solo un massimo di 8 nodi nel cluster. Questo numero di nodi può supportare solo fino a 240 pod, con un valore massimo predefinito di 30 pod per nodo.

Peering di rete virtuale e connessioni ExpressRoute

Per fornire connettività locale è possibile usare il peering di reti virtuali di Azure o le connessioni ExpressRoute con Azure CNI e kubenet. Pianificare con attenzione gli indirizzi IP per evitare sovrapposizioni ed errori di routing del traffico. Ad esempio, molte reti locali usano un intervallo di indirizzi 10.0.0.0/8 che viene annunciato sulla connessione ExpressRoute. È consigliabile creare cluster del servizio Azure Kubernetes in subnet di rete virtuale di Azure al di fuori di questo intervallo di indirizzi, ad esempio 172.16.0.0/16.

Per altre informazioni, vedere Confrontare i modelli di rete e i relativi ambiti di supporto.

Domande frequenti sulla subnet del pod di Azure CNI

• È possibile distribuire le VM nella subnet del cluster?

  Sì, per la subnet del nodo di Azure CNI è possibile distribuire le macchine virtuali nella stessa subnet del cluster del servizio Azure Kubernetes.

• Quali indirizzi IP di origine vedono i sistemi esterni per il traffico originato in un pod abilitato per Azure CNI?

  I sistemi nella stessa rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del pod come indirizzo di origine per qualsiasi traffico proveniente dal pod. I sistemi esterni alla rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del nodo come indirizzo di origine per qualsiasi traffico proveniente dal pod. Tuttavia, per l'allocazione IP dinamica di Azure CNI, indipendentemente dal fatto che la connessione sia all'interno della stessa rete virtuale o tra più reti virtuali, l'indirizzo IP del pod è sempre l'indirizzo di origine di qualsiasi traffico proveniente dal pod. Questo avviene perché l'allocazione IP dinamica di Azure CNI implementa l'infrastruttura della rete di contenitori di Microsoft Azure, che fornisce l'esperienza end-to-end. Pertanto, elimina l'uso di ip-masq-agent, che viene ancora usato da Azure CNI tradizionale.

• È possibile configurare criteri di rete per pod?

  Sì, i criteri di rete Kubernetes sono disponibili nel servizio Azure Kubernetes. Per iniziare, vedere Proteggere il traffico tra i pod usando criteri di rete nel servizio Azure Kubernetes.

• Il numero massimo di pod distribuibili in un nodo è configurabile?

  Per impostazione predefinita, i cluster del servizio Azure Kubernetes usano kubenet e creano una rete virtuale e una subnet. Con kubenet i nodi ottengono un indirizzo IP da una subnet della rete virtuale. Il protocollo NAT (Network Address Translation) viene quindi configurato nei nodi e i pod ricevono un indirizzo IP "nascosto" dietro l'indirizzo IP del nodo. Questo approccio riduce il numero di indirizzi IP che è necessario riservare ai pod nello spazio degli indirizzi della rete.

  Con Azure Container Networking Interface (CNI) ogni pod ottiene un indirizzo IP dalla subnet in modo che vi si possa accedere direttamente. I sistemi nella stessa rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del pod come indirizzo di origine per qualsiasi traffico proveniente dal pod. I sistemi esterni alla rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del nodo come indirizzo di origine per qualsiasi traffico proveniente dal pod. Questi indirizzi IP devono essere univoci nello spazio di indirizzi della rete e devono essere pianificati in anticipo. Ogni nodo ha un parametro di configurazione per il numero massimo di pod che supporta. Il numero equivalente di indirizzi IP per nodo viene quindi riservato anticipatamente per tale nodo. Questo approccio richiede una maggiore pianificazione e spesso conduce all'esaurimento degli indirizzi IP o alla necessità di riconfigurare i cluster in una subnet di dimensioni maggiori man mano che aumentano le richieste dell'applicazione.

• È possibile distribuire le VM nella subnet del cluster?

  Sì. Ma per l'allocazione IP dinamica di Azure CNI, le macchine virtuali non possono essere distribuite nella subnet del pod.

• Quali indirizzi IP di origine vedono i sistemi esterni per il traffico originato in un pod abilitato per Azure CNI?

  I sistemi nella stessa rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del pod come indirizzo di origine per qualsiasi traffico proveniente dal pod. I sistemi esterni alla rete virtuale del cluster del servizio Azure Kubernetes vedono l'indirizzo IP del nodo come indirizzo di origine per qualsiasi traffico proveniente dal pod.

  Ma per l'allocazione IP dinamica di Azure CNI, non importa che la connessione sia all'interno della stessa rete virtuale o tra più reti virtuali, l'IP del pod è sempre l'indirizzo di origine di qualsiasi traffico dal pod. Questo avviene perché l'allocazione IP dinamica di Azure CNI implementa l'infrastruttura della rete di contenitori di Microsoft Azure, che fornisce l'esperienza end-to-end. Pertanto, elimina l'uso di ip-masq-agent, che viene ancora usato da Azure CNI tradizionale.

• È possibile usare una subnet diversa all'interno della rete virtuale del cluster per l'intervallo di indirizzi del servizio Kubernetes?

  Non è consigliabile, ma questa configurazione è possibile. L'intervallo di indirizzi del servizio è un set di indirizzi IP virtuali che Kubernetes assegna ai servizi interni nel cluster. La rete di Azure non ha visibilità sull'intervallo di indirizzi IP dei servizi del cluster Kubernetes. La mancanza di visibilità nell'intervallo di indirizzi del servizio del cluster può causare problemi. È possibile creare successivamente una nuova subnet nella rete virtuale del cluster che si sovrappone all'intervallo di indirizzi del servizio. Se si verifica una sovrapposizione di questo tipo, Kubernetes può assegnare a un servizio un indirizzo IP già usato da un'altra risorsa nella subnet, causando un comportamento imprevedibile o errori. Assicurandosi di usare un intervallo di indirizzi esterno alla rete virtuale del cluster, è possibile evitare il rischio di sovrapposizioni. Sì, quando si distribuisce un cluster con l'interfaccia della riga di comando di Azure o un modello di Gestione risorse. Consultare Numero massimo di pod per nodo.

• È possibile usare una subnet diversa all'interno della rete virtuale del cluster per l'intervallo di indirizzi del servizio Kubernetes?

  Non è consigliabile, ma questa configurazione è possibile. L'intervallo di indirizzi del servizio è un set di indirizzi IP virtuali che Kubernetes assegna ai servizi interni nel cluster. La rete di Azure non ha visibilità sull'intervallo di indirizzi IP dei servizi del cluster Kubernetes. La mancanza di visibilità nell'intervallo di indirizzi del servizio del cluster può causare problemi. È possibile creare successivamente una nuova subnet nella rete virtuale del cluster che si sovrappone all'intervallo di indirizzi del servizio. Se si verifica una sovrapposizione di questo tipo, Kubernetes può assegnare a un servizio un indirizzo IP già usato da un'altra risorsa nella subnet, causando un comportamento imprevedibile o errori. Assicurandosi di usare un intervallo di indirizzi esterno alla rete virtuale del cluster, è possibile evitare il rischio di sovrapposizioni.