Opzioni di aggiornamento per i cluster del servizio Azure Kubernetes (AKS)

Articolo
2025-04-10

Questo articolo illustra le diverse opzioni di aggiornamento per i cluster del servizio Azure Kubernetes. Per eseguire un aggiornamento della versione Kubernetes di base, vedere Aggiornare un cluster del servizio Azure Kubernetes.

Per i cluster del servizio Azure Kubernetes che usano più pool di nodi o nodi di Windows Server, vedere Aggiornare un pool di nodi nel servizio Azure Kubernetes. Per aggiornare un pool di nodi specifico senza eseguire un aggiornamento del cluster Kubernetes, vedere Aggiornare un pool di nodi specifico.

Eseguire aggiornamenti manuali

È possibile eseguire aggiornamenti manuali per controllare quando il cluster viene aggiornato a una nuova versione di Kubernetes. Gli aggiornamenti manuali sono utili quando si vuole testare una nuova versione di Kubernetes prima di aggiornare il cluster di produzione. È possibile usare gli aggiornamenti manuali anche per aggiornare il cluster a una versione specifica di Kubernetes che non è la versione più recente disponibile.

Per eseguire gli aggiornamenti manuali, vedere gli articoli seguenti:

Configurare gli aggiornamenti automatici

È possibile configurare gli aggiornamenti automatici per aggiornare automaticamente il cluster alla versione più recente disponibile di Kubernetes. Gli aggiornamenti automatici sono utili quando ci si vuole assicurare che il cluster esegua sempre la versione più recente di Kubernetes. È possibile usare gli aggiornamenti automatici anche per assicurarsi che il cluster esegua sempre una versione di Kubernetes supportata.

Per configurare gli aggiornamenti automatici, vedere gli articoli seguenti:

Considerazioni speciali per i pool di nodi che si estendono su più zone di disponibilità

Il servizio Azure Kubernetes usa il bilanciamento delle zone con massimo sforzo nei gruppi di nodi. Durante un picco di aggiornamento, le zone relative ai nodi di picco nei set di scalabilità di macchine virtuali sono inizialmente sconosciute, il che può temporaneamente causare una configurazione sbilanciata delle zone durante l'aggiornamento. Tuttavia, il servizio Azure Kubernetes elimina i nodi di picco al termine dell'aggiornamento e mantiene il bilanciamento delle zone originale. Se si vuole mantenere bilanciate le zone durante gli aggiornamenti, è possibile aumentare il picco di un numero multiplo di tre nodie i set di scalabilità di macchine virtuali bilanceranno i nodi nelle zone di disponibilità con il bilanciamento delle zone con massimo sforzo. Con il bilanciamento delle zone con massimo sforzo, il set di scalabilità tenta di aumentare e ridurre il numero di macchine virtuali mantenendo il bilanciamento. Tuttavia, se per qualche motivo questo non è possibile (ad esempio, se una zona è fuori servizio, il set di scalabilità non può creare una nuova macchina virtuale in tale zona), il set di scalabilità consente lo squilibrio temporaneo per effettuare correttamente lo scaling verso l'alto o verso il basso.

Le richieste di volumi persistenti (PVC) supportate da dischi di archiviazione con ridondanza locale (LRS) di Azure sono vincolate a una determinata zona e potrebbero non riuscire a ripristinarsi immediatamente se il nodo di sovraccarico non corrisponde alla zona del PVC. Se le zone non corrispondono, possono verificarsi tempi di inattività nell'applicazione quando l'operazione di aggiornamento continua a svuotare i nodi, ma i PV sono vincolati a una zona. Per gestire questo caso e mantenere la disponibilità elevata, configurare un budget per l'interruzione dei pod nell'applicazione per consentire a Kubernetes di rispettare i requisiti di disponibilità durante l'operazione di svuotamento.

Ottimizzare il comportamento dei nodi non restrittivi (anteprima)

È possibile configurare il comportamento del processo di aggiornamento per i guasti di drenaggio. Il comportamento di aggiornamento predefinito è Schedule, costituito da un errore di drenaggio del nodo che causa il fallimento dell'operazione di aggiornamento, lasciando i nodi non drenati in uno stato pianificabile. In alternativa, è possibile selezionare il Cordon comportamento, che ignora i nodi che non riescono a svuotare inserendoli in uno stato in quarantena, li etichetta kubernetes.azure.com/upgrade-status:Quarantinede procede con l'aggiornamento dei nodi rimanenti. Questo comportamento garantisce che tutti i nodi vengano aggiornati o messi in quarantena. Questo approccio consente di risolvere gli errori di svuotamento e gestire normalmente i nodi in quarantena.

Impostare il nuovo comportamento di blocco

