Gestione del nodo e del pool di nodi Kubernetes

L'architettura kubernetes si basa su due livelli: il piano di controllo e uno o più nodi nei pool di nodi. Questo articolo descrive e confronta il modo in cui Amazon Elastic Kubernetes Service (Amazon EKS) e servizio Azure Kubernetes (AKS) gestiscono i nodi agente o di lavoro.

Sia in Amazon EKS che nel servizio Azure Kubernetes, la piattaforma cloud fornisce e gestisce il livello del piano di controllo e il cliente gestisce il livello del nodo. Il diagramma seguente illustra la relazione tra il piano di controllo e i nodi nell'architettura kubernetes del servizio Azure Kubernetes.

Gruppi di nodi gestiti di Amazon EKS

I gruppi di nodi gestiti amazon EKS automatizzano il provisioning e la gestione del ciclo di vita dei nodi di lavoro Amazon Elastic Compute Cloud (EC2) per i cluster Amazon EKS. Gli utenti di Amazon Web Services (AWS) possono usare l'utilità della riga di comando eksctl per creare, aggiornare o terminare nodi per i cluster del servizio Azure Kubernetes. Gli aggiornamenti e le terminazioni dei nodi bloccano e svuotano automaticamente i nodi per garantire che le applicazioni rimangano disponibili.

Viene eseguito il provisioning di ogni nodo gestito come parte di un gruppo Amazon EC2 Auto Scaling che Amazon EKS gestisce e controlla. Il ridimensionamento automatico del cluster Kubernetes regola automaticamente il numero di nodi di lavoro in un cluster quando i pod hanno esito negativo o vengono riprogrammati in altri nodi. Ogni gruppo di nodi può essere configurato per l'esecuzione in più zone di disponibilità all'interno di un'area.

Per altre informazioni sui nodi gestiti di Amazon EKS, vedere Creazione di un gruppo di nodi gestiti e Aggiornamento di un gruppo di nodi gestiti.

È anche possibile eseguire pod Kubernetes in AWS Fargate. Fargate offre capacità di calcolo su richiesta e di dimensioni corrette per i contenitori. Per altre informazioni su come usare Fargate con Amazon EKS, vedere AWS Fargate.

Nodi e pool di nodi del servizio Azure Kubernetes

La creazione di un cluster del servizio Azure Kubernetes crea e configura automaticamente un piano di controllo che fornisce i servizi Kubernetes di base e l'orchestrazione del carico di lavoro dell'applicazione. La piattaforma Azure fornisce il piano di controllo del servizio Azure Kubernetes senza costi come risorsa gestita di Azure. Il piano di controllo e le relative risorse esistono solo nell'area in cui è stato creato il cluster.

I nodi, detti anche nodi agente o nodi di lavoro, ospitano i carichi di lavoro e le applicazioni. Nel servizio Azure Kubernetes i clienti gestiscono e pagano completamente i nodi agente collegati al cluster del servizio Azure Kubernetes.

Per eseguire applicazioni e servizi di supporto, un cluster del servizio Azure Kubernetes necessita di almeno un nodo: Una macchina virtuale di Azure deve eseguire i componenti del nodo Kubernetes e il runtime del contenitore. Ogni cluster del servizio Azure Kubernetes deve contenere almeno un pool di nodi di sistema con almeno un nodo.

Il servizio Azure Kubernetes raggruppa i nodi della stessa configurazione in pool di nodi di macchine virtuali che eseguono carichi di lavoro del servizio Azure Kubernetes. I pool di nodi di sistema servono allo scopo principale di ospitare pod di sistema critici, ad esempio CoreDNS. I pool di nodi utente servono allo scopo principale di ospitare i pod del carico di lavoro. Se si vuole avere un solo pool di nodi nel cluster del servizio Azure Kubernetes, ad esempio in un ambiente di sviluppo, è possibile pianificare i pod dell'applicazione nel pool di nodi di sistema.

È anche possibile creare più pool di nodi utente per separare carichi di lavoro diversi in nodi diversi per evitare il problema del vicino rumoroso o per supportare applicazioni con esigenze di calcolo o archiviazione diverse.

Ogni nodo agente di un pool di nodi di sistema o utente è una macchina virtuale di cui viene effettuato il provisioning come parte di Azure set di scalabilità di macchine virtuali e gestita dal cluster del servizio Azure Kubernetes. Per altre informazioni, vedere Nodi e pool di nodi.

