Condividi tramite


Distribuire un cluster Kubernetes in una rete virtuale personalizzata nell'hub di Azure Stack

È possibile distribuire un cluster Kubernetes usando il motore servizio Azure Kubernetes (AKS) in una rete virtuale personalizzata. Questo articolo esamina le informazioni necessarie nella rete virtuale. È possibile trovare i passaggi per calcolare gli indirizzi IP usati dal cluster, impostare le vales nel modello API e impostare la tabella di route e il gruppo di sicurezza di rete.

Il cluster Kubernetes nell'hub di Azure Stack usando il motore del servizio Azure Kubenet usa il plug-in di rete kubenet. Il motore del servizio Azure Kubernetes nell'hub di Azure Stack supporta anche il plug-in di rete Azure CNI.

Vincoli durante la creazione di una rete virtuale personalizzata

  • La rete virtuale personalizzata deve trovarsi nella stessa sottoscrizione di tutti gli altri componenti del cluster Kubernetes.
  • Il pool di nodi del piano di controllo e il pool di nodi agente devono trovarsi nella stessa rete virtuale. È possibile distribuire i nodi in subnet diverse all'interno della stessa rete virtuale.
  • La subnet del cluster Kubernetes deve usare un intervallo IP all'interno dello spazio dell'intervallo IP della rete virtuale personalizzata. Vedere Ottenere il blocco di indirizzi IP.
  • Si consideri che le dimensioni consigliate delle subnet del nodo dipendono dal tipo di plug-in di rete in uso. Come linea guida generale, Azure CNI richiede un numero maggiore di indirizzi IP per la subnet che supporta i pool di nodi dell'agente rispetto a kubenet. Vedere gli esempi kubenet e Azure CNI seguenti.
  • Lo 169.254.0.0/16 spazio indirizzi non può essere usato per le reti virtuali personalizzate per i cluster Kubernetes.

Creare una rete virtuale personalizzata

È necessario avere una rete virtuale personalizzata nell'istanza dell'hub di Azure Stack. Per altre informazioni, vedere Avvio rapido: Creare una rete virtuale usando il portale di Azure.

Creare una nuova subnet nella rete virtuale. Sarà necessario ottenere l'ID risorsa della subnet e l'intervallo di indirizzi IP. Quando si distribuisce il cluster, si useranno l'ID risorsa e l'intervallo nel modello API.

  1. Aprire il portale utente dell'hub di Azure Stack nell'istanza dell'hub di Azure Stack.

  2. Selezionare Tutte le risorse.

  3. Immettere il nome della rete virtuale nella casella di ricerca.

  4. Selezionare Subnet>e subnet per aggiungere una subnet.

  5. Aggiungere un nome e un intervallo di indirizzi usando la notazione CIDR. Selezionare OK.

  6. Selezionare Proprietà nel pannello Reti virtuali . Copiare l'ID risorsa e quindi aggiungere /subnets/<nameofyoursubnect>. Questo valore verrà usato come valore per la vnetSubnetId chiave nel modello API per il cluster. L'ID risorsa per la subnet usa il formato seguente:
    /subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    ID risorsa di rete virtuale

  7. Selezionare Subnet nel pannello Reti virtuali . Selezionare il nome della subnet, ad esempio control-plane-sn.

    Non associare la subnet a un gruppo di sicurezza di rete.Do not associate the subnet to a network security group (NSG).

    blocco CIDR della rete virtuale

  8. Nel pannello della subnet prendere nota dell'intervallo di indirizzi (blocco CIDR) di ogni subnet.

Considerazioni sulla selezione di uno spazio indirizzi

Quando si crea una rete virtuale personalizzata, si specifica lo spazio indirizzi IP della rete e un intervallo di indirizzi IP per ogni subnet. Quando si scelgono gli spazi indirizzi e gli intervalli da usare nel cluster Kubernetes, tenere presenti i fattori seguenti:

  • Gli spazi di indirizzi sovrapposti possono causare conflitti di indirizzi IP o errori di comunicazione. Per ridurre il rischio di sovrapposizione degli indirizzi IP, scegliere uno spazio indirizzi univoco per la nuova rete virtuale.
  • Gli spazi indirizzi negli 10/8intervalli , 172.16/12e 192.168/16 vengono spesso usati per le reti private e possono essere usati dall'infrastruttura del data center esistente. Se le applicazioni Kubernetes usano risorse nel data center, ridurre il rischio di conflitti scegliendo uno spazio indirizzi per la rete virtuale personalizzata diversa dallo spazio indirizzi del data center.
  • È consigliabile usare una subnet dedicata per il cluster Kubernetes.
  • Se si usano più reti virtuali esistenti, è consigliabile usare spazi indirizzi diversi in ogni rete se si intende usare il peering di rete virtuale. La sovrapposizione degli spazi indirizzi può compromettere la capacità di abilitare il peering.