Per impostare il nuovo comportamento di blocco, è necessario usare aks-preview l'estensione 9.0.0b3 o versione successiva.

Installare o aggiornare l'estensione aks-preview usando il comando [az extension add][az-extension-add] o [az extension update][az-extension-update]:

# Install the aks-preview extension
az extension add --name aks-preview

# Update the aks-preview extension to the latest version
az extension update --name aks-preview

Aggiorna il comportamento del nodo non drenabile nel pool di nodi a Cordon usando il comando [az aks nodepool update][az-aks-nodepool-update].

az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon

L'output di esempio seguente mostra il comportamento del nodo non restrittivo aggiornato:

"upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxSurge": "1",
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": "Cordon"
  }

Verificare l'etichetta nei nodi bloccati quando si verifica un errore di svuotamento del nodo durante l'aggiornamento usando il comando kubectl get.
```
kubectl get nodes --show-labels=true
```
I nodi bloccati non sono pianificati per i pod e contrassegnati con l'etichetta "kubernetes.azure.com/upgrade-status: Quarantined". Il numero massimo di nodi che possono essere lasciati bloccati non può essere maggiore del Max-Surge valore.

Risolvere i nodi che non possono essere drenati

Risolvere prima di tutto il problema sottostante che causa lo svuotamento. Nell'esempio seguente viene rimosso il PDB responsabile:
```
kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.
```
Se si è certi che il problema è stato risolto, è possibile rimuovere l'etichetta "kubernetes.azure.com/upgrade-status: Quarantined" posizionata su nodi non restrittivi usando il kubectl label comando .
```
kubectl label nodes <node-name> <label-key>-
```
Tutte le operazioni PUT successive tenteranno di riconciliare prima l'oggetto Failed Provisioning Status nel cluster Success. I nodi in quarantena non verranno considerati per eventuali inserimenti o successive riconciliazioni. È necessario rimuovere in modo esplicito le etichette come indicato in precedenza per i nodi bloccati da considerare.
È anche possibile eliminare il nodo bloccato usando il comando [az aks nodepool delete-machines][az-aks-nodepool-delete-machines]. Questo comando è utile se si intende ridurre il footprint del pool di nodi rimuovendo i nodi lasciati indietro nelle versioni precedenti.
```
az aks nodepool delete-machines --cluster-name $CLUSTER_NAME --machine-names aks-$NODE_POOL_NAME-test123-vmss000000 --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP
```
Dopo aver completato questo passaggio, è possibile riconciliare lo stato del cluster eseguendo qualsiasi operazione di aggiornamento senza i campi facoltativi come descritto qui. In alternativa, è possibile ridimensionare il pool di nodi allo stesso numero di nodi del numero di nodi aggiornati. Questa azione garantisce che il pool di nodi ottenga le dimensioni originali desiderate. AKS prioritizza la rimozione dei nodi bloccati. Questo comando ripristina anche lo stato del provisioning del cluster su Succeeded. Nell'esempio specificato è 2 il numero totale di nodi aggiornati.
```
# Update the cluster to restore the provisioning status
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --node-count 2 
```

Ottimizzare gli aggiornamenti per migliorare le prestazioni e ridurre al minimo le interruzioni

La combinazione di Finestra di manutenzione pianificata, Picco massimo, Budget per l'interruzione dei pod, Timeout di svuotamento dei nodie Tempo di attesa dei nodi può aumentare significativamente la probabilità che gli aggiornamenti dei nodi vengano completati correttamente entro la fine della finestra di manutenzione, riducendo al minimo le interruzioni.

