Opzioni di aggiornamento e consigli per i cluster del servizio Azure Kubernetes

Si applica a: ✔️ AKS Automatic ✔️ AKS Standard

Per la maggior parte dei carichi di lavoro di produzione, AKS Automatic è l’esperienza cluster predefinita consigliata. Offre impostazioni predefinite pronte per la produzione per le operazioni del ciclo di vita del cluster e dei nodi, tra cui il comportamento di aggiornamento gestito, le misure di sicurezza predefinite e il sovraccarico operativo ridotto.

Il servizio Azure Kubernetes Standard rimane disponibile per scenari in cui è necessario un controllo manuale più approfondito sui meccanismi di aggiornamento, sulle scelte di rete o sul comportamento del pool di nodi.

Questo articolo offre una base tecnica per gli aggiornamenti del servizio Azure Kubernetes coprendo le opzioni di aggiornamento, gli scenari comuni e le raccomandazioni sia per il servizio Azure Kubernetes automatico che per il servizio Azure Kubernetes Standard.

Informazioni su questo articolo

Questo riferimento tecnico illustra:

  • Perché AKS Automatic è l'impostazione predefinita consigliata, pronta per la produzione, per la maggior parte dei carichi di lavoro.
  • Differenze tra il comportamento di aggiornamento automatico del servizio Azure Kubernetes e lo standard del servizio Azure Kubernetes.
  • Percorsi di aggiornamento manuali e automatizzati e quando usarli.
  • Scenari di aggiornamento comuni con raccomandazioni specifiche.
  • Tecniche di ottimizzazione per prestazioni e interruzioni minime.
  • Processi di convalida e controlli di pre-aggiornamento.

Per indicazioni correlate:

Spostamento rapido

La tua situazione Percorso consigliato
Carico di lavoro di produzione nuovo o esistente senza requisiti di personalizzazione speciali Creare un cluster automatico di AKS
Cluster di produzione con controlli di aggiornamento personalizzati rigorosi Strategie di aggiornamento della produzione
Database o carichi di lavoro con stato Modelli di carico di lavoro con stato
Primo aggiornamento di AKS Standard Aggiornamento di base del cluster AKS
Più ambienti o operazioni di flotta Hub degli scenari di aggiornamento
Pool di nodi o nodi Windows in AKS Standard Aggiornamenti del pool di nodi
Solo pool di nodi specifico Aggiornamento del pool a nodo singolo

Aggiornare i modelli operativi

AKS Automatic è progettato per un funzionamento pronto per l'ambiente di produzione per impostazione predefinita. Per gli aggiornamenti, AKS Automatic offre:

  • Pool di nodi di sistema gestiti.
  • Comportamento di aggiornamento automatico del cluster con impostazioni predefinite gestite dalla piattaforma.
  • Comportamento di aggiornamento automatico dell'immagine del sistema operativo del nodo con cadenza incentrata sulla sicurezza.
  • Controlli predefiniti per le API Kubernetes deprecate.
  • Supporto per la pianificazione della manutenzione programmata.

Usa AKS Automatic quando vuoi ridurre al minimo l'orchestrazione manuale degli aggiornamenti e mantenere i cluster di produzione allineati alle versioni supportate con il minimo sforzo.

AKS Standard (modello di controllo avanzato)

AKS Standard offre il controllo diretto sulla sequenza degli aggiornamenti e sull'ottimizzazione. È possibile scegliere e gestire:

  • Configurazione dell'aggiornamento manuale o automatico.
  • Selezione del canale di aggiornamento.
  • Pool di nodi e comportamento di picco.
  • Procedure operative relative alle finestre di manutenzione e ai budget di interruzione del carico di lavoro.

Usare il servizio Azure Kubernetes Standard quando l'ambiente richiede la personalizzazione che supera le impostazioni predefinite automatiche del servizio Azure Kubernetes.

Opzioni di aggiornamento

Eseguire aggiornamenti manuali

Si applica principalmente a AKS Standard o a flussi di lavoro operativi specializzati.

Gli aggiornamenti manuali consentono di controllare quando il cluster viene aggiornato a una nuova versione di Kubernetes. Questi aggiornamenti sono utili per il test, le implementazioni a fasi e l'adozione di versioni mirate.