Ottenere i blocchi di indirizzi IP

Il motore del servizio Azure Kubernetes supporta la distribuzione in una rete virtuale esistente. Quando viene distribuita in una rete virtuale esistente, il cluster usa blocchi di indirizzi consecutivi per i nodi dell'agente, i nodi del piano di controllo, i servizi cluster e i contenitori (pod). Ogni blocco di indirizzi può essere convertito in una subnet all'interno della rete virtuale. Tutti i blocchi di indirizzi nella distribuzione del cluster devono far parte dello spazio indirizzi complessivo della rete virtuale. La scelta dei blocchi di indirizzi all'esterno dello spazio indirizzi della rete virtuale può causare problemi di connettività.

Quando si configura un cluster Kubernetes sono necessari almeno tre blocchi di indirizzi:

  • Blocco di indirizzi dei nodi: si tratta del blocco di indirizzi usato per l'assegnazione di indirizzi ai nodi del cluster. Può trattarsi di un singolo blocco di indirizzi per tutti i nodi del cluster o può essere blocchi separati (subnet) per il piano di controllo e i pool di agenti. Prendere in considerazione il numero di nodi nel cluster quando si seleziona l'intervallo di indirizzi per questo blocco. Per i nodi e i contenitori CNI di Azure ottengono gli indirizzi dallo stesso blocco di indirizzi tenendo quindi in considerazione il numero di contenitori da distribuire nel cluster quando si sceglie l'intervallo di indirizzi quando si usa Azure CNI.
  • Blocco di indirizzi dei servizi: si tratta del blocco di indirizzi da cui i servizi distribuiti nel cluster Kubernetes otterranno l'indirizzo del cluster. Prendere in considerazione il numero massimo di servizi che si intende eseguire nel cluster quando si seleziona l'intervallo di indirizzi per questo blocco.
  • Blocco di indirizzi del cluster: si tratta del blocco di indirizzi da cui i pod otterranno l'indirizzo del cluster. Prendere in considerazione il numero massimo di pod che si intende eseguire nel cluster quando si seleziona l'intervallo di indirizzi per questo blocco. Come accennato in precedenza, per Azure CNI i blocchi di indirizzi del cluster e dei nodi sono gli stessi.

Oltre ai blocchi di indirizzi, per i nodi del piano di controllo sarà necessario impostare altri due valori. Sarà necessario conoscere il numero di indirizzi IP che sarà necessario riservare per il cluster e il primo indirizzo IP statico consecutivo all'interno dello spazio IP della subnet. Il motore del servizio Azure Kubernetes richiede un intervallo di un massimo di 16 indirizzi IP inutilizzati quando si usano più nodi del piano di controllo. Il cluster userà un indirizzo IP per ogni piano di controllo fino a cinque nodi del piano di controllo. Il motore del servizio Azure Kubernetes richiederà anche il successivo indirizzo IP 10 dopo l'ultimo nodo del piano di controllo per la prenotazione dell'indirizzo IP headroom. Infine, un altro indirizzo IP verrà usato dal servizio di bilanciamento del carico dopo i nodi del piano di controllo e la prenotazione headroom, per un totale di 16. Quando si posiziona il blocco di indirizzi IP, la subnet richiede le allocazioni seguenti degli indirizzi IP esistenti:

  • I primi quattro indirizzi IP e l'ultimo indirizzo IP sono riservati e non possono essere usati in alcuna subnet di Azure.
  • Un buffer di 16 indirizzi IP deve essere lasciato aperto.
  • Il valore del primo indirizzo IP del cluster deve essere verso la fine dello spazio indirizzi per evitare conflitti IP. Se possibile, assegnare la firstConsecutiveStaticIP proprietà a un indirizzo IP vicino alla fine dello spazio indirizzi IP disponibile nella subnet.

