Aggiornamenti del pool di nodi blu-verde nel servizio Azure Kubernetes (anteprima)

Gli aggiornamenti blu-verde consentono di aggiornare i pool di nodi del servizio Azure Kubernetes aggiungendo nuovi nodi verdi con la configurazione aggiornata (Kubernetes e la versione dell'immagine del nodo) al pool di nodi esistente, mentre i nodi blu originali continuano a essere in esecuzione. Questa strategia consente di testare e convalidare la nuova configurazione prima di eseguire il commit alla nuova versione, con la possibilità di eseguire rapidamente il rollback in caso di problemi.

Questo articolo illustra quando usare gli aggiornamenti blu-verde, il funzionamento del processo, le opzioni di configurazione e le considerazioni per l'uso di questa strategia di aggiornamento.

Quando usare gli aggiornamenti blu-verde

Annotazioni

Tenere presente che gli aggiornamenti blu-verde richiedono il doppio della capacità del nodo durante il processo di aggiornamento, che può portare a costi e requisiti di risorse maggiori.

Prendere in considerazione gli aggiornamenti blu-verde quando:

  • È necessario eseguire test granulari e verifica dei carichi di lavoro batch per batch.
  • È necessario convalidare le nuove configurazioni dei nodi prima di passare al traffico di produzione.
  • Si vuole una funzionalità di rollback istantaneo senza effettuare il provisioning dei nodi.
  • Si stanno aggiornando carichi di lavoro critici di produzione che non possono essere interrotti.
  • È necessario testare la compatibilità delle applicazioni con le nuove versioni di Kubernetes.

Se attualmente si utilizza un processo di distribuzione blu-verde manuale per gli aggiornamenti del pool di nodi e si desidera automatizzare questo flusso di lavoro, conviene considerare l'uso degli aggiornamenti del pool di nodi blu-verde AKS. Per altre informazioni sul processo di aggiornamento manuale blu verde, vedere Aggiornamenti manuali del pool di nodi blu-verde.

Quando usare gli aggiornamenti in sequenza standard

Gli aggiornamenti in sequenza standard potrebbero essere più appropriati negli scenari seguenti:

  • Ambienti di sviluppo o test con tolleranza di inattività.
  • Distribuzioni sensibili ai costi in cui il raddoppio temporaneo è proibitivo.
  • Applicazioni senza stato semplici con una gestione efficace delle interruzioni.
  • Ambienti con capacità o quota disponibile limitata.

Prerequisiti

Installare l'estensione aks-preview interfaccia della riga di comando di Azure

Importante

Le funzionalità di anteprima di AKS sono disponibili su base self-service, su scelta. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Installare o aggiornare l'estensione aks-preview usando i az extension add comandi e az extension update .

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

# Update the aks-preview extension
az extension update --name aks-preview

Funzionalità supportate per gli aggiornamenti blu-verde

Gli aggiornamenti blu-verde supportano attualmente le funzionalità seguenti:

Limitazioni e considerazioni per l'aggiornamento blu-verde

Gli aggiornamenti blu-verde attualmente non supportano le funzionalità seguenti:

Quando si usano gli aggiornamenti blu-verde, tenere presenti le considerazioni seguenti:

Requisiti risorsa Considerazioni sulla complessità Fattori di tempo
* Richiede il doppio della capacità del nodo durante il processo di aggiornamento, con conseguente aumento dei costi dell'infrastruttura.
* È necessaria una quota di calcolo aggiuntiva nella sottoscrizione Azure per supportare il raddoppio temporaneo dei nodi.
* È possibile che si verifichino limiti di capacità a livello di area durante i periodi di utilizzo di picco.		 * Richiede un'attenta pianificazione affinché i carichi di lavoro con stato garantiscano la coerenza dei dati durante la migrazione.
* Richiede un monitoraggio aggiuntivo per i nodi blu e verde durante il periodo di transizione.		 * Durata complessiva dell'aggiornamento più lunga rispetto agli aggiornamenti sul posto.
* Il periodo di convalida aggiunge tempo prima del cutover finale.

Flusso di lavoro di aggiornamento blu-verde

Il processo di aggiornamento blu-verde crea un ambiente parallelo per le transizioni sicure tra le versioni del pool di nodi. È possibile eseguire l'aggiornamento e effettuare il commit nel nuovo pool verde dopo la convalida o, se si verificano problemi, eseguire l'aggiornamento e il rollback al pool blu.

Scenario di aggiornamento e commit

Il diagramma seguente illustra il flusso di lavoro di aggiornamento e commit:

Diagramma che mostra il flusso di lavoro dello scenario di aggiornamento e commit.

Il processo di aggiornamento e commit è il seguente:

  1. Cordon blue nodes: i nodi blu esistenti sono contrassegnati come non programmabili.
  2. Aggiungere nodi verdi: nuovi nodi verdi con la configurazione aggiornata vengono aggiunti al pool di nodi esistente.
  3. Operazione parallela: i nodi blu e verde vengono eseguiti simultaneamente all'interno dello stesso pool di nodi.
  4. Migrazione graduale: i carichi di lavoro vengono progressivamente svuotati dai nodi blu e riprogrammati in nodi verdi in batch.
  5. Convalidare i nodi verdi: monitorare e testare i carichi di lavoro nei nuovi nodi durante la migrazione.
  6. Transizione completa: dopo il periodo di convalida finale, i nodi blu vengono eliminati e i nodi verdi diventano primari.

Scenario di rollback e aggiornamento

Il diagramma seguente illustra il flusso di lavoro di aggiornamento e ripristino:

Diagramma che mostra il flusso di lavoro dello scenario di aggiornamento e rollback.

Il processo di aggiornamento e rollback è il seguente:

  1. Cordon blue nodes: i nodi blu esistenti sono contrassegnati come non programmabili.
  2. Aggiungere nodi verdi: nuovi nodi verdi con la configurazione aggiornata vengono aggiunti al pool di nodi esistente.
  3. Operazione parallela: i nodi blu e verde vengono eseguiti simultaneamente all'interno dello stesso pool di nodi.
  4. Individuare i Problemi: identificare i problemi durante la convalida nei nodi verdi.
  5. Eseguire il rollback: rimuovere i nodi blu , svuotare i nodi verdi ed eseguire di nuovo la migrazione dei carichi di lavoro ai nodi blu .
  6. Stato di ripristino: i nodi verdi vengono eliminati e il pool di nodi torna alla configurazione originale.

Scegliere la strategia di aggiornamento

Quando si crea o si aggiorna un pool di nodi del servizio Azure Kubernetes, è possibile specificare la strategia di aggiornamento (upgradeStrategy) da usare. Le strategie disponibili includono:

Strategia Descrzione
Rolling (impostazione predefinita) Aggiornamento progressivo standard in cui i nodi vengono aggiornati uno alla volta.
BlueGreen Aggiunge nuovi nodi verdi con la configurazione aggiornata al pool di nodi esistente mantenendo in esecuzione i nodi blu originali.

Personalizzare le proprietà di aggiornamento blu-verde

È possibile personalizzare le proprietà di aggiornamento blu-verde seguenti (NodePoolBlueGreenUpgradeSettings):

Proprietà Descrzione Valori consentiti Valore predefinito
drainBatchSize Numero o percentuale di nodi da svuotare in ogni batch durante l'aggiornamento. La percentuale viene calcolata dal numero totale di nodi blu all'inizio dell'aggiornamento. I nodi frazionari vengono arrotondati. Integer (ad esempio, 5) o percentuale (ad esempio, 50%). Deve essere un valore diverso da zero. 10%
drainTimeoutInMinutes Tempo massimo (in minuti) da attendere affinché i pod si terminino correttamente su ciascun nodo prima di considerare l'aggiornamento non riuscito. Rispetta i budget di interruzione dei pod durante questo periodo di attesa. Se superato, l'aggiornamento non riesce. Intero compreso tra 1 e 1440 (24 ore). 30 minuti
batchSoakDurationInMinutes Tempo di pausa (in minuti) tra il drenaggio di batch di nodi per consentire l'osservazione e la convalida. Intero compreso tra 0 e 1440 (24 ore). 15 minuti
finalSoakDurationInMinutes Tempo di attesa (in minuti) dopo che tutti i nodi vengono svuotati prima di rimuovere i nodi precedenti. Fornisce un periodo di convalida finale prima di eseguire il commit dell'aggiornamento. Le operazioni di rollback sono disponibili solo durante questo periodo di attesa finale. Una volta scaduto questo periodo e il pool blu viene eliminato, il rollback non è più possibile. Intero compreso tra 0 e 10080 (sette giorni). 60 minuti

Creare un pool di nodi con le impostazioni di aggiornamento blu-verde predefinite

  • Creare un pool di nodi con la strategia di aggiornamento blu-verde predefinita e le impostazioni usando il az aks nodepool add comando con il --upgrade-strategy parametro impostato su bluegreen. L'esempio seguente crea un nuovo pool di nodi denominato myNodePool nel cluster AKS myAKSCluster all'interno del gruppo di risorse myResourceGroup:

    az aks nodepool add \
    --name myNodePool \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --upgrade-strategy bluegreen

Creare un pool di nodi con impostazioni di aggiornamento blu-verde personalizzate

  • Creare un pool di nodi con impostazioni di aggiornamento blu-verde personalizzate usando il comando con il az aks nodepool add--upgrade-strategy parametro impostato su bluegreen e impostare le impostazioni di aggiornamento blu-verde desiderate. L'esempio seguente crea un nuovo pool di nodi denominato myNodePool nel cluster myAKSCluster del servizio Azure Kubernetes all'interno del gruppo myResourceGroupdi risorse , con impostazioni di aggiornamento blu-verde personalizzate:

    az aks nodepool add \
    --name myNodePool \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --upgrade-strategy bluegreen \
    --drain-timeout-bg 5 \
    --batch-soak-duration 5 \
    --drain-batch-size 50% \
    --final-soak-duration 180

Avviare un aggiornamento blu-verde per un pool di nodi esistente

Importante

Quando si riprende un aggiornamento sospeso, è possibile aggiornare le impostazioni blu-verde, ma non è possibile modificare la strategia di aggiornamento o la versione di Kubernetes.

  • Avviare un aggiornamento blu-verde per un pool di nodi esistente usando il az aks nodepool upgrade comando con il --kubernetes-version parametro impostato sulla versione desiderata. È possibile avviare un aggiornamento blu-verde per un pool di nodi già usando la strategia blu-verde o per un pool di nodi non ancora configurato con strategia blu-verde. Gli esempi seguenti illustrano entrambi gli scenari:

    # Start a blue-green upgrade for an existing node pool already using blue-green strategy
az aks nodepool upgrade \
    --name myNodePool \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --kubernetes-version <kubernetes-version>

# Start a blue-green upgrade for an existing node pool not yet using blue-green strategy
az aks nodepool upgrade \
    --name myNodePool \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --kubernetes-version <kubernetes-version> \
    --upgrade-strategy bluegreen

Sospendere o annullare un aggiornamento blu-verde

  • Sospendere o annullare un aggiornamento blu-verde in corso usando il az aks nodepool operation-abort comando . L'esempio seguente sospende o annulla l'aggiornamento blu-verde per il pool di nodi denominato myNodePool nel cluster myAKSCluster all'interno del gruppo myResourceGroup di risorse:

    az aks nodepool operation-abort \
    --name myNodePool \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup

Eseguire il rollback di un aggiornamento blu-verde

Dopo l'annullamento di un aggiornamento blu-verde in corso, è possibile avviare il rollback usando il az aks nodepool rollback comando .

Il rollback è disponibile solo durante il periodo di immersione finale, come descritto nella proprietà finalSoakDurationInMinutes .

L'esempio seguente esegue un annullamento dell'aggiornamento blue-green per il pool di nodi denominato myNodePool nel cluster myAKSCluster di AKS all'interno del gruppo myResourceGroup di risorse:

az aks nodepool rollback \
    --name myNodePool \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup

Domande frequenti

Gli aggiornamenti blu-verde supportano l'impostazione maxUnavailable ?

No, l'impostazione maxUnavailable non è applicabile agli aggiornamenti blu-verde. I nuovi nodi verdi vengono aggiunti al pool di nodi esistente insieme ai nodi blu esistenti, assicurando che tutti i nodi originali rimangano disponibili durante il processo di aggiornamento.

Gli aggiornamenti blu-verde possono essere usati per gli aggiornamenti del pool di nodi oltre alla versione di Kubernetes e dell'immagine del nodo?

No, al momento la strategia di aggiornamento blu-verde è specifica per Kubernetes e per gli aggiornamenti delle versioni dell'immagine del nodo. Altre modifiche, ad esempio la rotazione dei certificati o kubelet e le modifiche alla configurazione del sistema operativo, non possono essere eseguite tramite la strategia di aggiornamento blu-verde.

Quali versioni di Kubernetes sono compatibili con gli aggiornamenti blu-verde?

Gli aggiornamenti blu-verde funzionano con tutte le versioni di Kubernetes supportate dal servizio Azure Kubernetes, incluse entrambe le versioni supportate dalla community e le versioni LTS (Long Term Support), purché si usi la versione 2025-08-02-preview dell'API o versioni successive.

È possibile usare il canale automatico delle patch di sicurezza con aggiornamenti blu-verde?

Sì, purché la strategia di aggiornamento del pool di nodi sia configurata per l'uso di blu-verde. Se configurate, le patch di sicurezza seguono il processo di aggiornamento blu-verde anziché il meccanismo di aggiornamento in sequenza predefinito.

Cosa accade ai volumi persistenti durante gli aggiornamenti blu-verde?

I volumi permanenti rimangono accessibili. I pod vengono svuotati e ripianificati correttamente, mantenendo i loro collegamenti dei volumi.

È possibile eseguire aggiornamenti blu-verde tra più pool di nodi contemporaneamente?

Sì, i pool di nodi diversi possono essere sottoposti a aggiornamenti blu-verde in parallelo, ma ogni pool può avere un solo aggiornamento attivo. Attualmente non è possibile controllare l'ordine degli aggiornamenti in più pool.

In che modo gli aggiornamenti blu-verde gestiscono configurazioni specifiche dei nodi, quali taint ed etichette?

Tutte le configurazioni dei nodi, incluse le etichette e le annotazioni, vengono replicate automaticamente nel pool verde .

Qual è l'impatto sui costi degli aggiornamenti blu-verde?

Si pagano sia i nodi blu originali che i nuovi nodi verdi durante la finestra di aggiornamento, quindi assicuratevi di pianificare il raddoppio temporaneo dei costi nel periodo di transizione.

Cosa accade durante un errore di capacità?

In caso di errore di capacità durante l'aggiunta dei nodi verdi , l'aggiornamento non riesce e i nodi blu rimangono invariati. È possibile ritentare l'aggiornamento dopo che è disponibile una capacità sufficiente o scegliere di eseguire il rollback.

Cosa accade durante il rollback?

Se il numero di nodi verdi è minore o uguale al numero di nodi blu all'avvio del rollback, i nodi verdi vengono rimossi e i nodi blu vengono sbloccati e riattivati per riprendere il normale funzionamento.

Contenuti correlati

Per ulteriori informazioni sugli aggiornamenti del pool di nodi in Azure Kubernetes Service (AKS), consultare i seguenti articoli:

  • Last updated on