Configurare gli aggiornamenti automatici

Per il servizio Azure Kubernetes Standard, gli aggiornamenti automatici consentono di mantenere i cluster nelle versioni supportate mantenendo al tempo stesso il controllo sui criteri e sulla pianificazione. In AKS Automatic, l'automazione degli aggiornamenti e i meccanismi di protezione sono già parte del modello operativo predefinito.

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

AKS usa il bilanciamento tra zone best-effort nei pool di nodi. Durante un picco di aggiornamento, le zone per i nodi di picco nei set di scalabilità di macchine virtuali sono AOT, e questo può temporaneamente causare una configurazione di zona sbilanciata. AKS elimina i nodi di espansione dopo l'aggiornamento e ripristina il bilanciamento della zona originale.

Per mantenere bilanciate le zone, impostare il picco su un multiplo di tre nodi. Le richieste di volume persistente che utilizzano dischi di archiviazione Azure con ridondanza locale sono vincolate alla zona e possono causare tempi di inattività se i nodi di incremento si trovano in una zona diversa. Usare un budget di interruzione dei pod (PDB) per mantenere la disponibilità elevata durante gli svuotamenti.

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

Combinare finestra di manutenzione pianificata, max surge, PDB, node drain timeout e node soak time per aumentare la probabilità di aggiornamenti con esito positivo e a bassa interruzione.

AKS Automatico

In AKS Automatic, il comportamento degli aggiornamenti a livello di piattaforma è preconfigurato. Concentrate l'ottimizzazione sulla resilienza del carico di lavoro e sulla preparazione della capacità:

  • Convalida i budget di interruzione dei pod e il numero di repliche.
  • Garantire capacità sufficienti delle quote e delle subnet per la crescita prevista.
  • Impostare pianificazioni di manutenzione pianificata allineate ai periodi di traffico ridotto.
  • Monitora gli eventi di aggiornamento e la preparazione dei carichi di lavoro critici.

Servizio Azure Kubernetes Standard

In AKS Standard, configura direttamente i controlli di aggiornamento:

Impostazioni di aggiornamento Modalità di utilizzo di nodi aggiuntivi Comportamento previsto
maxSurge=5, maxUnavailable=0 5 nodi di sovratensione Cinque nodi vengono potenziati per l'aggiornamento.
maxSurge=5, maxUnavailable=0 0-4 nodi di sovratensione L'aggiornamento fallisce a causa della mancanza di nodi surge.
maxSurge=0, maxUnavailable=5 N/A Per l'aggiornamento vengono svuotati cinque nodi esistenti.

Annotazioni

Prima di eseguire l'aggiornamento, verificare la presenza di modifiche che interrompono l'API ed esaminare le note sulla versione di AKS per evitare interruzioni.

Convalide usate nel processo di aggiornamento

AKS esegue controlli pre-aggiornamento per garantire la salute del cluster.

  • Modifiche che causano un'interruzione dell'API: rileva le API deprecate.
  • Versione di aggiornamento di Kubernetes: Assicura un percorso di aggiornamento valido.
  • Configurazione PDB: Verifica la presenza di PDB configurati in modo errato, ad esempio maxUnavailable=0.
  • Quota: Conferma una quota sufficiente per i nodi di picco.
  • Sottorete: Verifica indirizzi IP sufficienti.
  • Certificati/principali del servizio: Rileva le credenziali scadute.
  • Controllo blocco risorse gestite: Verifica la presenza di blocchi delle risorse applicati al gruppo di risorse del cluster gestito.

Questi controlli si applicano in tutto AKS. In AKS Automatic, sono integrati nel processo di aggiornamento gestito; in AKS Standard, fanno parte del flusso operativo.

Scenari di aggiornamento comuni e raccomandazioni

Scenario 1: Vincoli di capacità

Se il cluster è limitato dal livello di prodotto o dalla capacità a livello di area, gli aggiornamenti potrebbero non riuscire quando non è possibile effettuare il provisioning dei nodi di picco. Questa situazione è comune ai livelli di prodotto specializzati (ad esempio nodi GPU) o in aree con risorse limitate. Gli errori come SKUNotAvailable, AllocationFailed o OverconstrainedAllocationRequest possono verificarsi se maxSurge è impostato su un valore troppo elevato per la capacità disponibile.

