Aggiornare un cluster Kubernetes dell'Operatore Nexus di Azure

Articolo
10/14/2024

Questo articolo fornisce istruzioni su come aggiornare un cluster Kubernetes dell'Operatore Nexus per ottenere le funzionalità e gli aggiornamenti della sicurezza più recenti. Parte del ciclo di vita del cluster Kubernetes prevede l'esecuzione di aggiornamenti periodici alla versione più recente di Kubernetes. È importante applicare le versioni di sicurezza più recenti o eseguire l'aggiornamento per ottenere le funzionalità più recenti. Questo articolo illustra come verificare la presenza di aggiornamenti al cluster Kubernetes, configurarli e applicarli.

Limiti

Il processo di aggiornamento predefinito del cluster è un approccio scale-out, il che significa che viene aggiunto almeno un nodo in più (o il numero di nodi configurato in max surge). Se non è disponibile una capacità sufficiente, l'aggiornamento non riesce.
Quando diventano disponibili nuove versioni di Kubernetes, i cluster dei tenant non vengono aggiornati automaticamente. Gli utenti devono avviare l'aggiornamento quando tutte le funzioni di rete nel cluster sono pronte per supportare la nuova versione di Kubernetes. Per altre informazioni, vedere Aggiornare il cluster.
L'Operatore Nexus offre aggiornamenti a livello di cluster, garantendo la coerenza tra tutti i pool di nodi. L'aggiornamento di un singolo pool di nodi non è supportato. Inoltre, l'immagine del nodo viene aggiornata come parte dell'aggiornamento del cluster quando è disponibile una nuova versione.
Le personalizzazioni apportate ai nodi dell'agente andranno perse durante gli aggiornamenti del cluster. È consigliabile inserire queste personalizzazioni in DaemonSet anziché apportare modifiche manuali alla configurazione del nodo in modo da conservarle dopo l'aggiornamento.
Le modifiche apportate alle configurazioni dei componenti aggiuntivi di base vengono ripristinate nella configurazione predefinita dei componenti aggiuntivi come parte del processo di aggiornamento del cluster. Evitare di personalizzare la configurazione dei componenti aggiuntivi (ad esempio, Calico e così via) per evitare potenziali errori di aggiornamento. Se il ripristino della configurazione dei componenti aggiuntivi rileva problemi, potrebbe causare errori di aggiornamento.
Quando si aggiorna il cluster Kubernetes dell'Operatore Nexus, non è possibile ignorare le versioni secondarie di Kubernetes. È necessario eseguire tutti gli aggiornamenti in sequenza in base al numero di versione principale. Sono consentiti, ad esempio, gli aggiornamenti da 1.14.x a>1.15.x o da 1.15.x a>1.16.x, ma non da 1.14.x a>1.16.x. Se la versione usata è precedente a più di una versione principale, è necessario eseguire più aggiornamenti sequenziali.
I valori max surge e/o max unavailable devono essere impostati durante la creazione del cluster. Non è possibile modificare questi valori dopo la creazione del cluster. Per altre informazioni, vedere upgradeSettings in Creare un cluster Kubernetes dell'Operatore Nexus di Azure.

Prerequisiti

Un cluster Nexus Kubernetes dell'Operatore Nexus di Azure distribuito in un gruppo di risorse nella sottoscrizione di Azure.
Se si usa l'interfaccia della riga di comando di Azure, questo articolo richiede l'esecuzione della versione più recente dell'interfaccia della riga di comando di Azure. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
Versione minima richiesta dell'estensione networkcloud az-cli: 2.0.b3
Comprendere il concetto di bundle di versione. Per altre informazioni, vedere Bundle di versione di Nexus Kubernetes.

Verificare la disponibilità di aggiornamenti

Verificare quali versioni di Kubernetes sono disponibili per il cluster seguendo questa procedura:

Utilizzare l'interfaccia della riga di comando di Azure

Il comando seguente dell'interfaccia della riga di comando di Azure restituisce gli aggiornamenti disponibili per il cluster:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Output di esempio:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Usare il portale di Azure

Accedere al portale di Azure.
Passare al cluster Kubernetes dell'Operatore Nexus.
In Panoramica selezionare la scheda Aggiornamenti disponibili.

Scegliere una versione a cui eseguire l'aggiornamento

