servizio Azure Kubernetes linee guida per l'aggiornamento e l'applicazione di patch

Questa sezione della guida operativa del servizio Azure Kubernetes (AKS) day-2 descrive le strategie di applicazione di patch e aggiornamento per i nodi del ruolo di lavoro del servizio Azure Kubernetes e le versioni di Kubernetes. In qualità di operatore del cluster, è necessario avere un piano per mantenere aggiornati i cluster e monitorare le modifiche e le deprecazioni dell'API Kubernetes nel tempo.

Background e tipi di aggiornamenti

Esistono tre tipi di aggiornamenti per il servizio Azure Kubernetes e ognuno si basa sull'aggiornamento precedente:

Tipologie di aggiornamento

• Patch di sicurezza del sistema operativo del nodo (solo Linux): Per i nodi Linux, sia Canonical Ubuntu che Azure Linux rendono disponibili le patch di sicurezza del sistema operativo una volta al giorno. Microsoft testa e aggrega queste patch negli aggiornamenti settimanali alle immagini del nodo.

• Aggiornamenti settimanali alle immagini del nodo: AKS fornisce aggiornamenti settimanali alle immagini del nodo. Questi aggiornamenti includono le patch di sicurezza più recenti del sistema operativo e del servizio Azure Kubernetes, correzioni di bug e miglioramenti. Gli aggiornamenti del nodo non modificano la versione di Kubernetes. Le versioni vengono formattate per data (ad esempio, 202311.07.0) per Linux e per data di compilazione e data del sistema operativo Windows Server (ad esempio, 20348.2113.231115) per Windows. Per ulteriori informazioni, vedere Stato della versione di AKS.

• Versioni trimestrali di Kubernetes: AKS fornisce aggiornamenti trimestrali per le versioni di Kubernetes. Questi aggiornamenti consentono agli utenti del servizio Azure Kubernetes di usare le funzionalità e i miglioramenti più recenti di Kubernetes, ad esempio patch di sicurezza e aggiornamenti delle immagini dei nodi. Per altre informazioni, vedere Versioni Kubernetes supportate nel servizio Azure Kubernetes.

Considerazioni sul pre-aggiornamento

Prima di aggiornare i nodi worker AKS e le versioni di Kubernetes, valutare i seguenti effetti e le migliori pratiche.

Impatto complessivo del cluster

• Gli aggiornamenti sul posto per nodi e cluster influiscono sulle prestazioni dell'ambiente Kubernetes mentre sono in corso. È possibile ridurre al minimo questo effetto tramite la corretta configurazione dei budget di interruzione dei pod, la configurazione dell'aumento del nodo e la pianificazione corretta.

• Le strategie di aggiornamento blu-verde non influiscono sulle prestazioni del cluster, ma aumentano i costi e la complessità.

• Indipendentemente dalla strategia di aggiornamento e applicazione di patch, è necessario disporre di un processo di test e convalida affidabile per il cluster. Applicare prima patch e aggiornare gli ambienti inferiori ed eseguire una convalida post-manutenzione per controllare l'integrità del cluster, del nodo, della distribuzione e dell'applicazione.

Procedure consigliate per i carichi di lavoro del servizio Azure Kubernetes

Per assicurarsi che il cluster del servizio Azure Kubernetes funzioni senza problemi durante la manutenzione, seguire queste procedure consigliate:

• Definire i budget di interruzione dei pod (PDB). La configurazione dei PBD per le distribuzioni è essenziale. I PDB applicano un numero minimo di repliche dell'applicazione disponibili per garantire funzionalità continue durante gli eventi di interruzione. I PDB consentono di mantenere la stabilità del cluster durante gli errori di manutenzione o di nodo.

  Avviso

  I PDB configurati in modo errato possono bloccare il processo di aggiornamento perché l'API Kubernetes impedisce il blocco e lo svuotamento necessari che si verifica con un aggiornamento in sequenza dell'immagine del nodo. Inoltre, se troppi pod vengono spostati contemporaneamente, può verificarsi un'interruzione dell'applicazione. La configurazione PDB corretta riduce questo rischio.

