Aggiornare un cluster Nexus Kubernetes dell'operatore di Azure

Questo articolo fornisce istruzioni su come aggiornare un cluster Operator Nexus Kubernetes 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, la configurazione e l'applicazione degli aggiornamenti al cluster Kubernetes.

Limitazioni

• Il processo di aggiornamento predefinito del cluster è un approccio con scalabilità orizzontale, ovvero viene aggiunto almeno un nodo aggiuntivo (o il numero di nodi configurati in max surge). Se non è disponibile una capacità sufficiente, l'aggiornamento non riesce.
• Quando diventano disponibili nuove versioni di Kubernetes, i cluster tenant non subiranno aggiornamenti automatici. 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.
• Operator Nexus offre aggiornamenti a livello di cluster, garantendo la coerenza tra tutti i pool di nodi. L'aggiornamento di un pool a nodo singolo 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 vengono perse durante gli aggiornamenti del cluster. Inserire queste personalizzazioni in DaemonSet anziché apportare modifiche manuali alla configurazione del nodo per conservarle dopo l'aggiornamento.
• Le modifiche apportate alle configurazioni di componenti aggiuntivi di base vengono ripristinate nella configurazione predefinita dell'addon come parte del processo di aggiornamento del cluster. Evitare di personalizzare la configurazione del componente aggiuntivo (ad esempio, Calico e così via) per evitare potenziali errori di aggiornamento. Se il ripristino della configurazione del componente aggiuntivo rileva problemi, potrebbe causare errori di aggiornamento.
• Le modifiche apportate alla configurazione etcd vengono ripristinate nella configurazione predefinita come parte del processo di aggiornamento del cluster. Evitare di personalizzare la configurazione etcd per evitare potenziali errori di aggiornamento. Se il ripristino della configurazione etcd rileva problemi, potrebbe causare errori di aggiornamento.
• Quando si aggiorna il cluster Operator Nexus Kubernetes, non è possibile ignorare le versioni secondarie di Kubernetes. È necessario eseguire tutti gli aggiornamenti in sequenza in base al numero di versione secondaria. Ad esempio, gli aggiornamenti compresi tra 1.14.x ->1.15.x o 1.15.x ->1.16.x sono consentiti, ma 1.14.x ->1.16.x non è consentito. Se la tua versione non è aggiornata rispetto a più di una versione minore, dovresti eseguire più aggiornamenti sequenziali.
• Alcuni percorsi di aggiornamento nelle versioni secondarie possono essere bloccati a causa di percorsi di aggiornamento dei componenti non supportati annidati all'interno del bundle di versione. Gli utenti devono assicurarsi che l'applicazione supporti il percorso di aggiornamento, inclusi tutti gli aggiornamenti nel bundle di versione. I salti più grandi tra gli aggiornamenti del bundle di versione aumentano il rischio. Aggiornare spesso i cluster per rimanere vicini alla versione più recente per ridurre al minimo il rischio di errore di aggiornamento.

Prerequisiti

• Un cluster Kubernetes Operatore Nexus di Azure distribuito nel gruppo di risorse della tua 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 installare o aggiornare, 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 versioni 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

1. Accedi al portale di Azure.
2. Navigare nel cluster Operator Nexus Kubernetes.
3. 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 sulla versione v1.25.4-3. Di conseguenza, le opzioni di aggiornamento disponibili includono v1.25.4-4 e la versione v1.25.6-1. patch più recente, inoltre, è disponibile anche una nuova versione secondaria.

È possibile eseguire l'aggiornamento a una delle versioni disponibili. Tuttavia, la procedura consigliata consiste nell'eseguire l'aggiornamento alla versione disponibile più recente major-minor-patch-versionbundle.

Aggiornare il cluster

Durante il processo di aggiornamento del cluster, Operator 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, il blocco e lo svuotamento di uno dei nodi del piano di controllo precedente. Assicurarsi che i carichi di lavoro in esecuzione su di esso vengano spostati normalmente in altri nodi del piano di controllo integro.
• 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.
  • Isolare e svuotare uno dei vecchi nodi di lavoro per ridurre al minimo le interruzioni alle applicazioni in esecuzione. Se si usa max surge, viene bloccato e svuotato il numero di nodi di lavoro contemporaneamente al numero di nodi del buffer specificato.
  • 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 tutti i nodi configurati in max surge)
• Se si aggiornano i nodi di lavoro senza picchi:
  • Per ogni pool di agenti nel cluster, un vecchio nodo di lavoro (o quanti nodi sono configurati da max unavailability) viene isolato, drenato e quindi rimosso, prima di essere sostituito da un nuovo nodo 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 a cui passare. Ciò può causare l'ingresso di pod in uno stato in sospeso se non è disponibile 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 nel cluster.