È possibile definire il numero iniziale e le dimensioni per i nodi del ruolo di lavoro quando si crea un cluster del servizio Azure Kubernetes o quando si aggiungono nuovi nodi e pool di nodi a un cluster del servizio Azure Kubernetes esistente. Se non si specificano dimensioni della macchina virtuale, le dimensioni predefinite sono Standard_D2s_v3 per i pool di nodi Windows e Standard_DS2_v2 per i pool di nodi Linux.

Creazione del pool di nodi

È possibile aggiungere un pool di nodi a un cluster del servizio Azure Kubernetes nuovo o esistente usando la portale di Azure, l'interfaccia della riga di comando di Azure, l'API REST del servizio Azure Kubernetes o gli strumenti di infrastruttura come codice (IaC), ad esempio Bicep, modelli di Azure Resource Manager o Terraform. Per altre informazioni su come aggiungere pool di nodi a un cluster del servizio Azure Kubernetes esistente, vedere Creare e gestire più pool di nodi per un cluster in servizio Azure Kubernetes (servizio Azure Kubernetes).

Quando si crea un nuovo pool di nodi, il set di scalabilità di macchine virtuali associato viene creato nel gruppo di risorse del nodo, un gruppo di risorse di Azure che contiene tutte le risorse dell'infrastruttura per il cluster del servizio Azure Kubernetes. Queste risorse includono i nodi Kubernetes, le risorse di rete virtuale, le identità gestite e l'archiviazione.

Per impostazione predefinita, il gruppo di risorse del nodo ha un nome come MC_<resourcegroupname>_<clustername>_<location>. Il servizio Azure Kubernetes elimina automaticamente il gruppo di risorse del nodo durante l'eliminazione di un cluster, pertanto è consigliabile usare questo gruppo di risorse solo per le risorse che condividono il ciclo di vita del cluster.

Aggiungere un pool di nodi

L'esempio di codice seguente usa il comando az aks nodepool add dell'interfaccia della riga di comando di Azure per aggiungere un pool di nodi denominato mynodepool con tre nodi a un cluster del myResourceGroup servizio Azure Kubernetes esistente denominato myAKSCluster nel gruppo di risorse.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Pool di nodi spot

Un pool di nodi spot è un pool di nodi supportato da un set di scalabilità di macchine virtuali spot. L'uso di macchine virtuali spot per i nodi con il cluster del servizio Azure Kubernetes sfrutta la capacità di Azure non utilizzata con un notevole risparmio sui costi. La quantità di capacità non utilizzata disponibile varia in base a molti fattori, tra cui dimensioni del nodo, area e ora del giorno.

Quando si distribuisce un pool di nodi spot, Azure alloca i nodi spot se è disponibile la capacità. Ma non esiste alcun contratto di servizio per i nodi spot. Un set di scalabilità spot che esegue il backup del pool di nodi spot viene distribuito in un singolo dominio di errore e non offre garanzie di disponibilità elevata. Quando Azure richiede di nuovo la capacità, l'infrastruttura di Azure rimuove i nodi spot e si riceve al massimo un avviso di 30 secondi prima della rimozione. Tenere presente che un pool di nodi spot non può essere il pool di nodi predefinito del cluster. Un pool di nodi spot può essere usato solo per un pool secondario.

I nodi spot sono destinati a carichi di lavoro che possono gestire interruzioni, terminazioni anticipata o eliminazioni. Ad esempio, i processi di elaborazione batch, gli ambienti di sviluppo e test e i carichi di lavoro di calcolo di grandi dimensioni sono buoni candidati per la pianificazione in un pool di nodi spot. Per altri dettagli, vedere le limitazioni dell'istanza spot.

Il comando seguente az aks nodepool add aggiunge un pool di nodi spot a un cluster esistente con scalabilità automatica abilitata.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Per altre informazioni sui pool di nodi spot, vedere Aggiungere un pool di nodi spot a un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes).

Dischi del sistema operativo temporanei

Per impostazione predefinita, Azure replica automaticamente il disco del sistema operativo della macchina virtuale in Archiviazione di Azure per evitare perdite di dati se la macchina virtuale deve essere spostata in un altro host. Tuttavia, poiché i contenitori non sono progettati per rendere persistente lo stato locale, mantenere il disco del sistema operativo nell'archiviazione offre un valore limitato per il servizio Azure Kubernetes. Esistono alcuni svantaggi, ad esempio il provisioning dei nodi più lento e una latenza di lettura/scrittura superiore.