Finestra di manutenzione pianificata consente ai team del servizio di pianificare l'aggiornamento automatico durante una finestra predefinita, in genere un periodo di traffico ridotto, per ridurre al minimo l'impatto sul carico di lavoro. È consigliabile una finestra della durata di almeno quattro ore.
Max Surge nel pool di nodi consente di richiedere una quota aggiuntiva durante il processo di aggiornamento e limita il numero di nodi selezionati per l'aggiornamento simultaneamente. Un picco massimo superiore comporta un processo di aggiornamento più rapido. Non è consigliabile impostare il picco massimo su 100%, in quanto tutti i nodi vengono aggiornati contemporaneamente, causando interruzioni nell'esecuzione delle applicazioni. Per i pool di nodi di produzione, è consigliabile una quota di picco massimo di 33%.
Max Unavailable (anteprima) nel pool di nodi consente l'esecuzione degli aggiornamenti tramite il blocco dei nodi esistenti e lo svuotamento senza aggiungere nodi di picco. Un massimo massimo superiore non disponibile comporta un aggiornamento più rapido, ma causa anche un maggior numero di interruzioni del carico di lavoro per il pool di nodi. Questa funzionalità è consigliata per i clienti che riscontrano vincoli di capacità a causa della mancanza di capacità aggiuntiva di SKU nell'area o nei problemi di quota.
Budget per l'interruzione dei pod è impostato per le applicazioni di servizio e limita il numero di pod che possono essere disattivati durante interruzioni volontarie, ad esempio gli aggiornamenti dei nodi controllati dal servizio Azure Kubernetes. Può essere configurato come repliche minAvailable, che indica il numero minimo di pod dell'applicazione che devono essere attivi o repliche maxUnavailable, che indica il numero massimo di pod dell'applicazione che possono essere terminati, garantendo la disponibilità elevata per l'applicazione. Fare riferimento alle indicazioni fornite per configurare Budget per l'interruzione dei pod (PDB). I valori PDB devono essere convalidati per determinare le impostazioni che funzionano meglio per il servizio specifico.
Timeout di svuotamento dei nodi nel pool di nodi consente di configurare la durata di attesa per la rimozione dei pod e la terminazione normale per ogni nodo durante un aggiornamento. Questa opzione è utile quando si gestiscono carichi di lavoro a esecuzione prolungata. Quando viene specificato il timeout di svuotamento dei nodi (in minuti), il servizio Azure Kubernetes rispetta l'attesa nei budget di interruzione dei pod. Se non specificato, il timeout predefinito è 30 minuti.
Tempo di attesa dei nodi consente di scaglionare gli aggiornamenti dei nodi in modo controllato e può ridurre al minimo i tempi di inattività delle applicazioni durante un aggiornamento. È possibile specificare un tempo di attesa, preferibilmente il più vicino possibile a 0 minuti, per verificare la disponibilità dell'applicazione tra gli aggiornamenti dei nodi. Se non è specificato, il valore predefinito è 0 minuti. Tempo di attesa dei nodi funziona insieme alle proprietà Picco massimo e Timeout di svuotamento dei nodi disponibili nel pool di nodi per restituire risultati corretti in termini di velocità di aggiornamento e disponibilità dell'applicazione.

Impostazioni di aggiornamento	Risorse disponibili per l'aumento	Comportamento previsto
`maxSurge` = `5maxUnavailable` = `0`	5 nodi disponibili per l'aumento	Verranno aumentati 5 nodi per aggiornare il pool di nodi.
`maxSurge` = `5maxUnavailable` = `0`	0-4 nodi disponibili per l'aumento	L'operazione di aggiornamento non riesce a causa della mancata presenza di nodi sufficienti per soddisfare `maxSurge`.
`maxSurge` = `0maxUnavailable` = `5`	N/D poiché non sono necessari nodi di picco	L'operazione usa 5 nodi dal pool di nodi esistente senza creare nuovi nodi per aggiornare il pool di nodi.

Le convalide usate nel processo di aggiornamento oggi

Quando si avvia un'operazione di aggiornamento tramite API, interfaccia della riga di comando di Azure o portale di Azure, il servizio Azure Kubernetes esegue una serie di convalide di pre-aggiornamento prima di avviare l'aggiornamento. Queste convalide assicurano che il cluster sia in uno stato integro e possa essere aggiornato correttamente.

Modifiche che causano un'interruzione dell'API: identifica se sono presenti API deprecate in uso che possono influire sui carichi di lavoro.
Versione dell'aggiornamento di Kubernetes: assicura che la versione di destinazione sia valida(ad esempio, nessun passaggio maggiore di tre versioni secondarie, nessun downgrade e compatibilità con il piano di controllo).
Convalida della configurazione PDB non corretta: verifica la presenza di budget di interruzione dei pod (PDB) non configurati correttamente, ad esempio maxUnavailable = 0 che non consentono l'interruzione dei nodi.
Quota: conferma che è disponibile una quota sufficiente per i nodi in espansione necessari durante il processo di aggiornamento.
Subnet: verifica se sono presenti indirizzi IP allocabili sufficienti per l'aggiornamento o se sono necessarie modifiche alle dimensioni della subnet.
Certificati/entità servizio: rileva certificati scaduti o entità servizio che potrebbero influire sul processo di aggiornamento.

Questi controlli consentono di ridurre al minimo gli errori di aggiornamento e fornire agli utenti visibilità anticipata sui potenziali problemi che devono essere risolti prima di procedere.

Passaggi successivi

Questo articolo illustra le diverse opzioni di aggiornamento per i cluster del servizio Azure Kubernetes. Per una descrizione dettagliata delle procedure consigliate per l'aggiornamento e altre considerazioni, vedere Linee guida per l'aggiornamento e le patch del servizio Azure Kubernetes.

Condividi tramite