L'output dell'aggiornamento disponibile indica che sono disponibili più versioni tra cui scegliere per l'aggiornamento. In questo scenario specifico, il cluster corrente funziona nella versione v1.25.4-3. Di conseguenza, le opzioni di aggiornamento disponibili includono v1.25.4-4 e la versione patch più recente v1.25.6-1.. Inoltre, è disponibile anche una nuova versione secondaria.

È possibile eseguire l'aggiornamento a una delle versioni disponibili. Tuttavia, è consigliabile eseguire l'aggiornamento alla versione più recente disponibile major-minor-patch-versionbundle.

Nota

Il formato di input per la versione è major.minor.patch o major.minor.patch-versionbundle. L'input della versione deve essere una delle versioni di aggiornamento disponibili. Ad esempio, se la versione corrente del cluster è 1.1.1-1, gli input di versione validi sono 1.1.1-2 o 1.1.1-x. Anche se 1.1.1 è un formato valido, non attiverà alcun aggiornamento perché la versione corrente è già 1.1.1. Per avviare un aggiornamento, è possibile specificare la versione completa con il bundle di versione, ad esempio 1.1.1-2. Tuttavia, 1.1.2 e 1.2.x sono input validi e useranno il bundle di versione più recente disponibile per 1.1.2 o 1.2.x.

Aggiornare il cluster

Durante il processo di aggiornamento del cluster, l'Operatore Nexus esegue le operazioni seguenti:

Aggiungere un nuovo nodo del piano di controllo con la versione di Kubernetes specificata al cluster.
Dopo l'aggiunta del nuovo nodo, bloccare e svuotare uno dei nodi del piano di controllo precedenti, assicurandosi che i carichi di lavoro in esecuzione su di esso vengano spostati normalmente in altri nodi del piano di controllo integri.
Dopo che il nodo del piano di controllo precedente è stato svuotato, viene rimosso e viene aggiunto un nuovo nodo del piano di controllo al cluster.
Questo processo viene ripetuto fino a quando non vengono aggiornati tutti i nodi del piano di controllo nel cluster.
Se si aggiornano i nodi di lavoro tramite un picco (impostazione predefinita):
- Per ogni pool di agenti nel cluster, aggiungere un nuovo nodo di lavoro (o tutti i nodi configurati in max surge) con la versione di Kubernetes specificata. Più pool di agenti vengono aggiornati contemporaneamente.
- Bloccare e svuotare uno dei nodi di lavoro precedenti per ridurre al minimo l'interruzione delle applicazioni in esecuzione. Se si usa max surge, blocca e svuota contemporaneamente tanti nodi di lavoro quanti sono i nodi del buffer specificati.
- Dopo che il nodo di lavoro precedente è stato svuotato, viene rimosso e viene aggiunto un nuovo nodo di lavoro con la nuova versione di Kubernetes al cluster (o il numero di nodi configurato in max surge)
Se si aggiornano i nodi di lavoro senza picchi:
- Per ogni pool di agenti nel cluster, un nodo di lavoro precedente (o il numero di nodi configurato da max unavailable) viene bloccato, svuotato e quindi rimosso, prima di essere sostituito da un nuovo nodo di lavoro con la versione di Kubernetes specificata. Più pool di agenti vengono aggiornati contemporaneamente.
- Durante l'aggiornamento, si verifica una riduzione temporanea della capacità del cluster perché i pod svuotati dal nodo di lavoro precedente non avranno immediatamente un nuovo nodo in cui essere spostati. Questo può far sì che i pod entrino in uno stato in sospeso se non esiste una capacità sufficiente. È quindi fondamentale progettare il cluster per soddisfare i requisiti di capacità dell'applicazione, soprattutto durante gli aggiornamenti senza picchi.
Questo processo viene ripetuto fino a quando non vengono aggiornati tutti i nodi di lavoro del cluster.

Nota

L'aggiornamento del cluster non creerà nuovi nodi e sostituirà quelli precedenti se la versione dell'immagine del sistema operativo e la versione di Kubernetes rimangono invariate tra i bundle di versione. Si tratta di un comportamento previsto, poiché l'aggiornamento può includere solo gli aggiornamenti alle versioni dei componenti aggiuntivi anziché alle nuove versioni del sistema operativo o di Kubernetes. Poiché non è previsto alcun aggiornamento in sequenza, non esiste alcun blocco e svuotamento sui nodi, quindi non si verificheranno interruzioni del pod.

Importante