Al contrario, i dischi temporanei del sistema operativo vengono archiviati solo nel computer host, come un disco temporaneo, e offrono una latenza di lettura/scrittura inferiore e un ridimensionamento dei nodi e aggiornamenti del cluster più veloci. Come un disco temporaneo, un disco del sistema operativo temporaneo è incluso nel prezzo della macchina virtuale, quindi non vengono addebitati costi di archiviazione aggiuntivi.

Per usare il sistema operativo temporaneo, il disco del sistema operativo deve rientrare nella cache della macchina virtuale. La documentazione della macchina virtuale di Azure mostra le dimensioni della cache delle macchine virtuali tra parentesi accanto alla velocità effettiva di I/O come dimensioni della cache in gibibyte (GiB).

Ad esempio, le dimensioni predefinite del servizio Azure Kubernetes Standard_DS2_v2 con le dimensioni predefinite del disco del sistema operativo da 100 GB supportano il sistema operativo temporaneo, ma ha solo 86 GB di dimensioni della cache. Questa configurazione viene impostata per impostazione predefinita su disco gestito se non si specifica in modo esplicito. Se si richiede in modo esplicito il sistema operativo temporaneo per questa dimensione, viene visualizzato un errore di convalida.

Se si richiede la stessa macchina virtuale Standard_DS2_v2 con un disco del sistema operativo da 60 GB, si ottiene il sistema operativo temporaneo per impostazione predefinita. Le dimensioni richieste del sistema operativo da 60 GB sono inferiori alle dimensioni massime della cache di 86 GB.

Standard_D8s_v3 con un disco del sistema operativo da 100 GB supporta il sistema operativo temporaneo e ha 200 GB di spazio nella cache. Se un utente non specifica il tipo di disco del sistema operativo, per impostazione predefinita un pool di nodi ottiene un sistema operativo temporaneo.

Il comando seguente az aks nodepool add illustra come aggiungere un nuovo pool di nodi a un cluster esistente con un disco temporaneo del sistema operativo. Il --node-osdisk-type parametro imposta il tipo di disco del sistema operativo su Ephemerale il --node-osdisk-size parametro definisce le dimensioni del disco del sistema operativo.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Per altre informazioni sui dischi temporanei del sistema operativo, vedere Sistema operativo temporaneo.

Nodi virtuali

È possibile usare i nodi virtuali per aumentare rapidamente il numero di istanze dei carichi di lavoro dell'applicazione in un cluster del servizio Azure Kubernetes. I nodi virtuali offrono il provisioning rapido dei pod e si paga solo al secondo per il tempo di esecuzione. Non è necessario attendere che il ridimensionamento automatico del cluster distribuisca nuovi nodi di lavoro per eseguire più repliche pod. I nodi virtuali sono supportati solo con pod e nodi Linux. Il componente aggiuntivo nodi virtuali per il servizio Azure Kubernetes si basa sul progetto Kubelet virtuale open source.

La funzionalità del nodo virtuale dipende da Istanze di Azure Container. Per altre informazioni sui nodi virtuali, vedere Creare e configurare un cluster servizio Azure Kubernetes del servizio Azure Kubernetes per l'uso di nodi virtuali.

Taints, labels e tag

Quando si crea un pool di nodi, è possibile aggiungere tag e etichette Kubernetes a tale pool di nodi. Quando si aggiunge un taint, un'etichetta o un tag, tutti i nodi all'interno del pool di nodi ottengono tale taint, etichetta o tag.

Per creare un pool di nodi con un taint, è possibile usare il az aks nodepool add comando con il --node-taints parametro . Per etichettare i nodi in un pool di nodi, è possibile usare il --labels parametro e specificare un elenco di etichette, come illustrato nel codice seguente:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Per altre informazioni, vedere Specificare un taint, un'etichetta o un tag per un pool di nodi.

Etichette di sistema riservate

Amazon EKS aggiunge etichette Kubernetes automatizzate a tutti i nodi di un gruppo di nodi gestiti, ad esempio eks.amazonaws.com/capacityType, che specifica il tipo di capacità. Il servizio Azure Kubernetes aggiunge automaticamente anche etichette di sistema ai nodi dell'agente.

I prefissi seguenti sono riservati per l'uso del servizio Azure Kubernetes e non possono essere usati per alcun nodo:

• kubernetes.azure.com/
• kubernetes.io/

Per altri prefissi riservati, vedere Etichette, annotazioni etaints note di Kubernetes.

Nella tabella seguente sono elencate le etichette riservate per l'uso del servizio Azure Kubernetes e non possono essere usate per alcun nodo. Nella tabella la colonna Utilizzo nodo virtuale specifica se l'etichetta è supportata nei nodi virtuali.

Nella colonna Utilizzo nodo virtuale:

• N/D indica che la proprietà non si applica ai nodi virtuali perché richiederebbe la modifica dell'host.
• Lo stesso significa che i valori previsti sono gli stessi per un pool di nodi virtuali come per un pool di nodi standard.
• La macchina virtuale sostituisce i valori dello SKU della macchina virtuale, perché i pod dei nodi virtuali non espongono alcuna macchina virtuale sottostante.
• La versione del nodo virtuale fa riferimento alla versione attuale della versione rilasciata del connettore virtuale Kubelet-ACI.
• Il nome della subnet del nodo virtuale è la subnet che distribuisce i pod dei nodi virtuali in Istanze di Azure Container.
• La rete virtuale del nodo virtuale è la rete virtuale che contiene la subnet del nodo virtuale.

Pool di nodi Windows

Il servizio Azure Kubernetes supporta la creazione e l'uso di pool di nodi del contenitore Windows Server tramite il plug-in di rete CNI (Azure Container Network Interface). Per pianificare gli intervalli di subnet e le considerazioni di rete necessari, vedere Configurare la rete CNI di Azure.

Il comando seguente az aks nodepool add aggiunge un pool di nodi che esegue i contenitori di Windows Server.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Il comando precedente usa la subnet predefinita nella rete virtuale del cluster del servizio Azure Kubernetes. Per altre informazioni su come creare un cluster del servizio Azure Kubernetes con un pool di nodi Di Windows, vedere Creare un contenitore di Windows Server nel servizio Azure Kubernetes.

Considerazioni sul pool di nodi

Quando si creano e gestiscono pool di nodi e più pool di nodi, si applicano le considerazioni e le limitazioni seguenti:

• Le quote, le restrizioni relative alle dimensioni delle macchine virtuali e la disponibilità dell'area si applicano ai pool di nodi del servizio Azure Kubernetes.

• I pool di sistema devono contenere almeno un nodo. È possibile eliminare un pool di nodi di sistema se nel cluster del servizio Azure Kubernetes è presente un altro pool di nodi di sistema. I pool di nodi utente possono contenere zero o più nodi.

• Non è possibile modificare le dimensioni della macchina virtuale di un pool di nodi dopo averlo creato.

• Per più pool di nodi, il cluster del servizio Azure Kubernetes deve usare i servizi di bilanciamento del carico dello SKU Standard. I servizi di bilanciamento del carico sku basic non supportano più pool di nodi.

• Tutti i pool di nodi del cluster devono trovarsi nella stessa rete virtuale e tutte le subnet assegnate a qualsiasi pool di nodi devono trovarsi nella stessa rete virtuale.

• Se si creano più pool di nodi in fase di creazione del cluster, le versioni di Kubernetes per tutti i pool di nodi devono corrispondere alla versione del piano di controllo. È possibile aggiornare le versioni dopo il provisioning del cluster usando le operazioni per ogni pool di nodi.

Ridimensionamento del pool di nodi

Quando il carico di lavoro dell'applicazione cambia, potrebbe essere necessario modificare il numero di nodi in un pool di nodi. È possibile aumentare o ridurre manualmente il numero di nodi usando il comando az aks nodepool scale . L'esempio seguente ridimensiona il numero di nodi in mynodepool cinque:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Ridimensionare automaticamente i pool di nodi usando il ridimensionamento automatico del cluster

Il servizio Azure Kubernetes supporta automaticamente il ridimensionamento automatico dei pool di nodi con il ridimensionamento automatico del cluster. Questa funzionalità viene abilitata in ogni pool di nodi e viene definito un numero minimo e massimo di nodi.

Il comando seguente az aks nodepool add aggiunge un nuovo pool di nodi denominato mynodepool a un cluster esistente. Il --enable-cluster-autoscaler parametro abilita il ridimensionamento automatico del cluster nel nuovo pool di nodi e i --min-count parametri e --max-count specificano il numero minimo e massimo di nodi nel pool.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Il comando az aks nodepool update seguente aggiorna il numero minimo di nodi da uno a tre per il pool di mynewnodepool nodi.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