Ad esempio, per un cluster con tre nodi del piano di controllo. Se si usa una subnet con 256 indirizzi, ad esempio 10.100.0.0/24, sarà necessario impostare il primo indirizzo IP statico consecutivo prima della versione 239. La tabella seguente illustra gli indirizzi e le considerazioni:

Intervallo per la subnet /24 Numero Nota
172.100.0.0 - 172.100.0.3 4 Riservato nella subnet di Azure.
172.100.0.224-172.100.0.238 14 Numero di indirizzi IP per un cluster definito dal motore del servizio Azure Kubernetes.

3 indirizzi IP per 3 nodi del piano di controllo
10 indirizzi IP per la sala testata
1 Indirizzo IP per il servizio di bilanciamento del carico
172.100.0.238 - 172.100.0.254 16 16 buffer di indirizzi IP.
172.100.0.255 1 Riservato nella subnet di Azure.

In questo esempio la firstConsecutiveStaticIP proprietà sarà 172.100.0.224.

Per le subnet più grandi, ad esempio /16 con più di 60 mila indirizzi, potrebbe non essere utile impostare le assegnazioni IP statiche alla fine dello spazio di rete. Impostare l'intervallo di indirizzi IP statici del cluster rispetto ai primi 24 indirizzi nello spazio IP in modo che il cluster possa essere resiliente quando si dichiarano indirizzi.

Esempio di blocchi di indirizzi Kubenet

Nell'esempio seguente è possibile osservare in che modo queste varie considerazioni consentono di compilare lo spazio degli indirizzi nella rete virtuale per un cluster usando il plug-in di rete kubenet con subnet dedicate per il nodo del piano di controllo e i pool di nodi agente con tre nodi per pool.

Spazio indirizzi della rete virtuale: 10.100.0.0/16.

Blocco di indirizzi (subnet) CIDR Intervallo IP Conteggio IP (disponibile)
Blocco dei nodi del piano di controllo 10.100.0.0/24 10.100.0.0 - 10.100.0.255 255 - 4 riservato = 251
Blocco dei nodi dell'agente 10.100.1.0/24 10.100.1.0 - 10.100.1.255 255 - 4 riservato = 251
Blocco di servizi 10.100.16.0/20 10.100.16.0 - 10.100.31.255 4.096 - 5 riservato = 4.091
Blocco del cluster 10.100.128.0/17 10.100.128.0 - 10.100.255.255 32.768 - 5 riservato = 32.763

In questo esempio la firstConsecutiveStaticIP proprietà sarà 10.100.0.239.

Esempio di blocchi di indirizzi CNI di Azure

Nell'esempio seguente è possibile osservare in che modo queste varie considerazioni consentono di compilare lo spazio degli indirizzi nella rete virtuale per un cluster usando il plug-in di rete CNI di Azure con subnet dedicate per il piano di controllo e i pool di nodi agente con tre nodi per pool.

Spazio indirizzi della rete virtuale: 172.24.0.0/16.

Nota

Nell'ambiente, se l'intervallo IP pubblico è compreso in CIDR10.0.0.0/8, usare kubenet come plug-in di rete.

Blocco di indirizzi (subnet) CIDR Intervallo IP Conteggio IP (disponibile)
Blocco dei nodi del piano di controllo 172.24.0.0/24 172.24.0.0 - 172.24.0.255 255 - 4 riservato = 251
Nodi dell'agente & blocco del cluster 172.24.128.0/17 172.24.128.0 - 172.24.255.255 32.768 - 5 riservato = 32.763
Blocco di servizi 172.24.16.0/20 172.24.16.0 - 172.24.31.255 4.096 - 5 riservato = 4.091

In questo esempio la firstConsecutiveStaticIP proprietà sarà 172.24.0.239.

Aggiornare il modello API

Aggiornare il modello API usato per distribuire il cluster dal motore del servizio Azure Kubernetes alla rete virtuale personalizzata.

In masterProfile impostare i valori seguenti:

Campo Esempio Descrizione
vnetSubnetId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn Specificare l'ID percorso Resource Manager di Azure nella subnet. Questo valore esegue il mapping al blocco di indirizzi dei nodi del piano di controllo precedente.
firstConsecutiveStaticIP 10.100.0.239 Assegnare alla firstConsecutiveStaticIP proprietà di configurazione un indirizzo IP che si trova vicino alla fine dello spazio indirizzi IP disponibile nella subnet desiderata. firstConsecutiveStaticIP si applica solo al pool di nodi del piano di controllo.

