Condividi tramite

Usare funzionalità di rete kubenet con i propri intervalli di indirizzi IP nel servizio Azure Kubernetes

  • Articolo

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.

Con Azure Container Networking Interface (CNI) ogni pod ottiene un indirizzo IP dalla subnet in modo che vi si possa accedere 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 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 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.

Questo articolo illustra come usare le funzionalità di rete kubenet per creare e usare una subnet di rete virtuale per un cluster del servizio Azure Kubernetes. Per altre informazioni sulle opzioni di rete e le relative considerazioni, vedere Concetti relativi alla rete per le applicazioni nel servizio Azure Kubernetes.

Prerequisiti

  • La rete virtuale per il cluster servizio Azure Kubernetes deve consentire la connettività Internet in uscita.
  • Non creare più di un cluster servizio Azure Kubernetes nella stessa subnet.
  • 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'intervallo non può essere aggiornato dopo la creazione del cluster.
  • L'identità usata dal cluster del servizio Azure Kubernetes deve avere almeno il ruolo di Collaboratore di rete per la subnet all'interno della rete virtuale. L'interfaccia della riga di comando consente di impostare automaticamente l'assegnazione di ruolo. Se si usa un modello di ARM o altri client, è necessario impostare manualmente l'assegnazione di ruolo. Inoltre è necessario disporre delle autorizzazioni appropriate, ad esempio il proprietario della sottoscrizione, per creare un'identità del cluster e assegnarle le autorizzazioni. Se si desidera definire un ruolo personalizzato invece di usare il ruolo predefinito di Collaboratore di rete, sono necessarie le autorizzazioni seguenti:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read

Avviso

Per usare i pool di nodi di Windows Server, è necessario usare Azure CNI. Il modello di rete kubenet non è disponibile per i contenitori di Windows Server.

Operazioni preliminari

È necessario che sia installata e configurata l'interfaccia della riga di comando di Azure 2.0.65 o versione successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

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:

Modello di rete Kubenet con un cluster del servizio Azure Kubernetes

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.

Con 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 (Azure o Calico) non sono supportati con Azure CNI.

Limitazioni e considerazioni per kubenet

Nota

Alcuni pod di sistema, ad esempio konnectivity all'interno del cluster, usano l'indirizzo IP del nodo host anziché un IP dallo spazio indirizzi in sovrimpressione. I pod di sistema useranno solo l'IP del nodo e non un indirizzo IP dalla rete virtuale.

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 base /24 della subnet potrebbe supportare solo un massimo di otto nodi nel cluster. Questo numero di nodi può supportare solo fino a 240 pod, con un massimo predefinito di 30 pod per nodo.

Nota

Questi valori massimi non tengono in considerazione le operazioni di aggiornamento o ridimensionamento. In pratica, non è possibile eseguire il numero massimo di nodi supportati dall'intervallo di indirizzi IP della subnet. È necessario lasciare disponibili alcuni indirizzi IP per le operazioni di ridimensionamento o aggiornamento.

Peering di rete virtuale e connessioni ExpressRoute

Per fornire connettività locale, sia kubenet che Azure-CNI possono usare il peering di rete virtuale di Azure o le connessioni ExpressRoute. Pianificare con attenzione gli intervalli di 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 nelle subnet di rete virtuale di Azure al di fuori di questo intervallo di indirizzi, ad esempio 172.16.0.0/16.

Scegliere un modello di rete da usare

Le considerazioni seguenti sono utili per stabilire quando ogni modello di rete può essere il più appropriato:

Usare kubenet quando:

  • Lo spazio indirizzi IP è limitato.
  • La maggior parte delle comunicazioni dei pod avviene all'interno del cluster.
  • Non sono necessarie funzionalità del servizio Azure Kubernetes avanzate come i nodi virtuali o i Criteri di rete di Azure.

Usare Azure CNI quando:

  • È disponibile uno spazio indirizzi IP adeguato.
  • La maggior parte delle comunicazioni dei pod avviene con risorse esterne al cluster.
  • Non si vogliono gestire route definite dall'utente per la connettività dei pod.
  • Sono necessarie funzionalità del servizio Azure Kubernetes avanzate come i nodi virtuali o i Criteri di rete di Azure.

Per altre informazioni su come decidere quale modello di rete usare, vedere Confrontare i modelli di rete e il relativo ambito di supporto.

Creare una rete virtuale e una subnet

  1. Creare un gruppo di risorse usando il comando az group create.

    az group create --name myResourceGroup --location eastus

  2. Se non esiste già una rete virtuale e una subnet da usare, creare queste risorse di rete usando il comando az network vnet create. Il comando di esempio seguente crea una rete virtuale denominata myAKSVnet con il prefisso dell'indirizzo 192.168.0.0/16 e una subnet denominata myAKSSubnet con il prefisso dell'indirizzo 192.168.1.0/24:

    az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus

  3. Ottenere l'ID risorsa subnet usando il comando az network vnet subnet show e archiviarla come variabile denominata SUBNET_ID per usarla in seguito.

    SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

