Aggiornare il piano di controllo del cluster del servizio Azure Kubernetes

I cluster del servizio Azure Kubernetes sono costituiti da due componenti principali: il piano di controllo gestito da Azure e i pool di nodi in cui vengono eseguiti i carichi di lavoro. Questo articolo è incentrato sull'aggiornamento del piano di controllo in modo indipendente, che consente di adottare nuove versioni di Kubernetes per le funzionalità del server API, gestendo separatamente gli aggiornamenti del pool di nodi.

Prima di iniziare

  • Se si usa l'interfaccia della riga di comando di Azure, questo articolo richiede l'interfaccia della riga di comando di Azure versione 2.34.1 o successiva. Usare il az --version comando per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
  • Se si usa Azure PowerShell, questo articolo richiede Azure PowerShell versione 5.9.0 o successive. Usare il Get-InstalledModule -Name Az cmdlet per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare Azure PowerShell.
  • Per eseguire operazioni di aggiornamento, sono necessarie le autorizzazioni servizio Azure Kubernetes Ruolo collaboratore o equivalenti.
  • Le API beta sono disabilitate per impostazione predefinita quando si esegue l'aggiornamento alle versioni di Kubernetes 1.30 e 1.27 LTS.

Avvertimento

Assicurarsi di disporre di una quota di calcolo sufficiente prima dell'aggiornamento. Se la quota è bassa, l'aggiornamento potrebbe non riuscire. Per altre informazioni, vedere aumentare le quote.

Panoramica dei tipi di aggiornamento di AKS

La tabella seguente illustra tre tipi di aggiornamenti del servizio Azure Kubernetes, evidenziandone l'ambito e i casi d'uso:

Tipo di aggiornamento Ambito Caso d'uso
Solo piano di controllo Server API, etcd, gestione controller, utilità di pianificazione Testare le nuove API Kubernetes prima di aggiornare i carichi di lavoro
Cluster completo Piano di controllo e tutti i pool di nodi Aggiornamento standard per mantenere aggiornato il cluster
Pool di nodi soltanto Pool di nodi specifici Implementazione a fasi dopo l'aggiornamento del piano di controllo

Suggerimento

L'aggiornamento del piano di controllo consente innanzitutto di convalidare la compatibilità dell'API Kubernetes prima di influire sui carichi di lavoro in esecuzione. Per le strategie di aggiornamento del pool di nodi, vedere Configurare gli aggiornamenti in sequenza.

Regole di aggiornamento della versione di Kubernetes

Quando si aggiorna un cluster del servizio Azure Kubernetes non LTS supportato, non è possibile ignorare le versioni secondarie di Kubernetes. È necessario eseguire tutti gli aggiornamenti in sequenza in base al numero di versione secondaria. Ad esempio, sono consentiti gli aggiornamenti tra 1.28.x ->1.29.x o 1.29.x ->1.30.x . 1.28.x ->1.30.x non è consentito.

Un cluster LTS può ignorare le versioni secondarie quando si passa a una versione LTS superiore offerta dal servizio Azure Kubernetes, a condizione che l'aggiornamento soddisfi i requisiti di asimmetria della versione e i controlli di convalida. Per altre informazioni, vedere È possibile ignorare più versioni del servizio Azure Kubernetes durante un aggiornamento del cluster?

A partire da Kubernetes 1.28, il piano di controllo può avere fino a tre versioni secondarie prima dei pool di nodi. Ad esempio, se il piano di controllo è 1.35.x, i pool di nodi possono essere 1.32.x, 1.33.x, 1.34.x o 1.35.x. Per i vincoli correnti, vedere i criteri di asimmetria della versione del servizio Azure Kubernetes.

Verificare la disponibilità di aggiornamenti per AKS

Suggerimento

Per rimanere aggiornati sulle versioni e gli aggiornamenti più recenti del servizio Azure Kubernetes, vedere lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.

Verificare la disponibilità delle versioni di Kubernetes per il cluster AKS usando il comando az aks get-upgrades.

az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table

L'output di esempio seguente mostra la versione corrente come 1.28.9 ed elenca le versioni disponibili in upgrades:

Name     ResourceGroup          MasterVersion    Upgrades
-------  ---------------        ---------------  --------------
default  <resource-group-name>  1.28.9           1.29.2, 1.29.4

Aggiornare solo il piano di controllo di AKS

Importante