AKS Guida automatica

  • Mantieni le finestre di manutenzione pianificate.
  • Convalidare la quota di sottoscrizione e la subnet headroom prima dei periodi di aggiornamento previsti.
  • Mantenere i budget di ridimensionamento e interruzione del carico di lavoro allineati alle finestre di manutenzione.

Linee guida di AKS Standard

Scenario 2: Errori di svuotamento dei nodi e PDB

Gli aggiornamenti richiedono lo svuotamento dei nodi (rimozione dei pod). Gli svuotamenti possono non riuscire se i pod sono lenti a terminare o quando i Budget di interruzione dei pod (PDB) bloccano le eliminazioni dei pod.

Errore di esempio:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Guida automatica di AKS

  • Considerare PDB e strategia di replica come controlli di affidabilità primari.
  • Convalida i budget per le interruzioni nell'ambiente di staging prima del rilascio in produzione.
  • Mantieni i carichi di lavoro critici configurati affinché l'evizione progressiva vada a buon fine.

Linee guida AKS Standard

Opzione 1: Forzare l'aggiornamento, ignorare i vincoli PDB

Avvertimento

Forzare l'aggiornamento ignora i vincoli PDB (Pod Disruption Budget) e potrebbe causare interruzioni del servizio svuotando tutti i pod contemporaneamente. Prima di usare questa opzione, provare prima di tutto a correggere errori di configurazione dei PDB (esaminare le impostazioni PDB minAvailable/maxUnavailable, assicurarsi di avere repliche di pod adeguate, verificare che i PDB non blocchino tutte le evizioni).

Usare l'aggiornamento forzato solo quando i PDB impediscono gli aggiornamenti critici e non possono essere risolti. Questa azione esegue l'override delle protezioni PDB e può causare la mancata disponibilità completa del servizio durante l'aggiornamento.

Requisiti: interfaccia della riga di comando di Azure 2.79.0 o versione successiva oppure AKS API versione 2025-09-01 o successiva

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Annotazioni

  • Il upgrade-override-until parametro definisce quando termina il bypass di convalida (deve essere una data/ora futura)
  • Se non specificato, per impostazione predefinita la finestra è di tre giorni dall'ora corrente
  • Indica Z il fuso orario UTC/GMT

Avvertimento

Quando l'aggiornamento forzato è abilitato, ha la precedenza su tutte le altre configurazioni di svuotamento. Le impostazioni del comportamento del nodo non restrittive (opzione 2) non vengono applicate quando l'aggiornamento forzato è attivo.

Opzione 2: Gestire i nodi che non possono essere svuotati nel rispetto dei PDB

Usare questo approccio conservativo per rispettare i PDB impedendo gli errori di aggiornamento.

Configurare il comportamento del nodo non drenabile:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Opzioni di comportamento:

  • Pianificazione (impostazione predefinita): elimina il nodo bloccato e aumenta la sostituzione.
  • Cordon (scelta consigliata): nodo Cordons e lo etichetta come kubernetes.azure.com/upgrade-status=Quarantined.

Numero massimo di nodi bloccati (anteprima):

  • Specifica il numero di nodi il cui mancato drenaggio è tollerato
  • È necessario impostare undrainable-node-behavior
  • Il valore predefinito è maxSurge (tipicamente 10%) se non specificato.
Prerequisiti per il numero massimo di nodi bloccati

È necessaria l'estensione dell'interfaccia della riga di comando di Azure aks-preview versione 18.0.0b9 o successive per usare la funzionalità numero massimo di nodi bloccati.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview
Configurazione di esempio con numero massimo di nodi bloccati
az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5
Opzione 3: Gestione automatica PDB (anteprima)

Utilizzare l'estensione di gestione automatica dei PDB per risolvere in modo proattivo le operazioni di drain bloccate dai PDB senza aggirare le protezioni dei PDB o richiedere la pulizia manuale dei nodi in quarantena. La gestione PDB automatica rileva quando un PDB blocca l'eliminazione in un nodo bloccato e aumenta temporaneamente le repliche della distribuzione in modo che il budget di interruzione venga soddisfatto. Una volta completato lo svuotamento, riporta il numero di repliche al valore originale.