È possibile disabilitare il ridimensionamento automatico del cluster con az aks nodepool update passando il --disable-cluster-autoscaler parametro .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Per riabilitare il ridimensionamento automatico del cluster in un cluster esistente, usare az aks nodepool update, specificando i --enable-cluster-autoscalerparametri , --min-counte --max-count .

Per altre informazioni su come usare il ridimensionamento automatico del cluster per singoli pool di nodi, vedere Ridimensionare automaticamente un cluster per soddisfare le esigenze delle applicazioni in servizio Azure Kubernetes (servizio Azure Kubernetes).

Aggiornamenti e aggiornamenti

Azure aggiorna periodicamente la piattaforma di hosting delle macchine virtuali per migliorare l'affidabilità, le prestazioni e la sicurezza. Questi aggiornamenti vanno dall'applicazione di patch ai componenti software nell'ambiente di hosting all'aggiornamento dei componenti di rete o alla rimozione delle autorizzazioni dell'hardware. Per altre informazioni sull'aggiornamento delle macchine virtuali di Azure, vedere Manutenzione per le macchine virtuali in Azure.

Gli aggiornamenti dell'infrastruttura di hosting delle macchine virtuali in genere non influiscono sulle macchine virtuali ospitate, ad esempio i nodi agente dei cluster del servizio Azure Kubernetes esistenti. Per gli aggiornamenti che interessano le macchine virtuali ospitate, Azure riduce al minimo i casi che richiedono riavvii sospendo la macchina virtuale durante l'aggiornamento dell'host o eseguendo la migrazione in tempo reale della macchina virtuale a un host già aggiornato.

Se un aggiornamento richiede un riavvio, Azure fornisce una notifica e un intervallo di tempo in modo da poter avviare l'aggiornamento quando funziona automaticamente. La finestra di manutenzione automatica per i computer host è in genere di 35 giorni, a meno che l'aggiornamento non sia urgente.

È possibile usare manutenzione pianificata per aggiornare le macchine virtuali e gestire le notifiche di manutenzione pianificata con l'interfaccia della riga di comando di Azure, PowerShell o il portale di Azure. Manutenzione pianificata rileva se si usa l'aggiornamento automatico del cluster e pianifica automaticamente gli aggiornamenti durante la finestra di manutenzione. Per altre informazioni sulla manutenzione pianificata, vedere il comando az aks maintenanceconfiguration e Usare manutenzione pianificata per pianificare le finestre di manutenzione per il cluster servizio Azure Kubernetes del servizio Azure Kubernetes.

Aggiornamenti di Kubernetes

Parte del ciclo di vita del cluster del servizio Azure Kubernetes esegue periodicamente l'aggiornamento alla versione più recente di Kubernetes. È importante applicare gli aggiornamenti per ottenere le versioni e le funzionalità di sicurezza più recenti. Per aggiornare la versione Kubernetes delle macchine virtuali del pool di nodi esistenti, è necessario assegnare e svuotare i nodi e sostituirli con nuovi nodi basati su un'immagine del disco Kubernetes aggiornata.

Per impostazione predefinita, il servizio Azure Kubernetes configura gli aggiornamenti per l'aumento con un nodo aggiuntivo. Un valore predefinito di uno per le impostazioni riduce al minimo l'interruzione del max-surge carico di lavoro creando un nodo aggiuntivo per sostituire i nodi con controllo delle versioni precedenti prima di completare o svuotare le applicazioni esistenti. È possibile personalizzare il max-surge valore per ogni pool di nodi per consentire un compromesso tra la velocità di aggiornamento e l'interruzione dell'aggiornamento. L'aumento del max-surge valore completa il processo di aggiornamento più velocemente, ma un valore elevato per max-surge potrebbe causare interruzioni durante il processo di aggiornamento.

Ad esempio, un max-surge valore pari al 100% fornisce il processo di aggiornamento più rapido possibile raddoppiando il numero di nodi, ma comporta anche lo svuotamento simultaneo di tutti i nodi nel pool di nodi. È possibile usare questo valore elevato per i test, ma per i pool di nodi di produzione, un'impostazione max-surge del 33% è migliore.