Non è possibile eseguire un aggiornamento solo del piano di controllo quando l'aggiornamento automatico del cluster è abilitato. Il downgrade automatico del cluster aggiorna sempre il piano di controllo e tutti i pool di nodi insieme.

  1. Aggiorna il piano di controllo usando il comando az aks upgrade con il flag --control-plane-only. L'esempio seguente aggiorna il piano di controllo a Kubernetes versione 1.29.4:

    az aks upgrade \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --kubernetes-version 1.29.4 \
    --control-plane-only

  2. Verificare che l'aggiornamento del piano di controllo sia riuscito usando il az aks show comando .

    az aks show --resource-group <resource-group-name> --name <cluster-name> --output table

    L'output di esempio seguente mostra che il piano di controllo esegue ora la versione 1.29.4:

    Name            Location    ResourceGroup          KubernetesVersion    ProvisioningState    Fqdn
------------    ----------  ---------------        -------------------  -------------------  ------------------------------------------------
<cluster-name>  eastus      <resource-group-name>  1.29.4               Succeeded            <cluster-name>-dns-123abcd4.hcp.eastus.azmk8s.io

  3. Verificare che le versioni del pool di nodi rimangano invariate usando il az aks nodepool list comando .

    az aks nodepool list --resource-group <resource-group-name> --cluster-name <cluster-name> --query "[].{Name:name,Version:orchestratorVersion}" --output table

    Nell'output i pool di nodi devono comunque mostrare la versione precedente di Kubernetes.

Aggiornare l'intero cluster AKS

Annotazioni

Durante un aggiornamento completo del cluster, AKS aggiorna prima il piano di controllo e poi ciascun pool di nodi sequenzialmente. Per un maggiore controllo sugli aggiornamenti del pool di nodi, vedere Configurare gli aggiornamenti in sequenza.

Aggiornare il cluster completo (piano di controllo e tutti i pool di nodi) usando il az aks upgrade comando . L'esempio seguente aggiorna il cluster alla versione 1.29.4 di Kubernetes:

az aks upgrade \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --kubernetes-version 1.29.4

Domande frequenti per l'aggiornamento del piano di controllo del servizio Azure Kubernetes

Un aggiornamento solo piano di controllo aggiorna anche i pool di nodi?

No. Un aggiornamento solo del piano di controllo non modifica i pool di nodi. Il livello di aggiornamento automatico del cluster funziona in modo diverso: non supporta gli aggiornamenti solo del piano di controllo e aggiorna il piano di controllo e tutti i pool di nodi insieme.

È possibile aggiornare i pool di nodi prima del piano di controllo?

No. La versione del piano di controllo deve essere sempre uguale o maggiore di qualsiasi versione del pool di nodi. È innanzitutto necessario aggiornare il piano di controllo.

Quanto tempo richiede un aggiornamento del piano di controllo?

La durata dell'aggiornamento varia in base allo stato del cluster e alle condizioni Azure. Monitorare provisioningState usando az aks show o Get-AzAksCluster. L'aggiornamento viene completato quando lo stato del provisioning è Succeeded.

Risolvere i problemi di aggiornamento del piano di controllo

Nessun aggiornamento disponibile

Per un cluster non supportato, usare az aks get-upgrades per verificare se il servizio Azure Kubernetes offre una destinazione supportata idonea. Se è disponibile una destinazione, eseguire un aggiornamento full-cluster. Gli aggiornamenti solo del piano di controllo non sono supportati per questo percorso di ripristino.

Se non è disponibile alcuna destinazione, il cluster potrebbe essere già nella versione supportata più recente. Se il cluster esegue una versione non supportata, creare un nuovo cluster con una versione supportata ed eseguire la migrazione dei carichi di lavoro.

Aggiornamento non riuscito a causa di API deprecate

Prima dell'aggiornamento, verificare la presenza di API deprecate usando strumenti come kube-no-trouble (kubent):Before upgrade, check for deprecated APIs using tools like kube-no-trouble (kubent):

kubent

Il comando analizza le risorse accessibili tramite il contesto kubeconfig corrente per le versioni deprecate dell'API Kubernetes. L'output raggruppa i risultati in base alla versione di Kubernetes e identifica ogni risorsa interessata da KIND, NAMESPACENAME, e API_VERSION. Aggiornare il manifesto di origine per ogni risorsa elencata per usare una versione dell'API supportata prima dell'aggiornamento.

Contenuti correlati

  • Last updated on