Assicurarsi che qualsiasi PodDisruptionBudgets (PDB) consenta lo spostamento di almeno una replica pod alla volta. In caso contrario, l'operazione di svuotamento/eliminazione avrà esito negativo. Se l'operazione di svuotamento non riesce, anche l'operazione di aggiornamento avrà esito negativo, per garantire che le applicazioni non vengano interrotte. Correggere ciò che ha causato l'arresto dell'operazione, ad esempio PDB non corretti, mancanza di quota e così via, e riprovare l'operazione. È anche possibile configurare un timeout di svuotamento per ogni pool di nodi di lavoro, dopo il quale il nodo verrà rimosso anche se i pod non hanno ancora terminato lo svuotamento. Ciò può impedire che gli aggiornamenti vengano bloccati da PDB configurati in modo errato. L'impostazione di timeout di svuotamento è configurata in secondi e il valore predefinito è 1800.

Aggiornare il cluster usando il comando networkcloud kubernetescluster update.

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

Verificare che l'aggiornamento sia riuscito usando il comando show.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

L'output di esempio seguente mostra che ora nel cluster viene eseguita la versione 1.26.3:

"v1.26.3"

Assicurarsi che il cluster sia integro.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

L'output di esempio seguente mostra che il cluster è integro:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Personalizzare l'aggiornamento del picco o dell'indisponibilità dei nodi

Per impostazione predefinita, l'Operatore Nexus configura gli aggiornamenti per aumentare le operazioni con un nodo di lavoro aggiuntivo. Un valore predefinito di uno per le impostazioni di max surge consente all'Operatore Nexus di ridurre al minimo le interruzioni del carico di lavoro creando un nodo aggiuntivo prima del blocco/svuotamento delle applicazioni esistenti per sostituire un nodo con controllo delle versioni precedente. È possibile personalizzare il valore max surge per ogni pool di nodi per consentire un compromesso tra velocità di aggiornamento e interruzione dell'aggiornamento. Quando si aumenta il valore max surge, il processo di aggiornamento viene completato più velocemente. Se si imposta un valore elevato per max surge, è possibile che si verifichino interruzioni durante il processo di aggiornamento.

Ad esempio, un valore max surge del 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 un valore superiore, ad esempio questo per gli ambienti di test. Per i pool di nodi di produzione, è consigliabile impostare un valore max_surge del 33%.

Non è sempre opportuno eseguire l'aggiornamento tramite picchi, ad esempio negli ambienti con risorse limitate. Gli aggiornamenti possono essere eseguiti anche senza picchi, in cui un nodo di lavoro viene prima rimosso e quindi sostituito. Ciò significa che non è necessaria alcuna risorsa aggiuntiva, ma comporta periodi di capacità ridotta in cui i pod potrebbero non essere in grado di essere pianificati in un nodo. Questo tipo di aggiornamento è controllato per ogni pool di nodi dall'impostazione max unavailable. Per impostazione predefinita, max unavailable è impostato su 0. Ciò indica che al massimo 0 nodi possono essere non disponibili, ovvero questo tipo di aggiornamento non verrà eseguito per impostazione predefinita.

L'API accetta valori interi e un valore percentuale per max surge e max unavailable. Un numero intero, ad esempio 5, indica che è possibile aumentare o rendere non disponibili cinque nodi. Un valore pari al 50% indica un valore di aumento/non disponibilità della metà del numero di nodi corrente nel pool.

Uno dei valori max surge o max unavailable deve essere almeno 1 (o 1%), altrimenti non esisterebbe alcun meccanismo in base al quale il cluster potrebbe essere aggiornato. Un valore percentuale viene arrotondato al numero di nodi più vicino. Sia il valore max surge che il valore max unavailable possono essere impostati su un massimo del 100%. Se il valore di sovratensione massima è superiore al numero necessario di nodi da aggiornare, viene usato il numero di nodi da aggiornare per il valore di sovratensione massima.

È possibile configurare contemporaneamente max surge and max unavailable, nel qual caso l'aggiornamento procederà con una combinazione di picco e indisponibilità.

Importante

I carichi di lavoro Kubernetes standard passano in modo nativo ai nuovi nodi quando vengono svuotati dai nodi che vengono eliminati. Tenere presente che il servizio Kubernetes dell'Operatore Nexus non può promettere carichi di lavoro per comportamenti Kubernetes non standard.

Passaggi successivi

Altre informazioni sui Bundle di versione di Nexus Kubernetes.

Condividi tramite