Il servizio Azure Kubernetes accetta valori interi e percentuali per max-surge. Un numero intero, ad 5 esempio, indica cinque nodi aggiuntivi da aumentare. I valori di percentuale per max-surge possono essere minimo 1% e massimo di , arrotondati fino al numero di 100%nodi più vicino. Un valore di 50% indica un valore di aumento della metà del numero di nodi corrente nel pool.

Durante un aggiornamento, il max-surge valore può essere minimo 1 e un valore massimo uguale al numero di nodi nel pool di nodi. È possibile impostare valori maggiori, ma il numero massimo di nodi usati per max-surge non sarà maggiore del numero di nodi nel pool.

Aggiornare i pool di nodi

Per visualizzare gli aggiornamenti disponibili, usare az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Per visualizzare lo stato dei pool di nodi, usare az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Il comando seguente usa az aks nodepool upgrade per aggiornare un singolo pool di nodi.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Per altre informazioni su come aggiornare la versione di Kubernetes per un piano di controllo del cluster e i pool di nodi, vedere:

• Aggiornamento dell'immagine del nodo del servizio Azure Kubernetes
• Aggiornare un piano di controllo del cluster con più pool di nodi

Considerazioni sull'aggiornamento

Si notino queste procedure consigliate e considerazioni per l'aggiornamento della versione di Kubernetes in un cluster del servizio Azure Kubernetes.

• È consigliabile aggiornare tutti i pool di nodi in un cluster del servizio Azure Kubernetes alla stessa versione di Kubernetes. Il comportamento predefinito di aggiorna tutti i pool di az aks upgrade nodi e il piano di controllo.

• Aggiornare manualmente o impostare un canale di aggiornamento automatico nel cluster. Se si usa manutenzione pianificata per applicare patch alle macchine virtuali, gli aggiornamenti automatici vengono avviati anche durante la finestra di manutenzione specificata. Per altre informazioni, vedere Aggiornare un cluster del servizio Azure Kubernetes.

• Il az aks upgrade comando con il --control-plane-only flag aggiorna solo il piano di controllo del cluster e non modifica alcun pool di nodi associato nel cluster. Per aggiornare i singoli pool di nodi, specificare il pool di nodi di destinazione e la az aks nodepool upgrade versione di Kubernetes nel comando .

• Un aggiornamento del cluster del servizio Azure Kubernetes attiva un processo di blocco e svuotamento dei nodi. Se è disponibile una quota di calcolo ridotta, l'aggiornamento potrebbe non riuscire. Per altre informazioni sull'aumento della quota, vedere Aumentare le quote di vCPU a livello di area.

• Configurare il max-surge parametro in base alle esigenze, usando un numero intero o un valore percentuale. Per i pool di nodi di produzione, usare un'impostazione max-surge del 33%. Per altre informazioni, vedere Personalizzare l'aggiornamento della sovratensione del numero di nodi.

• Quando si aggiorna un cluster del servizio Azure Kubernetes che usa la rete CNI, assicurarsi che la subnet disponga di indirizzi IP privati sufficienti per i nodi aggiuntivi creati dalle max-surge impostazioni. Per altre informazioni, vedere Configurare la rete CNI di Azure nel servizio Azure Kubernetes.

• Se i pool di nodi del cluster si estendono su più zone di disponibilità all'interno di un'area, il processo di aggiornamento può causare temporaneamente una configurazione della zona sbilanciata. Per altre informazioni, vedere Considerazioni speciali per i pool di nodi che si estendono su più zone di disponibilità.

Reti virtuali node

Quando si crea un nuovo cluster o si aggiunge un nuovo pool di nodi a un cluster esistente, si specifica l'ID risorsa di una subnet all'interno della rete virtuale del cluster in cui si distribuiscono i nodi dell'agente. Un carico di lavoro potrebbe richiedere la suddivisione dei nodi di un cluster in pool di nodi separati per l'isolamento logico. È possibile ottenere questo isolamento con subnet separate, ognuna dedicata a un pool di nodi separato. Le macchine virtuali del pool di nodi ottengono ogni indirizzo IP privato dalla subnet associata.

Il servizio Azure Kubernetes supporta due plug-in di rete:

• Kubenet è un plug-in di rete semplice di base per Linux. Con kubenet, i nodi ottengono un indirizzo IP privato dalla subnet di Azure Rete virtuale. I pod ottengono un indirizzo IP da uno spazio indirizzi diverso logicamente. Network Address Translation (NAT) consente ai pod di raggiungere le risorse nella rete virtuale di Azure convertendo l'indirizzo IP del traffico di origine nell'indirizzo IP primario del nodo. Questo approccio riduce il numero di indirizzi IP che è necessario riservare nello spazio di rete per i pod.