• Controllare i limiti di calcolo e di rete disponibili. Verificare i limiti di calcolo e di rete disponibili nella sottoscrizione di Azure tramite la pagina quota nel portale di Azure o usando il comando az quota. Controlla le risorse di calcolo e di rete, in particolare le vCPU delle macchine virtuali (VM) per i nodi, e il numero di macchine virtuali e dei set di scalabilità delle macchine virtuali. Se si è vicini a un limite, richiedere un aumento della quota prima di eseguire l'aggiornamento.

• Controllare lo spazio degli indirizzi IP disponibili nelle subnet del nodo. Durante gli aggiornamenti, vengono creati nodi di picco aggiuntivi nel cluster e i pod vengono spostati in questi nodi. È importante monitorare lo spazio degli indirizzi IP nelle subnet del nodo per assicurarsi che sia disponibile spazio indirizzi sufficiente per queste modifiche. Diverse configurazioni di rete Kubernetes hanno requisiti di indirizzo IP diversi. Per iniziare, esaminare queste considerazioni:

  • Durante un aggiornamento, il numero di indirizzi IP del nodo aumenta in base al valore di picco. Il valore minimo di picco è 1.
  • I cluster basati sull'interfaccia di rete di Azure Container assegnano indirizzi IP a singoli pod, quindi è necessario disporre di spazio di indirizzi sufficiente per lo spostamento dei pod.
  • Il cluster continua a funzionare durante gli aggiornamenti. Assicurarsi che lo spazio degli indirizzi IP sia sufficiente per consentire il ridimensionamento dei nodi.

• Configurare più ambienti. Configurare più ambienti Kubernetes, ad esempio ambienti di sviluppo, gestione temporanea e produzione. Questa separazione consente di testare e convalidare completamente le modifiche prima di spostarle nell'ambiente di produzione. La convalida è particolarmente importante quando si passa da più versioni del servizio Azure Kubernetes, ad esempio dalla versione 1.28 alla 1.31.

• Pianificare e programmare le finestre di manutenzione. I processi di aggiornamento possono influire sulle prestazioni complessive del cluster Kubernetes. Pianificare i processi di aggiornamento sul posto al di fuori delle finestre di utilizzo di picco e monitorare le prestazioni del cluster per garantire un ridimensionamento adeguato, in particolare durante i processi di aggiornamento.

• Ottimizzare i cluster per il comportamento del nodo non drenabile. Per impostazione predefinita, se un nodo non riesce ad eseguire il draining correttamente, di conseguenza anche l'applicazione di patch al cluster non riesce. Per risolvere questo problema, è necessario configurare il blocco di svuotamento dei nodi. Questo processo mette in quarantena i nodi non consentiti e consente al cluster di eseguire correttamente l'aggiornamento. È quindi possibile correggere manualmente i nodi che non sono stati aggiornati applicando patch o eliminandoli.

• Ottimizzare i valori di aggiornamento con picchi. Per impostazione predefinita, il servizio Azure Kubernetes ha un valore di picco pari a 1, il che significa che un nodo aggiuntivo viene creato alla volta come parte del processo di aggiornamento. È possibile aumentare la velocità di un aggiornamento del servizio Azure Kubernetes aumentando questo valore. Il valore massimo consigliato per i carichi di lavoro sensibili alle interruzioni è 33%. Per altre informazioni, vedere Personalizzare l'aggiornamento della sovratensione del numero di nodi.

• Ottimizzare il timeout di svuotamento dei nodi.Il timeout di svuotamento dei nodi specifica il tempo massimo di attesa di un cluster mentre un carico di lavoro tenta di riprogrammare i pod su un nodo in fase di aggiornamento. Il valore predefinito è 30 minuti. Per i carichi di lavoro che faticano a riprogrammare i pod, l'aumento di questo valore può essere utile.

• Regolare il tempo di attesa di soak del nodo. Per impostazione predefinita, la configurazione di soak del nodo procede alla reimaging del nodo successivo dopo che un nodo ha completato il processo di aggiornamento. Per determinati carichi di lavoro legacy o sensibili, può essere utile aggiungere un ritardo prima di passare al nodo successivo. Aggiungere un ritardo configurando un timeout di immersione del nodo.

• Controllare altre dipendenze nel cluster. Gli operatori Kubernetes spesso distribuiscono altri strumenti nel cluster Kubernetes come parte delle operazioni, ad esempio scalatori KEDA, DAPR e reti di servizi. Quando si pianificano i processi di aggiornamento, controllare le note sulla versione per tutti i componenti usati per garantire la compatibilità con la versione di destinazione.