La gestione automatica del database PDB può anche creare automaticamente PDB per le distribuzioni che non ne hanno una, assicurandosi che i carichi di lavoro siano protetti durante lo svuotamento degli aggiornamenti. Per i dettagli sull'installazione e la configurazione, vedere Gestire automaticamente i budget di interruzione dei pod durante gli aggiornamenti di AKS.

Raccomandazioni per evitare errori di svuotamento
  • Impostare maxUnavailable nei PDB per consentire la rimozione di almeno un pod
  • Aumentare le repliche dei pod per soddisfare i requisiti del budget per le interruzioni
  • Estendere il timeout di svuotamento se i carichi di lavoro richiedono più tempo. Il valore predefinito è 30 minuti.
  • Usare la gestione PDB automatica per automatizzare la creazione e il ridimensionamento delle repliche PDB durante le operazioni di svuotamento.
  • Testare PDBs nella gestione temporanea, monitorare gli eventi di aggiornamento e usare distribuzioni blu-green per carichi di lavoro critici. Per ulteriori informazioni, vedere Distribuzione blu-verde dei cluster AKS.
Verificare i nodi non restrittivi

  • I nodi bloccati non sono pianificati per i pod e contrassegnati con l'etichetta "kubernetes.azure.com/upgrade-status: Quarantined".

  • Verificare l'etichetta su ogni nodo bloccato in caso di fallimento del drenaggio del nodo durante l'aggiornamento.

    kubectl get nodes --show-labels=true
Risolvere i nodi non drenabili

  1. Rimuovere il PDB responsabile:

    kubectl delete pdb <pdb-name>

  2. Rimuovere l'etichetta kubernetes.azure.com/upgrade-status: Quarantined :

    kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-

  3. Facoltativamente, eliminare il nodo bloccato:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. Dopo aver completato questo passaggio, è possibile riconciliare lo stato del cluster eseguendo qualsiasi operazione di aggiornamento senza i campi facoltativi come descritto in az aks. 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 seguente è 2 il numero totale di nodi aggiornati.

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

Scenario 3: Aggiornamenti lenti

Le impostazioni conservatrici o i problemi a livello di nodo possono ritardare gli aggiornamenti, che influiscono sulla capacità di rimanere aggiornati con le patch e i miglioramenti.

Le cause comuni degli aggiornamenti lenti includono:

  • Valori bassi maxSurge o maxUnavailable (limita il parallelismo).
  • Tempi di soak elevati (attese lunghe tra gli aggiornamenti del nodo).
  • Errori di drenaggio (vedere Errori di drenaggio dei nodi).

Guida automatica di AKS

  • Mantenere aggiornate le pianificazioni di manutenzione.
  • Monitorare lo stato di integrità degli eventi di aggiornamento e la prontezza del carico di lavoro.
  • Risolvi rapidamente i problemi di blocco del PDB o di capacità per evitare rallentamenti prolungati.