Preparare i carichi di lavoro da svuotare prima dell'aggiornamento. Assicurati che PodDisruptionBudgets (PDB) consentano lo spostamento di almeno una replica di pod alla volta. Controllare anche i periodi di tolleranza di terminazione, i finalizzatori, l'affinità dei nodi e i vincoli di topologia, la capacità del cluster e i carichi di lavoro che non possono essere rimossi. Queste condizioni possono impedire il completamento di uno svuotamento.

1. Aggiornare il cluster usando il comando networkcloud kubernetescluster update.

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

2. 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 il cluster esegue ora v1.26.3:

"v1.26.3"

3. Assicurarsi che il cluster sia funzionante correttamente.

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 la gestione di picchi o l'indisponibilità durante l'aggiornamento del nodo

Per impostazione predefinita, Operator Nexus configura gli aggiornamenti per l'espansione aggiungendo un nodo lavoratore in più. Un valore predefinito di uno per le impostazioni di "max surge" consente a Operator Nexus di ridurre al minimo l'interruzione del carico di lavoro creando un nodo aggiuntivo prima dell'isolare/spostare delle applicazioni esistenti per sostituire un nodo di una versione precedente. Il valore max surge può essere personalizzato per ogni pool di nodi per consentire un compromesso tra la velocità di aggiornamento e l'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 l'aumento massimo, è possibile che si verifichino interruzioni durante il processo di aggiornamento.

Ad esempio, un valore massimo di 100% fornisce il processo di aggiornamento più rapido possibile (raddoppiando il numero di nodi), ma comporta anche lo svuotamento simultaneo di tutti i nodi del 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 max_surge su 33%.

Non è sempre opportuno eseguire l'aggiornamento tramite picchi, ad esempio negli ambienti vincolati delle risorse. Gli aggiornamenti possono anche procedere senza picchi di attività, 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 pool di nodi dalla impostazione "max unavailable". Per impostazione predefinita, max non disponibile è impostato su 0. Ciò indica che al massimo 0 nodi non possono essere disponibili, ad esempio questo tipo di aggiornamento non verrà eseguito per impostazione predefinita.

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

"Uno dei "max surge" o "max non disponibili" deve essere almeno 1 (o 1%), altrimenti non ci sarebbe alcun meccanismo per aggiornare il cluster." Un valore percentuale viene arrotondato al numero di nodi più vicino. Sia il massimo aumento che il massimo non disponibile possono essere entrambi impostati al 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.

Le opzioni "massimo incremento" e "massima indisponibilità" possono essere configurate contemporaneamente, nel qual caso l'aggiornamento procederà attraverso una combinazione di incremento e indisponibilità.

È possibile aggiornare maxSurge, maxUnavailable e le impostazioni di drain in upgradeSettings dopo aver creato un pool di agenti. La modifica di queste impostazioni aggiorna la configurazione del pool di agenti esistente e di per sé non sostituisce né ruota alcun nodo. Se si modificano le impostazioni durante un aggiornamento, le nuove impostazioni si applicano ai nodi che non hanno avviato l'aggiornamento.

Ad esempio, usare il comando seguente per aggiornare un pool di agenti con un timeout di svuotamento di 30 minuti:

az networkcloud kubernetescluster agentpool update \
  --agent-pool-name <agent-pool-name> \
  --kubernetes-cluster-name <cluster-name> \
  --resource-group <resource-group> \
  --upgrade-settings drain-timeout=1800

Configurare il timeout di svuotamento del nodo di lavoro

Le impostazioni di svuotamento controllano per quanto tempo Operator Nexus attende il svuotamento di ogni nodo di lavoro durante un aggiornamento o una riduzione delle prestazioni. Queste impostazioni non si applicano ai nodi del piano di controllo. Il timeout di drenaggio del piano di controllo è impostato su cinque minuti e non può essere configurato.

Configurare upgradeSettings.drainTimeout con il numero massimo di secondi di attesa per il svuotamento di ogni nodo di lavoro. Se si omette questa impostazione, il timeout di svuotamento è 1.800 secondi (30 minuti).

I carichi di lavoro Kubernetes standard passano in modo nativo ai nuovi nodi quando i nodi precedenti vengono svuotati. Il servizio Nexus Kubernetes operator non può garantire il carico di lavoro per i comportamenti Kubernetes non standard.

Passaggi successivi

• Altre informazioni sui bundle di versioni di Nexus Kubernetes.