• Ottimizzare le configurazioni zonali di AKS. Per i cluster AKS zonali, l'aggiornamento con surge potrebbe comportare temporaneamente una distribuzione sbilanciata dei carichi di lavoro tra le zone. Per evitare questo scenario, impostare il valore di surge su un multiplo di tre, ad esempio 33% surge.

Gestire gli aggiornamenti settimanali per le immagini dei nodi

Microsoft crea una nuova immagine del nodo per i nodi del servizio Azure Kubernetes circa una volta alla settimana. Un'immagine del nodo contiene patch di sicurezza del sistema operativo aggiornate, aggiornamenti del kernel del sistema operativo, aggiornamenti della sicurezza di Kubernetes, versioni aggiornate di file binari come kubelet e aggiornamenti delle versioni dei componenti elencati nelle note sulla versione.

Quando un'immagine del nodo viene aggiornata, nei nodi del pool di nodi di destinazione viene attivata un'azione di blocco e svuotamento :

1. Un nodo con l'immagine aggiornata viene aggiunto al pool di nodi. Il valore di aumento determina il numero di nodi aggiunti contemporaneamente.
2. A seconda del valore di picco, un batch di nodi esistenti viene bloccato e svuotato. Il blocco garantisce che il nodo non pianifica i pod. Lo svuotamento rimuove i pod e li pianifica in altri nodi.
3. Una volta che questi nodi sono completamente svuotati, vengono rimossi dal pool di nodi. I nodi aggiornati aggiunti dal picco li sostituiscono.
4. Questo processo viene ripetuto per ogni batch di nodi rimanente che deve essere aggiornato nel pool di nodi.

Un processo simile si verifica durante un aggiornamento del cluster.

Aggiornamento automatico delle immagini di nodo

In genere, la maggior parte dei cluster deve usare il NodeImage canale di aggiornamento. Questo canale fornisce un disco rigido virtuale (VHD) dell'immagine del nodo aggiornato su base settimanale e viene aggiornato in base alla finestra di manutenzione del cluster.

I canali disponibili sono:

• None. Nessun aggiornamento viene avviato automaticamente.

• Unmanaged. Il sistema operativo applica gli aggiornamenti di Ubuntu e Linux di Azure su base notturna. I riavvii devono essere gestiti separatamente. AKS non può testare o controllare il ritmo di questi aggiornamenti.

• SecurityPatch. Il sistema operativo distribuisce le patch di sicurezza testate dal servizio Azure Kubernetes, sono completamente gestite e usano procedure di distribuzione sicure. Questa patch non contiene correzioni di bug del sistema operativo. Contiene solo gli aggiornamenti della sicurezza.

• NodeImage. AKS aggiorna settimanalmente i nodi con un nuovo VHD aggiornato che contiene correzioni di sicurezza e bug. Questi aggiornamenti vengono testati e distribuiti completamente usando procedure di distribuzione sicure. Per informazioni in tempo reale sulle immagini dei nodi attualmente distribuite, vedere Aggiornamenti delle immagini dei nodi del servizio Azure Kubernetes.

Per comprendere le cadenze predefinite senza una finestra di manutenzione stabilita, vedere Proprietà e pianificazione degli aggiornamenti.

Se si sceglie il canale di Unmanaged aggiornamento, è necessario gestire il processo di riavvio utilizzando uno strumento come kured. Il Unmanaged canale non include procedure di distribuzione sicura fornite da AKS e non funziona durante le finestre di manutenzione.

Se si sceglie il SecurityPatch canale di aggiornamento, è possibile applicare gli aggiornamenti con la frequenza settimanale. Questo livello di patch richiede che i dischi rigidi virtuali vengano archiviati nel gruppo di risorse, che comportano un addebito nominale. Per controllare quando SecurityPatch viene applicato, imposta una frequenza che meglio si adatta al tuo carico di lavoro. Se sono necessarie anche correzioni di bug che in genere vengono fornite con nuove immagini del nodo (VHD), è necessario scegliere il NodeImage canale anziché SecurityPatch.

Per altre informazioni, vedere Usare la manutenzione pianificata per pianificare e controllare gli aggiornamenti per il cluster del servizio Azure Kubernetes.