• L'interfaccia CNI (Azure Container Networking Interface) offre a ogni pod un indirizzo IP per chiamare e accedere direttamente. Questi indirizzi IP devono essere univoci nello spazio di rete. 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 per tale nodo. Questo approccio richiede una pianificazione avanzata e può causare l'esaurimento degli indirizzi IP o la necessità di ricompilare i cluster in una subnet più grande man mano che le richieste dell'applicazione aumentano.

  Quando si crea un nuovo cluster o si aggiunge un nuovo pool di nodi a un cluster che usa Azure CNI, è possibile specificare l'ID risorsa di due subnet separate, una per i nodi e una per i pod. Per altre informazioni, vedere Allocazione dinamica di indirizzi IP e supporto avanzato delle subnet.

Allocazione ip dinamica

I pod che usano Azure CNI ottengono indirizzi IP privati da una subnet del pool di nodi di hosting. L'allocazione ip dinamica di Azure CNI può allocare indirizzi IP privati ai pod da una subnet separata dalla subnet di hosting del pool di nodi. Questa funzionalità offre i vantaggi seguenti:

• La subnet del pod alloca dinamicamente gli indirizzi IP ai pod. L'allocazione dinamica offre un utilizzo ip migliore rispetto alla soluzione CNI tradizionale, che esegue l'allocazione statica degli indirizzi IP per ogni nodo.

• È possibile ridimensionare e condividere le subnet dei nodi e dei pod in modo indipendente. È possibile condividere una singola subnet pod tra più pool di nodi o cluster distribuiti nella stessa rete virtuale. È anche possibile configurare una subnet pod separata per un pool di nodi.

• Poiché i pod hanno indirizzi IP privati della rete virtuale, hanno connettività diretta ad altri pod e risorse del cluster nella rete virtuale. Questa capacità supporta prestazioni migliori per cluster di grandi dimensioni.

• Se i pod hanno una subnet separata, è possibile configurare i criteri di rete virtuale per i pod diversi dai criteri dei nodi. I criteri separati consentono molti scenari utili, ad esempio consentire la connettività Internet solo per i pod e non per i nodi, correggere l'indirizzo IP di origine per un pod in un pool di nodi usando il gateway NAT e l'uso di gruppi di sicurezza di rete per filtrare il traffico tra pool di nodi.

• Sia i criteri di rete che i criteri di rete Calico Kubernetes funzionano con l'allocazione ip dinamica.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Paolo Salvatori | Principal System Engineer

Altri contributori:

• Laura Nicolas | Senior Software Engineer
• Chad Kittel | Principal Software Engineer
• Ed Price | Senior Content Program Manager
• Theano Petersen | Writer tecnico

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Servizio Azure Kubernetes per professionisti amazon EKS
• Gestione delle identità e degli accessi Kubernetes
• Monitoraggio e registrazione Kubernetes
• Accesso sicuro alla rete Kubernetes
• Opzioni di archiviazione per un cluster Kubernetes
• Gestione dei costi per Kubernetes
• Governance del cluster
• Percorso della soluzione del servizio Azure Kubernetes
• Guida alle operazioni di manutenzione ordinaria del servizio Azure Kubernetes
• Scegliere un'opzione di calcolo Kubernetes su dispositivi perimetrali
• GitOps per il servizio Azure Kubernetes

Risorse correlate

• Procedure consigliate per i cluster del servizio Azure Kubernetes
• Creare un cluster del servizio Azure Kubernetes privato con una zona DNS pubblica
• Creare un cluster servizio Azure Kubernetes privato usando Terraform e Azure DevOps
• Creare un cluster di servizio Azure Kubernetes pubblico o privato con gateway NAT di Azure e gateway di app Azure lication
• Usare endpoint privati con un cluster del servizio Azure Kubernetes privato
• Creare un cluster servizio Azure Kubernetes con il controller di ingresso gateway applicazione
• Introduzione a Kubernetes
• Introduzione a Kubernetes in Azure
• Implementare servizio Azure Kubernetes (servizio Azure Kubernetes)
• Sviluppare e distribuire applicazioni in Kubernetes
• Ottimizzare i costi di calcolo in servizio Azure Kubernetes (servizio Azure Kubernetes)