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, ognuno dei quali si basa sul successivo:

Tipi 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 dei nodi. Il servizio Azure Kubernetes 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 altre informazioni, vedere Stato della versione del servizio Azure Kubernetes.

• Versioni trimestrali di Kubernetes. Il servizio Azure Kubernetes fornisce aggiornamenti trimestrali per le versioni di Kubernetes. Questi aggiornamenti consentono agli utenti del servizio Azure Kubernetes di sfruttare le funzionalità e i miglioramenti più recenti di Kubernetes. Includono patch di sicurezza e aggiornamenti delle immagini del nodo. Per altre informazioni, vedere Versioni di Kubernetes supportate nel servizio Azure Kubernetes.

Considerazioni preliminari sull'aggiornamento

Impatto complessivo del cluster

• Gli aggiornamenti sul posto (sia node che 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.
• L'uso di una strategia di aggiornamento blu/verde anziché l'aggiornamento sul posto elimina qualsiasi impatto sulle prestazioni del cluster, ma aumenta 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 il carico di lavoro del servizio Azure Kubernetes

Per garantire il corretto funzionamento del cluster del servizio Azure Kubernetes durante la manutenzione, seguire queste procedure consigliate:

• Definire i budget di interruzione dei pod (PDB). La configurazione dei budget di interruzione dei pod 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 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. Controllare le risorse di calcolo e di rete, in particolare le vm vCPU per i nodi e il numero di macchine virtuali e set di scalabilità di macchine virtuali. Se si è vicini a un limite, richiedere un aumento della quota prima di eseguire l'aggiornamento.
• Controllare lo spazio IP disponibile 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 IP diversi. Come punto di partenza, esaminare queste considerazioni:
  • Durante un aggiornamento, il numero di indirizzi IP del nodo aumenta in base al valore di picco. Il valore minimo dell'aumento è 1.
  • I cluster basati su Azure CNI assegnano indirizzi IP a singoli pod, quindi è necessario disporre di spazio IP sufficiente per lo spostamento dei pod.
  • Il cluster continua a funzionare durante gli aggiornamenti. Assicurarsi che sia disponibile spazio IP sufficiente per consentire il ridimensionamento dei nodi (se è abilitato).
• Configurare più ambienti. È consigliabile configurare ambienti separati, ad esempio sviluppo, gestione temporanea e produzione, per consentire di testare e convalidare le modifiche prima di implementarle nell'ambiente di produzione.
• 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. L'aumento del 33% è il valore massimo consigliato per i carichi di lavoro sensibili alle interruzioni. Per altre informazioni, vedere Personalizzare l'aggiornamento della sovratensione del numero di nodi.
• Ottimizzare il timeout di svuotamento dei nodi. Il timeout di svuotamento del nodo specifica il tempo massimo di attesa di un cluster durante il tentativo di riprogrammare i pod in un nodo che sta aggiornando. Il valore predefinito per questo valore è 30 minuti. Per i carichi di lavoro che faticano a riprogrammare i pod, può essere utile modificare questo valore predefinito.
• Pianificare e pianificare 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.
• Controllare altre dipendenze nel cluster. Gli operatori Kubernetes spesso distribuiscono altri strumenti nel cluster Kubernetes come parte delle operazioni, ad esempio scaler KEDA, Dapr e mesh di servizi. Quando si pianificano i processi di aggiornamento, controllare le note sulla versione per tutti i componenti in uso per garantire la compatibilità con la versione di destinazione.

Gestione degli aggiornamenti settimanali alle 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 :

• Un nodo con l'immagine aggiornata viene aggiunto al pool di nodi. Il numero di nodi aggiunti contemporaneamente è regolato dal valore di aumento.
• 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.
• Dopo che questi nodi sono completamente svuotati, vengono rimossi dal pool di nodi. I nodi aggiornati aggiunti dal picco li sostituiscono.
• 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.

Aggiornamenti automatici delle immagini dei nodi

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

I canali disponibili includono quanto segue:

• None. Non vengono applicati automaticamente aggiornamenti.
• Unmanaged. Gli aggiornamenti di Ubuntu e Linux di Azure vengono applicati dal sistema operativo ogni notte. I riavvii devono essere gestiti separatamente. Il servizio Azure Kubernetes non è in grado di testare questo né controllare la frequenza di questa operazione.
• SecurityPatch. Patch di sicurezza del sistema operativo testate dal servizio Azure Kubernetes, completamente gestite e applicate con procedure di distribuzione sicure. Non contiene correzioni di bug del sistema operativo solo per gli aggiornamenti della sicurezza.
• NodeImage. Il servizio Azure Kubernetes aggiorna i nodi con un nuovo disco rigido virtuale con patch contenente correzioni di sicurezza e correzioni di bug a frequenza settimanale. Questa operazione è completamente testata e distribuita con procedure di distribuzione sicure. Per informazioni in tempo reale sulle immagini dei nodi attualmente distribuite, vedere la sezione [Immagini del nodo del servizio Azure Kubernetes][release-tracker].

Per comprendere le cadenza predefinite senza una finestra di manutenzione stabilita, fare riferimento all'aggiornamento della proprietà e della cadenza.

Se si sceglie il Unmanaged canale di aggiornamento, è necessario gestire il processo di riavvio usando uno strumento come kured. Unmanaged non include procedure di distribuzione sicure fornite dal servizio Azure Kubernetes e non funzionerà nelle finestre di manutenzione. Se si sceglie il SecurityPatch canale di aggiornamento, gli aggiornamenti possono essere applicati ogni settimana. Questo livello di patch richiede che i dischi rigidi virtuali vengano archiviati nel gruppo di risorse, che comportano un addebito nominale. Controllare quando l'oggetto SecurityPatch viene applicato impostando un oggetto appropriato aksManagedNodeOSUpgradeSchedule che sia allineato a una frequenza ottimale per il carico di lavoro. Per altre informazioni, vedere Creazione di una finestra di manutenzione. 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.

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. Vedere Creazione di una finestra di manutenzione per gli attributi che è possibile usare per configurare la finestra di manutenzione del cluster. 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.

In questo esempio viene impostata una finestra di manutenzione settimanale su 8: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

Per altri esempi, vedere Aggiungere una configurazione della finestra di manutenzione con l'interfaccia della riga di comando di Azure.

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

È 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. Il più possibile, la manutenzione del servizio Azure Kubernetes viene eseguita all'interno della finestra configurata, ma il tempo di manutenzione non è garantito.

È possibile controllare lo stato degli eventi di aggiornamento tramite i log attività di Azure o esaminando i log delle risorse nel cluster.

È possibile sottoscrivere eventi servizio Azure Kubernetes (servizio Azure Kubernetes) con Griglia di eventi di Azure che include eventi di aggiornamento del servizio Azure Kubernetes. 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.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

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 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:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Aggiornamenti del cluster

La community di Kubernetes rilascia versioni secondarie di Kubernetes ogni tre mesi circa. 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.

Il servizio Azure Kubernetes segue un criterio di supporto N - 2 , il che significa che viene fornito il supporto completo per la versione più recente (N) e due versioni secondarie precedenti. È disponibile un supporto limitato per la piattaforma per la terza versione secondaria precedente. Per altre informazioni, vedere Criteri di supporto del servizio Azure Kubernetes.

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 può mantenere la prevedibilità nel processo di aggiornamento e ridurre al minimo le interruzioni delle applicazioni. Per altre informazioni, vedere Aggiornare un 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 di Kubernetes supportate nel servizio Azure Kubernetes.

Un aggiornamento del cluster include un aggiornamento del nodo e usa un processo simile 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 del servizio Azure Kubernetes per le API deprecate. Nella pagina di panoramica del cluster nella portale di Azure è possibile selezionare Diagnostica e risoluzione dei problemi, passare alla categoria Crea, Aggiorna, Elimina e Ridimensiona e quindi selezionare Deprecations dell'API Kubernetes. In questo modo viene eseguita una cartella di lavoro che verifica la presenza di versioni API deprecate usate nel cluster. Per altre informazioni, vedere Rimuovere l'utilizzo delle API deprecate.
• Pagina note sulla versione del servizio Azure Kubernetes. Questa pagina fornisce informazioni complete sulle nuove versioni e versioni del servizio Azure Kubernetes. 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, che evidenziano informazioni critiche che potrebbero influire sul cluster del servizio Azure Kubernetes.
• Componenti del servizio Azure Kubernetes che causano un'interruzione delle modifiche in base alla versione. Questa tabella offre una panoramica completa delle modifiche di rilievo nei componenti del servizio Azure Kubernetes, 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 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.26.6         1.27.1, 1.27.3

Controllare le versioni di Kubernetes dei nodi nei pool di nodi per determinare 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.26.6
usernodepool  1.26.6

Aggiornamento manuale

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

1. Aggiornare il piano di controllo del servizio Azure Kubernetes. Per iniziare, aggiornare il piano di controllo del servizio Azure Kubernetes. Questo passaggio comporta l'aggiornamento dei componenti del piano di controllo responsabili della gestione e dell'orchestrazione del cluster. L'aggiornamento del piano di controllo consente prima di 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 della 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. Questi sono i passaggi dettagliati:

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 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 quindi ripetuto per tutti gli altri nodi nel pool di nodi.

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

Registrare i cluster nei canali di versione di aggiornamento automatico

Il servizio Azure Kubernetes offre anche una soluzione di aggiornamento automatico del cluster per mantenere aggiornato il cluster. 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

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Anthony Nevico | Principal Cloud Solution Architect

Altri contributori:

• Rishabh Saha | Principal Solution Architect
• 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 servizio Azure Kubernetes
• Strumento di rilevamento delle versioni del servizio Azure Kubernetes
• Roadmap del servizio Azure Kubernetes
• Acceleratore di zona di destinazione del servizio Azure Kubernetes
• Risolvere i problemi del servizio Azure Kubernetes
• Ottimizzazione degli aggiornamenti del servizio Azure Kubernetes
• 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 del giorno 2

Risorse correlate

• Guida operativa al giorno 2 del servizio Azure Kubernetes
• Procedure di valutazione del servizio Azure Kubernetes