Creare un cluster del servizio Azure Kubernetes nella rete virtuale

Creare un cluster del servizio Azure Kubernetes con identità gestite assegnate dal sistema

Nota

Quando si usa l'identità assegnata dal sistema, l'interfaccia della riga di comando di Azure concede il ruolo di Collaboratore rete all'identità assegnata dal sistema dopo la creazione del cluster. Se si usa un modello di ARM o altri client, è necessario usare invece l’identità gestita assegnata dall'utente.

  • Creare un cluster del servizio Azure Kubernetes con identità gestite assegnate dal sistema usando il comando az aks create.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

    Parametri di distribuzione:

    • --service-cidr è facoltativo. Questo indirizzo viene usato per assegnare un indirizzo IP ai servizi interni nel cluster del servizio Azure Kubernetes. Questo intervallo di indirizzi IP deve essere uno spazio indirizzi non usato altrove nell'ambiente di rete, includendo intervalli di rete locali se si connette o si prevede di connettere, le reti virtuali di Azure usando Express Route o una connessione VPN da sito a sito. Il valore predefinito è 10.0.0.0/16.
    • --dns-service-ip è facoltativo. L'indirizzo deve essere l'indirizzo .10 dell'intervallo di indirizzi IP del servizio. Il valore predefinito è 10.0.0.10.
    • --pod-cidr è facoltativo. Questo indirizzo deve essere uno spazio indirizzi ampio non in uso in qualsiasi altra posizione nell'ambiente di rete. Questo intervallo include gli eventuali intervalli della rete locale se si connettono o si prevede di connettere le proprie reti virtuali di Azure tramite Express Route o connessione VPN da sito a sito. Il valore predefinito è 10.244.0.0/16.
      • Questo intervallo di indirizzi deve essere abbastanza ampio da contenere il numero di nodi in base a cui si prevede di aumentare le dimensioni. Non è possibile cambiare questo intervallo di indirizzi dopo la distribuzione del cluster.
      • L'intervallo di indirizzi IP dei pod viene usato per assegnare uno spazio indirizzi /24 a ogni nodo del cluster. Nell'esempio seguente l'intervallo --pod-cidr di 10.244.0.0/16 assegna al primo nodo 10.244.0.0/24, al secondo nodo 10.244.1.0/24 e al terzo nodo 10.244.2.0/24.
      • Quando il cluster viene ridimensionato o aggiornato, la piattaforma di Azure continua ad assegnare un intervallo di indirizzi IP dei pod a ogni nuovo nodo.

Creare un cluster del servizio Azure Kubernetes con identità gestita assegnata dall'utente