In agentPoolProfiles impostare i valori seguenti:

Campo Esempio Descrizione
vnetSubnetId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn Specificare l'ID percorso Resource Manager di Azure nella subnet. Questo valore esegue il mapping al blocco di indirizzi dei nodi dell'agente precedente.

In orchestratorProfile trovare kubernetesConfig e impostare il valore seguente:

Campo Esempio Descrizione
clusterSubnet 10.100.128.0/17 Subnet IP usata per l'allocazione di indirizzi IP per le interfacce di rete dei pod. Questo valore viene mappato al blocco di indirizzi del cluster precedente. La subnet deve trovarsi nello spazio indirizzi della rete virtuale. Con Azure CNI abilitato, il valore predefinito è 10.240.0.0/12. Senza Azure CNI, il valore predefinito è 10.244.0.0/16. Usare invece la subnet /16 /24. Se si usa /24, questa subnet verrà assegnata a un solo nodo. L'altro nodo non riceverà l'assegnazione della rete POD, perché lo spazio IP sarà esaurito, quindi non sarà pronto nel cluster.
serviceCidr 10.100.16.0/20 Subnet IP usata per l'allocazione di indirizzi IP per i servizi distribuiti nel cluster. Questo valore viene mappato al blocco di servizi cluster precedente.
dnsServiceIP 10.100.16.10 Indirizzo IP da assegnare al servizio DNS del cluster. L'indirizzo deve provenire dalla subnet serviceCidr. Questo valore deve essere impostato quando si specifica serviceCidr. Il valore predefinito è l'indirizzo 10 della subnet serviceCidr.

Ad esempio, se si usa kubenet:
Con uno spazio indirizzi di rete di 10.100.0.0/16 dove la subnet per control-plane-sn è 10.100.0.0/24 e agents-sn è 10.100.1.0/24

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "10.100.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "10.100.128.0/17",
    "serviceCidr": "10.100.16.0/20",
    "dnsServiceIP" : "10.100.16.10",

    ...
  },

Ad esempio, se si usa Azure CNI:
Con uno spazio indirizzi di rete di 172.24.0.0/16 dove la subnet per control-plane-sn è 172.24.0.0/24 e k8s-sn è 172.24.128.0/17

"masterProfile": {
  ...
  "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
  "firstConsecutiveStaticIP": "172.24.0.239",
  ...
},
...
"agentPoolProfiles": [
  {
    ...
    "vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/k8s-sn",
    ...
  },
    ...
"kubernetesConfig": [
  {
    ...
    "clusterSubnet": "172.24.128.0/17",
    "serviceCidr": "172.24.16.0/20",
    "dnsServiceIP" : "172.24.16.10",
    ...
  },

Distribuire il cluster

Dopo aver aggiunto i valori al modello API, è possibile distribuire il cluster dal computer client usando il comando nel motore del deploy servizio Azure Kubernetes. Per istruzioni, vedere Distribuire un cluster Kubernetes.

Impostare la tabella di route

Se si usa kubenet, ad esempio : networkPluginkubenet nell'oggetto di configurazione del kubernetesConfig modello API. Dopo aver distribuito il cluster, tornare alla rete virtuale nel portale utenti di Azure Stack. Impostare sia la tabella di route che il gruppo di sicurezza di rete (NSG) nel pannello della subnet. Dopo aver distribuito un cluster nella rete virtuale personalizzata, ottenere l'ID della risorsa Tabella di route dal pannello Rete nel gruppo di risorse del cluster.

  1. Aprire il portale utente dell'hub di Azure Stack nell'istanza dell'hub di Azure Stack.

  2. Selezionare Tutte le risorse.

  3. Immettere il nome della rete virtuale nella casella di ricerca.

  4. Selezionare Subnet e quindi selezionare il nome della subnet che contiene il cluster.

    tabella di route e gruppo di sicurezza di rete

  5. Selezionare Tabella route e quindi selezionare la tabella di route per il cluster.

  6. Assicurarsi che questa operazione venga eseguita per ogni subnet specificata nel modello API, inclusa la masterProfile subnet.

Nota

Una rete virtuale personalizzata per il cluster Windows Kubernetes presenta un problema noto.

Passaggi successivi