Come procedura consigliata, usare il NodeImage canale di aggiornamento e configurare una aksManagedNodeOSUpgradeSchedule finestra di manutenzione per un'ora in cui il cluster non rientra nelle finestre di utilizzo di picco. Per gli attributi che è possibile usare per configurare la finestra di manutenzione del cluster, vedere Creare una finestra di manutenzione. Gli attributi chiave sono:

• name. Usare aksManagedNodeOSUpgradeSchedule per gli aggiornamenti del sistema operativo del nodo.

• utcOffset. Configurare il fuso orario.

• startTime. Impostare l'ora di inizio della finestra di manutenzione.

• dayofWeek. Impostare i giorni della settimana per la finestra. Ad esempio: Saturday.

• schedule. Impostare la frequenza della finestra. Per NodeImage gli aggiornamenti, è consigliabile weekly.

• durationHours. Impostare questo attributo su almeno quattro ore.

L'esempio seguente imposta una finestra di manutenzione settimanale su 18:00 Ora orientale sabato:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Questa configurazione è idealmente distribuita come parte della distribuzione dell'infrastruttura come codice del cluster.

Per altri esempi, vedere Aggiungere una configurazione della finestra di manutenzione.

È possibile verificare la presenza di finestre di manutenzione configurate usando l'interfaccia della riga di comando di Azure:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

È anche possibile controllare i dettagli di una finestra di manutenzione specifica usando l'interfaccia della riga di comando:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Se non è configurata una finestra di manutenzione del cluster, gli aggiornamenti dell'immagine del nodo vengono eseguiti biweekly. La manutenzione di AKS viene eseguita il più possibile all'interno della finestra configurata, ma l'orario di manutenzione non è garantito.

Per monitorare automaticamente lo stato degli aggiornamenti, puoi usare il gestore delle comunicazioni di AKS per fornire avvisi automatici per le attività di manutenzione pianificate. In alternativa, è possibile monitorare direttamente tramite i log attività di Monitoraggio di Azure o esaminando i log delle risorse nel cluster tramite kubectl get events.

Abbonati agli eventi di Azure Kubernetes Service (AKS) con Azure Event Grid per ricevere gli eventi di aggiornamento di AKS. Questi eventi possono avvisare quando è disponibile una nuova versione di Kubernetes e consentono di tenere traccia delle modifiche dello stato del nodo durante i processi di aggiornamento.

È anche possibile gestire il processo di aggiornamento settimanale usando GitHub Actions. Questo metodo fornisce un controllo più granulare del processo di aggiornamento.

Processo di aggiornamento manuale dei nodi

È possibile usare il comando kubectl describe nodes per determinare la versione del kernel del sistema operativo e la versione dell'immagine del sistema operativo dei nodi nel cluster:

kubectl describe nodes <NodeName>

Output di esempio (troncato):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.173.1-1.cm2
  OS Image:                   CBL-Mariner/Linux
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.6.26
  Kubelet Version:            v1.31.3
  Kube-Proxy Version:         v1.31.3

Usare il comando az aks nodepool list dell'interfaccia della riga di comando di Azure per determinare le versioni dell'immagine del nodo dei nodi in un cluster:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Output di esempio:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Usare il comando az aks nodepool get-upgrades per determinare la versione più recente dell'immagine del nodo disponibile per un pool di nodi specifico:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Output di esempio:

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V2gen2-202501.12.0
user    AKSAzureLinux-V2gen2arm64-202501.12.0

Aggiornamenti del cluster

La community di Kubernetes rilascia le versioni secondarie di Kubernetes all'incirca ogni tre mesi. Per mantenere aggiornati regolarmente le nuove versioni e le versioni del servizio Azure Kubernetes, la pagina delle note sulla versione del servizio Azure Kubernetes viene aggiornata regolarmente. È anche possibile sottoscrivere il feed RSS del servizio Azure Kubernetes di GitHub, che fornisce aggiornamenti in tempo reale sulle modifiche e sui miglioramenti.

AKS segue un criterio di supporto N - 2, il che significa che viene fornito il supporto completo per la versione più recente (N) e le due versioni minori precedenti. È disponibile un supporto limitato per la piattaforma per la terza versione secondaria precedente. Per ulteriori informazioni, vedere Criteri di supporto per AKS.