Creare un'identità gestita

  • Creare un'identità gestita usando il comando az identity. Se si dispone di un'identità gestita esistente, trovare l'ID entità usando il az identity show --ids <identity-resource-id> comando .

    az identity create --name myIdentity --resource-group myResourceGroup

    L'output dovrebbe essere simile all'output di esempio seguente:

    {                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Aggiungere un'assegnazione di ruolo per l'identità gestita

Se si usa l'interfaccia della riga di comando di Azure, il ruolo viene aggiunto automaticamente ed è possibile ignorare questo passaggio. Se si usa un modello di ARM o altri client, per eseguire un'assegnazione di ruolo è necessario usare l'ID dell’entità sicurezza dell’identità gestita del cluster.

  • Ottenere l'ID risorsa di rete virtuale usando il comando az network vnet show e archiviarla come variabile denominata VNET_ID.

    VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

  • Assegnare l'identità gestita per le autorizzazioni di Collaboratore di rete del cluster del servizio Azure Kubernetes nella rete virtuale usando il comando az role assignment create e specificare <principalId>.

    az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Nota

Per l’inserimento dei dati, l'autorizzazione concessa all'identità gestita del cluster usata da Azure può richiedere fino a 60 minuti.

Creare un cluster del servizio Azure Kubernetes

  • Creare un cluster del servizio Azure Kubernetes usando il comando az aks create e specificare l'ID risorsa identità gestita del piano di controllo per l'argomento assign-identity, al fine di assegnare l'identità gestita assegnata dall'utente.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

Quando si crea un cluster del servizio Azure Kubernetes, vengono creati automaticamente un gruppo di sicurezza di rete e una tabella di route. Queste risorse di rete vengono gestite dal piano di controllo del servizio Azure Kubernetes. Il gruppo di sicurezza di rete viene associato automaticamente alle NIC virtuali nei nodi. La tabella di route viene associata automaticamente alla subnet della rete virtuale. Le regole del gruppo di sicurezza di rete e le tabelle di route vengono aggiornate automaticamente durante la creazione e l'esposizione dei servizi.

Portare la propria subnet e la tabella di route con kubenet

Con kubenet, nelle subnet del cluster deve esistere una tabella di route. Il servizio Azure Kubernetes supporta l'uso di una subnet e di una tabella di route esistenti. Se la subnet personalizzata non contiene una tabella di route, il servizio Azure Kubernetes ne crea automaticamente una e aggiunge le regole in tutto il ciclo di vita del cluster. Se la subnet personalizzata contiene una tabella di route quando si crea il cluster, il servizio Azure Kubernetes riconosce la tabella di route esistente durante le operazioni del cluster e aggiunge/aggiorna le regole di conseguenza per le operazioni del provider cloud.

Avviso

È possibile aggiungere/aggiornare le regole personalizzate nella tabella di route personalizzata. Tuttavia, le regole vengono aggiunte dal provider di servizi cloud Kubernetes, e non possono essere aggiornate o rimosse. Le regole tipo 0.0.0.0/0 devono esistere sempre in una determinata tabella di route ed eseguire il mapping alla destinazione del gateway Internet, ad esempio un'Appliance virtuale di rete o un altro gateway in uscita. Pertanto l’aggiornamento delle regole richiede cautela.

Altre informazioni sulla configurazione di una tabella di route personalizzata.

La rete Kubenet richiede regole della tabella di route organizzate per instradare correttamente le richieste. Per questo, le tabelle di route devono essere gestite attentamente per ogni cluster che si basa su di essa. Più cluster non possono condividere una tabella di route perché i CIDR dei pod di cluster diversi potrebbero sovrapporsi, causando scenari di routing imprevisti e interrotti. Se si configurano più cluster nella stessa rete virtuale o si dedica una rete virtuale a ogni cluster, considerare le limitazioni seguenti:

  • Prima di creare il cluster del servizio Azure Kubernetes, è necessario associare alla subnet una tabella di route personalizzata.
  • La risorsa della tabella di route associata non può essere aggiornata successivamente alla creazione del cluster. Tuttavia, è possibile modificare le regole personalizzate nella tabella di route.
  • Ogni cluster del servizio Azure Kubernetes deve usare una singola tabella di route univoca per tutte le subnet associate al cluster. A causa della possibilità di sovrapposizione dei CIDR di pod e di conflitti delle regole di gestione, non è possibile riutilizzare una tabella di route con più cluster.
  • Per l'identità gestita assegnata dal sistema, è possibile solo fornire la propria subnet e la propria tabella di route tramite l'interfaccia della riga di comando di Azure in quanto questa aggiunge automaticamente l'assegnazione di ruolo. Se si usa un modello di ARM o altri client, è necessario usare un'identità gestita assegnata dall'utente, assegnare autorizzazioni prima della creazione del cluster e assicurarsi che l'identità assegnata dall'utente disponga delle autorizzazioni di scrittura per la subnet personalizzata e la tabella di route personalizzata.
  • L'uso della stessa tabella di route con più cluster del servizio Azure Kubernetes non è supportato.

Nota

Quando si crea e si usa la propria rete virtuale e la tabella di route con il plug-in di rete kubenet, è necessario configurare un'identità gestita assegnata dall'utente per il cluster. Con un'identità gestita assegnata dal sistema, non è possibile recuperare l'ID identità prima di creare un cluster, causando un ritardo durante l'assegnazione di ruolo.

Quando si crea e si usa la propria rete virtuale e la tabella di route con il plug-in di rete di Azure sono supportate sia le identità gestite assegnate dal sistema sia quelle assegnate dall'utente. Per gli scenari BYO è consigliabile usare un'identità gestita assegnata dall'utente.

Aggiungere una tabella di route con un'identità gestita assegnata dall'utente al cluster del servizio Azure Kubernetes

Una volta che la tabella di route personalizzata sia stata creata e associata a una subnet nella rete virtuale, è possibile creare un nuovo cluster del servizio Azure Kubernetes specificando la propria tabella di route con un'identità gestita assegnata dall'utente. È necessario usare l'ID subnet per il percorso in cui si prevede di distribuire il cluster del servizio Azure Kubernetes. Questa subnet inoltre deve essere associata alla tabella di route personalizzata.

  1. Ottenere l'ID subnet usando il comando az network vnet subnet list.

    az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

  2. Creare un cluster del servizio Azure Kubernetes con una subnet personalizzata preconfigurato con una tabella di route usando il az aks create comando e specificando i valori per i --vnet-subnet-id parametri e --assign-identity .

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys

Passaggi successivi

Questo articolo ha descritto come distribuire il cluster del servizio Azure Kubernetes nella subnet di rete virtuale esistente. A questo punto, è possibile iniziare a creare nuove app usando Helm o distribuire app esistenti usando Helm.