Linee guida per AKS Standard

  • Usa maxSurge=33%, maxUnavailable=1 per la produzione.
  • Usare maxSurge=50%, maxUnavailable=2 per sviluppo/test.
  • Usare patch di sicurezza del sistema operativo per correzioni rapide e mirate (evita la ricreazione completa dell'immagine del nodo).
  • Abilitare --undrainable-node-behavior per evitare blocchi di aggiornamento.

Scenario 4: esaurimento IP

I nodi di surge richiedono più indirizzi IP. Se la subnet è vicina alla capacità, il provisioning dei nodi può non riuscire (ad esempio Error: SubnetIsFull). Questo scenario è comune con Azure Container Networking Interface, elevati o grandi conteggi di nodi maxPods.

AKS Guida automatica

  • Convalidare i piani di subnet e capacità prima dell'espansione di produzione.
  • Monitorare l'utilizzo della rete come parte delle operazioni di routine.

Linee guida standard per AKS

  • Assicurarsi che la subnet disponga di indirizzi IP sufficienti per tutti i nodi, i nodi di picco e i pod. La formula è Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

  • Recuperare gli INDIRIZZI IP inutilizzati o espandere la subnet , ad esempio da /24 a /22.

  • Minore maxSurge se l'espansione della subnet non è possibile.

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • Monitorare l'utilizzo degli indirizzi IP con Monitoraggio di Azure o avvisi personalizzati.

  • Ridurre maxPods per nodo, pulire gli indirizzi IP orfani del servizio di bilanciamento del carico e pianificare il ridimensionamento delle subnet per i cluster su larga scala.

Domande frequenti

Devo usare AKS Automatic o AKS Standard per gli aggiornamenti in produzione?

Per la maggior parte dei carichi di lavoro di produzione, usare AKS Automatic. È progettato come configurazione predefinita pronta per l'uso in produzione, con una gestione controllata degli aggiornamenti e meccanismi di protezione integrati.

Usa AKS Standard quando hai bisogno di un controllo manuale avanzato sulla sequenza degli aggiornamenti, sulle scelte dell'infrastruttura o sulle operazioni sui pool di nodi.

È possibile usare strumenti open source per la convalida?

Sì. Molti strumenti open source si integrano bene con i processi di aggiornamento di Azure Kubernetes Service (AKS):

  • kube-no-trouble (kubent): analizza le API deprecate prima degli aggiornamenti.
  • Trivy: Analisi della sicurezza per le immagini del contenitore e le configurazioni di Kubernetes.
  • Sonobuoy: test di conformità kubernetes e convalida del cluster.
  • kube-bench: il benchmark della sicurezza verifica la conformità agli standard del Center for Internet Security.
  • Polaris: convalida delle procedure consigliate di Kubernetes.
  • kubectl-neat: pulire i manifesti Kubernetes per la convalida.

Come si convalida la compatibilità dell'API prima dell'aggiornamento?

Eseguire controlli deprecato usando strumenti come kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Cosa rende gli aggiornamenti del servizio Azure Kubernetes diversi da altre piattaforme Kubernetes?

AKS offre diversi vantaggi unici:

  • Percorsi operativi gestiti in AKS Automatic per ridurre il sovraccarico degli aggiornamenti.
  • Integrazione nativa di Azure con Gestione traffico di Azure, Azure Load Balancer e rete.
  • Azure Kubernetes Fleet Manager per gli aggiornamenti multicluster coordinati.
  • Applicazione automatica di patch alle immagini dei nodi senza gestione manuale dei nodi.
  • Convalida predefinita per quote, rete e credenziali.
  • Supporto di Azure per i problemi correlati all'aggiornamento.

Scegliere il percorso di aggiornamento

Questo articolo ha fornito una base tecnica. Ora seleziona il percorso basato sullo scenario.

Pronto per l'esecuzione?

Se hai... Poi vai a...
Carico di lavoro di produzione e nessun vincolo di personalizzazione speciale Creare un cluster automatico di AKS
Ambiente di produzione con esigenze avanzate di aggiornamento personalizzato Strategie di aggiornamento della produzione
Database o app con stato Modelli di carico di lavoro con stato
Più ambienti Hub degli scenari di aggiornamento
Cluster AKS Standard di base Aggiornare un cluster AKS

Ancora decidere?

Usare l'hub degli scenari di aggiornamento per un albero delle decisioni guidato che considera:

  • Tolleranza al tempo di inattività
  • Complessità dell'ambiente
  • Profilo di rischio
  • Vincoli di sequenza temporale

Raccomandazioni finali

  • Usa AKS Automatic per la maggior parte dei carichi di lavoro di produzione.
  • Esaminare le linee guida per l'aggiornamento e le patch del servizio Azure Kubernetes per le procedure consigliate e i suggerimenti per la pianificazione prima di avviare qualsiasi aggiornamento.
  • Controllare sempre le modifiche che causano un'interruzione dell'API e convalidare la compatibilità del carico di lavoro con la versione di Kubernetes di destinazione.
  • Testare le impostazioni di aggiornamento (ad esempio maxSurge, maxUnavailablee PDB) in un ambiente di staging per ridurre al minimo i rischi di produzione.
  • Monitorare gli eventi di aggiornamento e l'integrità del cluster durante tutto il processo.
  • Last updated on