Per assicurarsi che i cluster del servizio Azure Kubernetes rimangano supportati, è necessario stabilire un processo di aggiornamento continuo del cluster. Questo processo prevede il test di nuove versioni in ambienti inferiori e la pianificazione dell'aggiornamento all'ambiente di produzione prima che la nuova versione diventi l'impostazione predefinita. Questo approccio consente di mantenere la prevedibilità nel processo di aggiornamento e ridurre al minimo le interruzioni delle applicazioni. Per altre informazioni, vedere Opzioni di aggiornamento per i cluster del servizio Azure Kubernetes.

Se il cluster richiede un ciclo di aggiornamento più lungo, usare le versioni del servizio Azure Kubernetes che supportano l'opzione LTS (Long Term Support). Se si abilita l'opzione LTS, Microsoft fornisce il supporto esteso per le versioni di Kubernetes per due anni, che consente un ciclo di aggiornamento più prolungato e controllato. Per altre informazioni, vedere Versioni Kubernetes supportate nel servizio Azure Kubernetes.

Un aggiornamento del cluster include un aggiornamento del nodo e usa un processo di blocco e svuotamento.

Prima di aggiornare

Come procedura consigliata, è consigliabile eseguire sempre l'aggiornamento e il test in ambienti inferiori per ridurre al minimo il rischio di interruzioni nell'ambiente di produzione. Gli aggiornamenti del cluster richiedono test aggiuntivi perché comportano modifiche all'API, che possono influire sulle distribuzioni di Kubernetes. Le risorse seguenti possono essere utili per il processo di aggiornamento.

• Cartella di lavoro AKS per le API deprecate: Nella pagina di panoramica del cluster nel portale di Azure, selezionare Diagnostica e risoluzione dei problemi, passare alla sezione Crea, Aggiorna, Elimina e Ridimensiona, quindi selezionare Deprecazioni API Kubernetes. Questa procedura esegue una cartella di lavoro che verifica la presenza di versioni API deprecate che il cluster usa ancora. Per altre informazioni, vedere Rimuovere l'utilizzo delle API deprecate.

• Pagina delle note di rilascio di AKS: Questa pagina fornisce informazioni complete sulle nuove versioni e rilasci di AKS. Esaminare queste note per rimanere informati sugli aggiornamenti e sulle modifiche più recenti.

• Pagina delle note sulla versione di Kubernetes: Questa pagina fornisce informazioni dettagliate sulle versioni più recenti di Kubernetes. Prestare particolare attenzione alle note di aggiornamento urgente. Evidenziano informazioni critiche che potrebbero influire sul cluster AKS.

• Modifiche di rilievo nei componenti di AKS, suddivise per versione: Questa tabella offre una panoramica completa delle modifiche di rilievo nei componenti di AKS, in base alla versione. Facendo riferimento a questa guida, è possibile risolvere in modo proattivo eventuali potenziali problemi di compatibilità prima del processo di aggiornamento.

Oltre a queste risorse Microsoft, è consigliabile usare strumenti open source per ottimizzare il processo di aggiornamento del cluster. Uno di questi strumenti è Fairwinds pluto, che può analizzare le distribuzioni e i grafici Helm per le API Kubernetes deprecate. Questi strumenti consentono di garantire che le applicazioni rimangano compatibili con le versioni più recenti di Kubernetes.

Processo di aggiornamento

Per verificare quando il cluster richiede un aggiornamento, usare il comando az aks get-upgrades per ottenere un elenco delle versioni di aggiornamento disponibili per il cluster del servizio Azure Kubernetes. Determinare la versione di destinazione per il cluster dai risultati.

Ecco un esempio:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Output di esempio:

MasterVersion  Upgrades
-------------  ---------------------------------
1.30.7         1.31.1, 1.31.2, 1.31.3

Controllare le versioni di Kubernetes dei nodi nei pool di nodi per trovare i pool da aggiornare:

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

Output di esempio:

Name          K8version
------------  ------------
systempool    1.30.7
usernodepool  1.30.7

Aggiornamenti manuali

Per ridurre al minimo le interruzioni e garantire un aggiornamento uniforme per il cluster del servizio Azure Kubernetes, adottare questo approccio di aggiornamento:

1. Aggiornare il piano di controllo del servizio Azure Kubernetes. Aggiornare i componenti del piano di controllo responsabili della gestione e dell'orchestrazione del cluster. Aggiornare prima di tutto il piano di controllo per garantire la compatibilità e la stabilità prima di aggiornare i singoli pool di nodi.

2. Aggiornare il pool di nodi di sistema. Dopo aver aggiornato il piano di controllo, aggiornare il pool di nodi di sistema nel cluster del servizio Azure Kubernetes. I pool di nodi sono costituiti dalle istanze di macchina virtuale che eseguono i carichi di lavoro dell'applicazione. L'aggiornamento dei pool di nodi consente separatamente un aggiornamento controllato e sistematico dell'infrastruttura sottostante che supporta le applicazioni.

3. Aggiornare i pool di nodi utente. Dopo aver aggiornato il pool di nodi di sistema, aggiornare i pool di nodi utente nel cluster del servizio Azure Kubernetes.

Seguendo questo approccio, è possibile ridurre al minimo le interruzioni durante il processo di aggiornamento e mantenere la disponibilità delle applicazioni. Seguire questa procedura:

1. Eseguire il comando az aks upgrade con il flag per aggiornare solo il --control-plane-only piano di controllo del cluster e non i pool di nodi del cluster:

   az aks upgrade \
      --resource-group <ResourceGroupName> --name <AKSClusterName> \
      --control-plane-only \
      --kubernetes-version <KubernetesVersion>
   

2. Eseguire il comando az aks nodepool upgrade per aggiornare i pool di nodi alla versione di destinazione:

   az aks nodepool upgrade \
      --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
      --no-wait --kubernetes-version <KubernetesVersion>
   

   Durante l'aggiornamento del pool di nodi, il servizio Azure Kubernetes crea un nodo di picco, delimita e svuota i pod nel nodo che viene aggiornato, ricrea l'immagine del nodo e quindi rimuove i pod. Questo processo viene ripetuto per gli altri nodi nel pool di nodi.

È possibile controllare lo stato del processo di aggiornamento eseguendolo kubectl get events. Per informazioni sulla risoluzione dei problemi di aggiornamento del cluster, vedere la documentazione sulla risoluzione dei problemi del servizio Azure Kubernetes.

Iscrivere i cluster nei canali di rilascio per aggiornamenti automatici

AKS offre anche una soluzione di aggiornamento automatico del cluster per mantenere il cluster aggiornato. Se si usa questa soluzione, è consigliabile associarla a una finestra di manutenzione per controllare la tempistica degli aggiornamenti. La finestra di aggiornamento deve essere di quattro ore o più. Quando si registra un cluster in un canale di versione, Microsoft gestisce automaticamente la frequenza di aggiornamento e versione per il cluster e i relativi pool di nodi.

L'aggiornamento automatico del cluster offre diverse opzioni del canale di rilascio. Ecco una configurazione del canale di rilascio e dell'ambiente consigliata:

Considerazioni

La tabella seguente descrive le caratteristiche dei vari scenari di aggiornamento e applicazione di patch del servizio Azure Kubernetes.

• Una patch di sicurezza del sistema operativo applicata come parte di un aggiornamento dell'immagine del nodo potrebbe installare una versione successiva del kernel rispetto alla creazione di un nuovo cluster.

• La scalabilità orizzontale del pool di nodi usa il modello attualmente associato al set di scalabilità di macchine virtuali. I kernel del sistema operativo vengono aggiornati quando vengono applicate le patch di sicurezza e i nodi vengono riavviati.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Anthony Nevico | Principal Cloud Solution Architect

Altri contributori:

• Rishabh Saha | Architetto principale delle soluzioni
• Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
• Ali Yousefi | Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Documentazione del prodotto AKS
• Tracker versione AKS
• Roadmap AKS
• Acceleratore della zona di destinazione
• Risolvere i problemi di AKS
• Ottimizzare gli aggiornamenti di AKS
• Domande frequenti su aggiornamento del sistema operativo del nodo
• Set di costruzione del servizio Azure Kubernetes
• Automazione della baseline del servizio Azure Kubernetes
• Definizione delle operazioni di giorno 2
• Guida pratica per i cluster AKS a zone ridondanti

Risorse correlate

• Guida alle operazioni del secondo giorno servizio Azure Kubernetes
• Procedure di valutazione AKS