Gestire nodi e pool di nodi Kubernetes

L'architettura kubernetes è costituita da due livelli: il piano di controllo e almeno un nodo in un pool di nodi. Questo articolo descrive e confronta il modo in cui Amazon Elastic Kubernetes Service (EKS) e il servizio Azure Kubernetes gestiscono nodi agente e nodi di lavoro.

Sia in Amazon EKS che nel servizio Azure Kubernetes, la piattaforma cloud fornisce e gestisce il livello del piano di controllo e il cliente gestisce il livello del nodo. Il diagramma seguente illustra la relazione tra il piano di controllo e i nodi nell'architettura kubernetes del servizio Azure Kubernetes.

Gruppi di nodi gestiti di Amazon EKS

I gruppi di nodi gestiti amazon EKS automatizzano il provisioning e la gestione del ciclo di vita dei nodi di lavoro Amazon Elastic Compute Cloud (EC2) per i cluster Amazon EKS. Gli utenti di Amazon Web Services (AWS) possono usare l'utilità della riga di comando eksctl per creare, aggiornare o terminare nodi per i cluster del servizio Azure Kubernetes. Gli aggiornamenti e le terminazioni dei nodi bloccano e svuotano automaticamente i nodi per garantire che le applicazioni rimangano disponibili.

Viene effettuato il provisioning di ogni nodo gestito come parte di un gruppo di scalabilità automatica Amazon EC2 gestito da Amazon EKS. Il ridimensionamento automatico del cluster Kubernetes regola automaticamente il numero di nodi di lavoro in un cluster quando i pod hanno esito negativo o vengono riprogrammati in altri nodi. È possibile configurare ogni gruppo di nodi per l'esecuzione in più zone di disponibilità all'interno di un'area.

Per altre informazioni, vedere Creare un gruppo di nodi gestiti e Aggiornare un gruppo di nodi gestiti.

È anche possibile eseguire pod Kubernetes in AWS Fargate. Fargate offre capacità di calcolo su richiesta e di dimensioni corrette per i contenitori. Per altre informazioni, vedere Semplificare la gestione delle risorse di calcolo.

Karpenter

Karpenter è un progetto open source che consente di migliorare la gestione del ciclo di vita dei nodi all'interno dei cluster Kubernetes. Automatizza il provisioning e il deprovisioning dei nodi in base alle specifiche esigenze di pianificazione dei pod, migliorando così la scalabilità e l'ottimizzazione dei costi. Usare Karpenter per le funzioni principali seguenti:

• Monitorare i pod che l'utilità di pianificazione Kubernetes non è in grado di pianificare a causa di vincoli di risorse.

• Valutare i requisiti di pianificazione, ad esempio richieste di risorse, selettori di nodo, affinità e tolleranze, dei pod non pianificabili.

• Configurare nuovi nodi che soddisfano i requisiti dei pod non pianificabili.

• Rimuovere i nodi quando non sono più necessari.

È possibile usare Karpenter per definire pool di nodi con vincoli per il provisioning dei nodi, ad esempio taints, etichette, requisiti (tipi di istanza e zone) e limiti per le risorse con provisioning totale. Quando distribuisci i carichi di lavoro, specifica vari vincoli di pianificazione nella configurazione dei pod. Ad esempio, è possibile specificare richieste di risorse o limiti, selettori di nodo, affinità di nodo o pod, tolerazioni e vincoli di distribuzione della topologia. Karpenter configura quindi nodi di dimensioni corrette in base a queste specifiche.

Prima del lancio di Karpenter, gli utenti di Amazon EKS si affidavano principalmente ai gruppi di scalabilità automatica amazon EC2 e al ridimensionamento automatico del cluster Kubernetes per regolare dinamicamente la capacità di calcolo dei cluster. Non è necessario creare decine di gruppi di nodi per ottenere la flessibilità e la diversità offerta da Karpenter. A differenza del ridimensionamento automatico del cluster Kubernetes, Karpenter dipende meno dalle versioni di Kubernetes e non richiede transizioni tra LE API AWS e Kubernetes.

Karpenter consolida le responsabilità di orchestrazione delle istanze all'interno di un singolo sistema, che è più semplice, più stabile e più compatibile con il cluster. Karpenter aiuta a superare le sfide del ridimensionamento automatico del cluster offrendo modi semplificati per:

• Configurare i nodi in base ai requisiti del carico di lavoro.

• Creare configurazioni di nodi diverse in base al tipo di istanza usando opzioni del pool di nodi flessibili. Anziché gestire diversi gruppi di nodi personalizzati specifici, usare Karpenter per gestire capacità di carico di lavoro diverse usando un singolo pool di nodi flessibile.

• È possibile migliorare la pianificazione dei pod su larga scala avviando rapidamente i nodi e pianificando i pod.

Rispetto ai gruppi di scalabilità automatica e ai gruppi di nodi gestiti, Karpenter integra la gestione del ridimensionamento più strettamente con le API native di Kubernetes. I gruppi di scalabilità automatica e i gruppi di nodi gestiti sono astrazioni native di AWS che attivano il ridimensionamento in base alle metriche a livello di AWS, ad esempio il carico della CPU EC2. Anche se il ridimensionamento automatico del cluster collega le astrazioni Kubernetes alle astrazioni AWS, sacrifica una certa flessibilità, ad esempio la pianificazione per una zona di disponibilità specifica.

Karpenter semplifica la gestione dei nodi eliminando componenti specifici di AWS, che offre una maggiore flessibilità direttamente all'interno di Kubernetes. Utilizzare Karpenter per i cluster che eseguono carichi di lavoro che riscontrano periodi di elevata e punteggiata richiesta o hanno requisiti di calcolo variegati. Usare gruppi di nodi gestiti e gruppi di ridimensionamento automatico per i cluster che eseguono carichi di lavoro più statici e coerenti. A seconda dei requisiti, è possibile usare una combinazione di nodi gestiti in modo dinamico e statico.

Contenitori Kata

Kata Containers è un progetto open source che offre un runtime di contenitori altamente sicuro. Combina la natura leggera dei contenitori con i vantaggi di sicurezza delle macchine virtuali.It combine the lightweight nature of containers with the security benefits of virtual machines (VM). I contenitori Kata migliorano l'isolamento e la sicurezza del carico di lavoro avviando ogni contenitore con un sistema operativo guest diverso, a differenza dei contenitori tradizionali che condividono lo stesso kernel Linux tra i carichi di lavoro. I contenitori Kata eseguano contenitori in una macchina virtuale conforme a Open Container Initiative (OCI), che fornisce un isolamento rigoroso tra contenitori nello stesso computer host. I contenitori Kata offrono le funzionalità seguenti:

• Isolamento avanzato del carico di lavoro: Ogni contenitore viene eseguito nella propria macchina virtuale leggera per garantire l'isolamento a livello di hardware.

• Sicurezza migliorata: L'uso della tecnologia delle macchine virtuali offre un livello di sicurezza aggiuntivo, riducendo il rischio di interruzioni dei contenitori.

• Compatibilità con gli standard del settore: I contenitori Kata si integrano con strumenti standard del settore, ad esempio il formato del contenitore OCI e l'interfaccia di runtime del contenitore Kubernetes.

• Supporto per più architetture e hypervisor: I contenitori Kata supportano le architetture AMD64 e ARM ed è possibile usarla con hypervisor come Cloud Hypervisor e Firecracker.

• Distribuzione e gestione semplici: I contenitori Kata semplificano l'orchestrazione del carico di lavoro perché usa il sistema di orchestrazione Kubernetes.

Per configurare ed eseguire i contenitori Kata in AWS, configurare un cluster Amazon EKS per l'uso di Firecracker. Firecracker è una tecnologia di virtualizzazione open source di Amazon che consente di creare e gestire servizi sicuri basati su contenitori multi-tenant e basati su funzioni. Usare Firecracker per distribuire i carichi di lavoro in macchine virtuali leggere, denominate microVM, che offrono sicurezza e isolamento del carico di lavoro avanzati rispetto alle macchine virtuali tradizionali. I microVM migliorano anche la velocità e l'efficienza delle risorse dei contenitori. Seguire la procedura per eseguire Kata Containers in AWS EKS.

Host dedicati

Quando si usa Amazon EKS per distribuire ed eseguire contenitori, è possibile eseguire i contenitori in host dedicati Amazon EC2. Tuttavia, questa funzionalità è disponibile solo per i gruppi di nodi autogestito. È quindi necessario creare manualmente un modello di avvio e gruppi di ridimensionamento automatico. Registrare quindi gli host dedicati, il modello di avvio e i gruppi di ridimensionamento automatico con il cluster EKS. Per creare queste risorse, usare lo stesso metodo del ridimensionamento automatico EC2 generale.

Per altre informazioni su come usare AWS EKS per eseguire contenitori in host dedicati EC2, vedere le risorse seguenti:

• nodi Amazon EKS
• Restrizioni per l'host dedicato
• Assegnare host dedicati
• Acquistare prenotazioni host dedicate
• Posizionamento automatico

Nodi e pool di nodi AKS

Quando si crea automaticamente un cluster del servizio Azure Kubernetes, viene creato e configurato un piano di controllo che fornisce i servizi Kubernetes di base e l'orchestrazione del carico di lavoro dell'applicazione. La piattaforma Azure fornisce il piano di controllo AKS senza costi, come risorsa gestita di Azure. Il piano di controllo e le relative risorse esistono solo nell'area in cui si crea il cluster.

I nodi, detti anche nodi agente o nodi di lavoro, ospitano i carichi di lavoro e le applicazioni. Nel servizio Azure Kubernetes è possibile gestire e pagare completamente i nodi agente collegati al cluster del servizio Azure Kubernetes.

Per eseguire applicazioni e servizi di supporto, un cluster del servizio Azure Kubernetes richiede almeno un nodo, ovvero una macchina virtuale di Azure che esegue i componenti del nodo Kubernetes e il runtime del contenitore. Ogni cluster del servizio Azure Kubernetes deve contenere almeno un pool di nodi di sistema con almeno un nodo.

Il servizio Azure Kubernetes combina i nodi della stessa configurazione in pool di nodi di macchine virtuali che eseguono carichi di lavoro del servizio Azure Kubernetes. Usare i pool di nodi di sistema per ospitare pod di sistema critici, ad esempio CoreDNS. Usare i pool di nodi utente per ospitare i pod del carico di lavoro. Se si vuole un solo pool di nodi nel cluster del servizio Azure Kubernetes, ad esempio in un ambiente di sviluppo, è possibile pianificare i pod dell'applicazione nel pool di nodi di sistema.

È anche possibile creare più pool di nodi utente per separare carichi di lavoro diversi in nodi diversi. Questo approccio consente di evitare il problema adiacente rumoroso e supporta le applicazioni con esigenze di calcolo o archiviazione diverse.

Ogni nodo agente all'interno di un pool di nodi di sistema o utente è essenzialmente una macchina virtuale. I set di scalabilità di macchine virtuali di Azure configurano le macchine virtuali e il cluster del servizio Azure Kubernetes li gestisce. Per altre informazioni, vedere Pool di nodi.

È possibile definire il numero iniziale e le dimensioni per i nodi di lavoro quando si crea un cluster del servizio Azure Kubernetes o quando si aggiungono nuovi nodi e pool di nodi a un cluster del servizio Azure Kubernetes esistente. Se non si specificano dimensioni della macchina virtuale, le dimensioni predefinite sono Standard_D2s_v3 per i pool di nodi Windows e Standard_DS2_v2 per i pool di nodi Linux.

Creare un pool di nodi

Quando si crea un nuovo pool di nodi, il set di scalabilità di macchine virtuali associato viene creato nel gruppo di risorse del nodo. Questo gruppo di risorse di Azure contiene tutte le risorse dell'infrastruttura per il cluster del servizio Azure Kubernetes. Queste risorse includono i nodi Kubernetes, le risorse di rete virtuale, le identità gestite e l'archiviazione.

Per impostazione predefinita, il gruppo di risorse del nodo ha un nome come MC_<resourcegroupname>_<clustername>_<location>. Il servizio Azure Kubernetes elimina automaticamente il gruppo di risorse del nodo quando elimina un cluster. È consigliabile usare questo gruppo di risorse solo per le risorse che condividono il ciclo di vita del cluster.

Per altre informazioni, vedere Creare pool di nodi per un cluster nel servizio Azure Kubernetes.

Aggiungere un pool di nodi

Per aggiungere un pool di nodi a un cluster del servizio Azure Kubernetes nuovo o esistente, usare il portale di Azure, l'interfaccia della riga di comando di Azure o l'API REST del servizio Azure Kubernetes. È anche possibile usare l'infrastruttura come strumenti di codice (IaC), ad esempio Bicep, modelli di Azure Resource Manager o Terraform.

L'esempio di codice seguente usa il comando az aks nodepool add dell'interfaccia della riga di comando di Azure per aggiungere un pool di nodi denominato mynodepool con tre nodi. Aggiunge il pool di nodi a un cluster del myResourceGroup servizio Azure Kubernetes esistente denominato myAKSCluster nel gruppo di risorse.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Pool di nodi spot

Un pool di nodi spot è un pool di nodi supportato da un set di scalabilità di macchine virtuali spot . Usare le macchine virtuali spot per i nodi nel cluster del servizio Azure Kubernetes per sfruttare la capacità di Azure inutilizzata a un costo ridotto. La quantità di capacità inutilizzata disponibile varia in base a fattori, ad esempio dimensioni del nodo, area e ora del giorno.

Quando si distribuisce un pool di nodi spot, Azure alloca i nodi spot se la capacità è disponibile. Tuttavia, i nodi spot non hanno un contratto di servizio. Un set di scalabilità spot che supporta il pool di nodi spot viene distribuito in un singolo dominio di errore e non offre garanzie di disponibilità elevata. Quando Azure richiede la capacità, l'infrastruttura di Azure rimuove i nodi spot. Si riceve un avviso fino a 30 secondi prima della rimozione. Non è possibile usare un pool di nodi spot come pool di nodi predefinito del cluster. Utilizzare un pool di nodi spot solo come pool secondario.

Usare nodi spot per carichi di lavoro in grado di gestire interruzioni, terminazioni anticipate o espulsioni. Ad esempio, pianificare in un pool di nodi spot per processi di elaborazione batch, ambienti di sviluppo e test e carichi di lavoro di calcolo di grandi dimensioni. Per altre informazioni, vedere Limitazioni dell'istanza spot.

Il comando seguente az aks nodepool add aggiunge un pool di nodi spot a un cluster esistente con scalabilità automatica abilitata.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Per ulteriori informazioni, vedere Aggiungere un pool di nodi spot a un cluster del servizio Azure Kubernetes (AKS).

Dischi del sistema operativo temporanei

Per impostazione predefinita, Azure replica automaticamente il disco del sistema operativo della macchina virtuale in Archiviazione di Azure. Questo approccio impedisce la perdita di dati se la macchina virtuale deve essere trasferita in un altro host. Tuttavia, i contenitori non sono progettati per mantenere lo stato locale, quindi archiviare il disco del sistema operativo in Azure Storage offre vantaggi limitati per AKS (Azure Kubernetes Service). Questo approccio può causare un provisioning dei nodi più lento e una maggiore latenza di lettura e scrittura.

Al contrario, i dischi temporanei del sistema operativo vengono archiviati solo nel computer host, ad esempio un disco temporaneo. Offrono anche una latenza di lettura e scrittura inferiore e un ridimensionamento dei nodi e aggiornamenti del cluster più veloci. Come un disco temporaneo, il prezzo della macchina virtuale include un disco temporaneo del sistema operativo, quindi non si comportano costi di archiviazione aggiuntivi.

Per usare il sistema operativo temporaneo, il disco del sistema operativo deve rientrare nella cache della macchina virtuale. La documentazione della macchina virtuale di Azure mostra le dimensioni della cache delle macchine virtuali tra parentesi accanto alla velocità effettiva di input/output (I/O) come dimensioni della cache in gibibyte (GiB).

Ad esempio, la dimensione predefinita della macchina virtuale AKS Standard_DS2_v2 con disco del sistema operativo da 100 GB supporta un disco del sistema operativo effimero, ma ha solo una cache di 86 GB. Questa configurazione viene impostata per impostazione predefinita su managed disks se non si specifica in modo esplicito. Se si richiede in modo esplicito il sistema operativo temporaneo per questa dimensione, viene visualizzato un errore di convalida.

Se si richiede la stessa macchina virtuale Standard_DS2_v2 con un disco del sistema operativo da 60 GB, si ottiene il sistema operativo temporaneo per impostazione predefinita. Le dimensioni richieste del sistema operativo da 60 GB sono inferiori alle dimensioni massime della cache di 86 GB.

Standard_D8s_v3 con un disco del sistema operativo di 100 GB supporta un sistema operativo effimero e ha una cache di 200 GB. Se non si specifica il tipo di disco del sistema operativo, per impostazione predefinita un pool di nodi ottiene il sistema operativo temporaneo.

Il comando seguente az aks nodepool add illustra come aggiungere un nuovo pool di nodi a un cluster esistente con un disco temporaneo del sistema operativo. Il --node-osdisk-type parametro imposta il tipo di disco del sistema operativo su Ephemerale il --node-osdisk-size parametro definisce le dimensioni del disco del sistema operativo.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Per altre informazioni, vedere Disco del sistema operativo temporaneo.

Pool di nodi di Macchine Virtuali Azure in AKS (Azure Kubernetes Service)

Ogni gruppo di nodi gestiti nel servizio Azure Kubernetes è supportato da un gruppo di scalabilità automatica Amazon EC2 gestito da Amazon EKS. Questa integrazione consente al servizio Azure Kubernetes di configurare e ridimensionare automaticamente le istanze EC2 all'interno del gruppo di nodi.

È possibile configurare i gruppi di ridimensionamento automatico per supportare più tipi di istanza EC2, ma non è possibile specificare il numero di nodi da creare o ridimensionare per ogni tipo di istanza. Il servizio Azure Kubernetes gestisce invece il ridimensionamento del gruppo di nodi in base alla configurazione e ai criteri desiderati. Questo approccio semplifica e automatizza il processo di gestione per il gruppo di nodi in modo da poter scegliere i tipi di istanza EC2 in base ai requisiti del carico di lavoro. È anche possibile avviare nodi Amazon Linux autogestito usando lo eksctl strumento da riga di comando o AWS Management Console.

Per i pool di nodi di Macchine virtuali di Azure, il servizio Azure Kubernetes configura e avvia ogni nodo dell'agente. Per i pool di nodi dei set di scalabilità di macchine virtuali di Azure, il servizio Azure Kubernetes gestisce il modello di set di scalabilità di macchine virtuali e lo usa per ottenere coerenza tra tutti i nodi dell'agente nel pool di nodi. È possibile usare pool di nodi di macchine virtuali per orchestrare il cluster con macchine virtuali più adatte ai singoli carichi di lavoro. È anche possibile specificare il numero di nodi da creare o ridimensionare per ogni dimensione della macchina virtuale.

Un pool di nodi è costituito da un set di macchine virtuali con dimensioni diverse. Ogni macchina virtuale supporta un tipo di carico di lavoro diverso. Queste dimensioni delle macchine virtuali, denominate SKU, vengono classificate in famiglie diverse ottimizzate per scopi specifici. Per altre informazioni, vedere Dimensioni delle macchine virtuali in Azure.

Per abilitare il ridimensionamento di più dimensioni di VM, il tipo di pool di nodi di macchine virtuali utilizza un ScaleProfile. Questo profilo consente di configurare la scalabilità del pool di nodi specificando le dimensioni e il numero di macchine virtuali desiderati. È ManualScaleProfile un profilo di scalabilità che specifica le dimensioni e il conteggio della macchina virtuale desiderati. In un oggetto ManualScaleProfileè consentita una sola dimensione della macchina virtuale. È necessario creare un elemento separato ManualScaleProfile per ogni dimensione della macchina virtuale nel pool di nodi.

Quando si crea un nuovo pool di nodi di macchine virtuali, è necessario almeno un ManualScaleProfile nel ScaleProfile. È possibile creare più profili di scalabilità manuale per un singolo pool di nodi di macchine virtuali.

I vantaggi dei pool di nodi delle macchine virtuali includono:

• Flessibilità: È possibile aggiornare le specifiche dei nodi in base ai carichi di lavoro e alle esigenze.

• Controllo ottimizzato: I controlli a livello di nodo singolo consentono di specificare e combinare nodi di specifiche diverse per migliorare la coerenza.

• Efficienza: È possibile ridurre il footprint del nodo per il cluster per semplificare i requisiti operativi.

I pool di nodi delle macchine virtuali offrono un'esperienza migliore per carichi di lavoro dinamici e requisiti di disponibilità elevata. È possibile usarli per configurare più macchine virtuali della stessa famiglia in un pool di nodi e il carico di lavoro viene pianificato automaticamente sulle risorse disponibili configurate.

La tabella seguente confronta i pool di nodi delle macchine virtuali con i pool di nodi dei set di scalabilità di macchine virtuali standard.

I pool di nodi delle macchine virtuali presentano le limitazioni seguenti:

• La scalabilità automatica del cluster non è supportata.
• InfiniBand non è disponibile.
• I pool di nodi di Windows non sono supportati.
• Questa funzionalità non è disponibile nel portale di Azure. Usare l'interfaccia della riga di comando di Azure o le API REST per eseguire operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) o per gestire il pool.
• Lo snapshot del pool di nodi non è supportato.
• Tutte le dimensioni delle macchine virtuali in un pool di nodi devono appartenere alla stessa famiglia di macchine virtuali. Ad esempio, non è possibile combinare un tipo di macchina virtuale serie N con un tipo di macchina virtuale serie D nello stesso pool di nodi.
• I pool di nodi delle macchine virtuali consentono fino a cinque dimensioni di vm diverse per ogni pool di nodi.

Nodi virtuali

È possibile usare i nodi virtuali per aumentare rapidamente il numero di istanze dei carichi di lavoro dell'applicazione in un cluster del servizio Azure Kubernetes. I nodi virtuali forniscono il provisioning rapido dei pod e si paga solo al secondo per il runtime. Non serve aspettare che il ridimensionatore automatico del cluster distribuisca nuovi nodi di lavoro per eseguire più repliche del pod. Solo i pod e i nodi Linux supportano nodi virtuali. Il componente aggiuntivo dei nodi virtuali per AKS si basa sul progetto open-source Virtual Kubelet.

La funzionalità del nodo virtuale dipende da Istanze di Azure Container. Per ulteriori informazioni, vedere Creare e configurare un cluster AKS per utilizzare i nodi virtuali.

Taints, labels e tag

Quando si crea un pool di nodi, è possibile aggiungere segni e etichette Kubernetes e tag di Azure. Ogni taint, etichetta o tag si applica a tutti i nodi all'interno del pool di nodi.

Per creare un pool di nodi con un taint, puoi usare il comando az aks nodepool add con il parametro --node-taints. Per etichettare i nodi in un pool di nodi, usare il --labels parametro e specificare un elenco di etichette, come illustrato nel codice seguente:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Per altre informazioni, vedere Specificare un taint, un'etichetta o un tag per un pool di nodi.

Etichette di sistema riservate

Amazon EKS aggiunge etichette Kubernetes automatizzate a tutti i nodi di un gruppo di nodi gestiti, ad esempio eks.amazonaws.com/capacityType, che specifica il tipo di capacità. AKS aggiunge automaticamente anche etichette di sistema ai nodi dell'agente.

I prefissi seguenti sono riservati per l'uso del servizio Azure Kubernetes e non possono essere usati per i nodi:

• kubernetes.azure.com/
• kubernetes.io/

Per altri prefissi riservati, vedere etichette, annotazioni e taints ben noti di Kubernetes.

Nella tabella seguente sono elencate le etichette riservate per l'uso del servizio Azure Kubernetes e non possono essere usate per i nodi. Nella tabella la colonna Utilizzo nodo virtuale specifica se i nodi virtuali supportano l'etichetta.

Nella colonna Utilizzo nodo virtuale:

• N/D significa che la proprietà non si applica ai nodi virtuali perché richiede la modifica dell'host.
• Lo stesso significa che i valori previsti sono gli stessi per un pool di nodi virtuali e un pool di nodi standard.
• Virtuale sostituisce i valori SKU della macchina virtuale, perché i pod dei nodi virtuali non espongono le macchine virtuali sottostanti.
• La versione del nodo virtuale fa riferimento alla versione attuale della versione rilasciata del connettore virtuale Kubelet-ACI.
• Il nome della subnet del nodo virtuale è la subnet che distribuisce i pod dei nodi virtuali in Istanze di Contenitore.
• La rete virtuale del nodo virtuale è la rete virtuale che contiene la subnet del nodo virtuale.

Gruppi di nodi Windows

È possibile usare il servizio Azure Kubernetes per creare e usare pool di nodi del contenitore di Windows Server tramite il plug-in di rete dell'interfaccia di rete di Azure Container . Per pianificare gli intervalli di subnet e le considerazioni di rete necessari, vedere Configurare l'interfaccia di rete di Azure Container.

Il comando seguente az aks nodepool add aggiunge un pool di nodi che esegue contenitori di Windows Server:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Il comando precedente usa la subnet predefinita nella rete virtuale del cluster AKS. Per altre informazioni su come creare un cluster del servizio Azure Kubernetes con un pool di nodi Windows, vedere Creare un contenitore di Windows Server nel servizio Azure Kubernetes.

Considerazioni sul pool di nodi

Quando si creano e si gestiscono pool di nodi singoli o multipli, si applicano le considerazioni e le limitazioni seguenti:

• Le quote, le restrizioni relative alle dimensioni delle macchine virtuali e la disponibilità dell'area si applicano ai pool di nodi del servizio Azure Kubernetes.

• I pool di sistema devono contenere almeno un nodo. È possibile eliminare un pool di nodi di sistema se nel cluster AKS è presente un altro pool di nodi di sistema per sostituirlo. I pool di nodi utente possono contenere zero o più nodi.

• Non è possibile modificare le dimensioni della macchina virtuale di un pool di nodi dopo averlo creato.

• Per più pool di nodi, il cluster AKS deve usare bilanciatori di carico SKU Standard. Bilanciatori di carico SKU Basic non supportano pool multipli di nodi.

• Tutti i pool di nodi del cluster devono trovarsi nella stessa rete virtuale e tutte le subnet assegnate a un pool di nodi devono trovarsi nella stessa rete virtuale.

• Se si creano più pool di nodi quando si crea un cluster, le versioni di Kubernetes per tutti i pool di nodi devono corrispondere alla versione del piano di controllo. Per aggiornare le versioni dopo la configurazione del cluster, usare le operazioni per ogni pool di nodi.

Ridimensionare i pool di nodi

Quando il carico di lavoro dell'applicazione cambia, potrebbe essere necessario modificare il numero di nodi in un pool di nodi. Per ridimensionare manualmente il numero di nodi verso l'alto o verso il basso, usare il comando az aks nodepool scale . L'esempio seguente ridimensiona il numero di nodi in mynodepool cinque:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Ridimensionare automaticamente i pool di nodi

Il servizio Azure Kubernetes supporta automaticamente il ridimensionamento automatico dei pool di nodi usando il ridimensionamento automatico del cluster. Abilitare questa funzionalità in ogni pool di nodi e definire un numero minimo e massimo di nodi.

Il comando seguente az aks nodepool add aggiunge un nuovo pool di nodi denominato mynodepool a un cluster esistente. Il --enable-cluster-autoscaler parametro abilita il ridimensionamento automatico del cluster nel nuovo pool di nodi. I --min-count parametri e --max-count specificano il numero minimo e massimo di nodi nel pool.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Il comando az aks nodepool update seguente aggiorna il numero minimo di nodi da uno a tre per il pool di mynewnodepool nodi.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Per disabilitare il ridimensionamento automatico del cluster, usare il az aks nodepool update comando con il --disable-cluster-autoscaler parametro .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Per riabilitare il ridimensionamento automatico del cluster in un cluster esistente, usare il az aks nodepool update comando e specificare i --enable-cluster-autoscalerparametri , --min-counte --max-count .

Per altre informazioni su come usare il ridimensionamento automatico del cluster per singoli pool di nodi, vedere Usare il ridimensionamento automatico del cluster nel servizio Azure Kubernetes.

Sandboxing dei pod

Per configurare ed eseguire facilmente i contenitori Kata su AKS come soluzione completamente gestita, usare "Pod Sandboxing". La sandbox dei pod è una funzionalità del servizio Azure Kubernetes che crea un limite di isolamento tra l'applicazione contenitore e il kernel condiviso e le risorse di calcolo dell'host contenitore, ad esempio CPU, memoria e rete.

La sandbox dei pod integra altre misure di sicurezza o controlli di protezione dei dati per aiutare i carichi di lavoro dei tenant a proteggere le informazioni riservate e soddisfare i requisiti normativi, di settore o di conformità della governance. Questi requisiti includono Payment Card Industry Data Security Standard (PCI DSS), International Organization for Standardization (ISO) 27001 e Health Insurance Portability and Accountability Act (HIPAA).

Distribuire applicazioni in cluster o pool di nodi separati per isolare i carichi di lavoro del tenant di team o clienti diversi. Se la soluzione SaaS (Software as a Service) richiede più cluster e pool di nodi, è possibile usare più cluster e pool di nodi. Tuttavia, alcuni scenari traggono vantaggio da un singolo cluster con pool di nodi di macchina virtuale condivisi. Ad esempio, è possibile usare un singolo cluster per eseguire pod non attendibili e attendibili nello stesso nodo o colocare DaemonSet e contenitori con privilegi nello stesso nodo per velocizzare la comunicazione locale e il raggruppamento funzionale.

La sandbox dei pod consente di isolare le applicazioni tenant negli stessi nodi del cluster senza dover eseguire questi carichi di lavoro in cluster o pool di nodi separati. Altri metodi potrebbero richiedere la ricompilazione del codice oppure potrebbero creare altri problemi di compatibilità. Il sandboxing dei pod nel servizio Azure Kubernetes può eseguire qualsiasi contenitore non modificato all'interno di un limite avanzato della macchina virtuale di sicurezza.

Il sandboxing dei pod si basa su contenitori Kata in esecuzione nell'host contenitore Linux di Azure per lo stack del servizio Azure Kubernetes per fornire l'isolamento imposto dall'hardware. I contenitori Kata su AKS sono costruiti su un hypervisor di Azure con sicurezza rafforzata. Ottiene l'isolamento per ogni pod tramite una VM Kata leggera e annidata che utilizza le risorse del nodo macchina virtuale padre. In questo modello ogni pod Kata ottiene il proprio kernel in una macchina virtuale guest Kata annidata. Usare questo modello per inserire diversi contenitori Kata in una singola macchina virtuale guest, continuando a eseguire i contenitori nella macchina virtuale padre. Questo modello fornisce un solido limite di isolamento in un cluster del servizio Azure Kubernetes condiviso.

Per ulteriori informazioni, vedere Supporto per i contenitori isolati di Kata VM su AKS per il sandboxing dei pod.

Host dedicato di Azure

Host dedicato di Azure è un servizio che fornisce server fisici dedicati a una singola sottoscrizione di Azure per garantire l'isolamento hardware a livello di server fisico. È possibile effettuare il provisioning di questi host dedicati all'interno di un'area, di una zona di disponibilità e di un dominio di errore. È possibile inserire le macchine virtuali direttamente negli host di cui è stato effettuato il provisioning.

Utilizza il Dedicated Host con AKS per fornire i seguenti vantaggi:

• L'isolamento hardware garantisce che nessun'altra macchina virtuale venga inserita negli host dedicati, che fornisce un ulteriore livello di isolamento per i carichi di lavoro del tenant. Gli host dedicati vengono distribuiti negli stessi data center e condividono la stessa rete e la stessa infrastruttura di archiviazione sottostante degli altri host non isolati.

• Host dedicato fornisce il controllo sugli eventi di manutenzione avviati dalla piattaforma Azure. È possibile scegliere una finestra di manutenzione per ridurre l'impatto sui servizi e garantire la disponibilità e la privacy dei carichi di lavoro del tenant.

L'host dedicato può aiutare i provider SaaS a garantire che le applicazioni tenant soddisfino i requisiti normativi, di settore e di conformità della governance per proteggere le informazioni riservate. Per ulteriori informazioni, vedere Aggiungere un host dedicato a un cluster AKS.

Karpenter

Karpenter è un progetto open source di gestione del ciclo di vita dei nodi creato per Kubernetes. Aggiungere Karpenter a un cluster Kubernetes per migliorare l'efficienza e i costi di esecuzione dei carichi di lavoro in tale cluster. Karpenter controlla i pod che l'utilità di pianificazione kubernetes contrassegna come non pianificabile. Gestisce e fornisce dinamicamente nodi che soddisfano i requisiti dei pod.

Karpenter offre un controllo granulare sul provisioning dei nodi e sul posizionamento del carico di lavoro in un cluster gestito. Questo controllo ottimizza l'allocazione delle risorse, garantisce l'isolamento tra le applicazioni di ogni tenant e riduce i costi operativi, migliorando così la multi-tenancy. Quando costruisci una soluzione multitenant su AKS, Karpenter offre funzionalità utili per gestire requisiti applicativi diversi e supportare tenant diversi.

Ad esempio, potrebbe essere necessario che alcune applicazioni dei tenant vengano eseguite in pool di nodi ottimizzati per GPU e altri per l'esecuzione in pool di nodi ottimizzati per la memoria. Se l'applicazione richiede bassa latenza per l'archiviazione, è possibile usare Karpenter per indicare che un pod richiede un nodo eseguito in una zona di disponibilità specifica. È quindi possibile collocare la memoria e il livello applicativo.

Il servizio Azure Kubernetes abilita il provisioning automatico dei nodi nei cluster del servizio Azure Kubernetes tramite Karpenter. La maggior parte degli utenti deve usare la modalità di provisioning automatico del nodo per abilitare Karpenter come componente aggiuntivo gestito. Per altre informazioni, vedere Il provisioning automatico di Node. Se è necessaria una personalizzazione più avanzata, è possibile ospitare autonomamente Karpenter. Per ulteriori informazioni, vedere AKS Karpenter provider.

Macchine virtuali riservate

Il confidential computing è una misura di sicurezza che consente di proteggere i dati durante l'uso tramite isolamento e crittografia assistita da software o hardware. Questa tecnologia aggiunge un ulteriore livello di sicurezza agli approcci tradizionali, che consentono di proteggere i dati inattivi e i dati in transito.

La piattaforma AWS supporta il confidential computing tramite Nitro Enclaves, disponibili su istanze EC2 e Amazon EKS. Le istanze di Amazon EC2 supportano anche AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP). Il repository GitHub dell'attestazione di runtime fornisce elementi per compilare e distribuire un'immagine di Amazon Machine per il servizio Azure Kubernetes con supporto AMD SEV-SNP .

Azure offre ai clienti macchine virtuali riservate per soddisfare requisiti rigorosi di isolamento, privacy e sicurezza all'interno di un cluster del servizio Azure Kubernetes. Queste macchine virtuali riservate usano un ambiente di esecuzione attendibile basato su hardware. In particolare, le macchine virtuali riservate di Azure usano la tecnologia AMD SEV-SNP. Questa tecnologia nega l'accesso all'hypervisor e ad altri codici di gestione host alla memoria e allo stato della macchina virtuale. Usare questo approccio per aggiungere un ulteriore livello di difesa e protezione dall'accesso degli operatori. Per altre informazioni, vedere Usare macchine virtuali riservate in un cluster del servizioAzure Kubernetes e Panoramica delle macchine virtuali riservate in Azure.

Standard del processo informativo federale

Federal Information Process Standards (FIPS) 140-3 è uno standard governativo statunitense che definisce i requisiti minimi di sicurezza per i moduli crittografici nei prodotti e nei sistemi informatici. Abilitare la conformità FIPS per i pool di nodi AKS per migliorare l'isolamento, la privacy e la sicurezza dei carichi di lavoro del tuo tenant. La conformità FIPS consente di garantire l'uso di moduli crittografici convalidati per la crittografia, l'hashing e altre operazioni correlate alla sicurezza. Usare pool di nodi del servizio Azure Kubernetes abilitati per FIPS per usare algoritmi e meccanismi di crittografia affidabili, che consentono di soddisfare i requisiti normativi e di conformità del settore. Per altre informazioni su come rafforzare il comportamento di sicurezza degli ambienti del servizio Azure Kubernetes multi-tenant, vedere Abilitare FIPS per i pool di nodi del servizio Azure Kubernetes.

Crittografia basata su host

Nel servizio EKS, l'architettura potrebbe usare le funzionalità seguenti per migliorare la sicurezza dei dati:

• Crittografia Amazon Elastic Block Store (EBS): è possibile crittografare i dati inattivi nei volumi Amazon EBS collegati ai nodi di lavoro EKS.

• AWS Key Management Service (KMS): è possibile usare il servizio di gestione delle chiavi AWS per gestire le chiavi di crittografia e applicare la crittografia dei tuoi dati a riposo. Se si abilita la crittografia dei segreti, è possibile crittografare i segreti Kubernetes usando la propria chiave del Servizio di gestione delle chiavi AWS. Per altre informazioni, vedere Crittografare i segreti Kubernetes con IL Servizio di gestione delle chiavi AWS in cluster esistenti.

• Crittografia lato server Amazon S3: se le applicazioni EKS interagiscono con Amazon S3, è possibile abilitare la crittografia lato server per i bucket S3 per proteggere i dati inattivi.

la crittografia basata su host nel servizio Azure Kubernetes rafforza ulteriormente l'isolamento, la privacy e la sicurezza del carico di lavoro del tenant. Quando si abilita la crittografia basata su host, AKS crittografa i dati a riposo sui computer host sottostanti. Questo approccio consente di proteggere le informazioni sensibili del tenant da accessi non autorizzati. Quando si abilita la crittografia end-to-end, i dischi temporanei e i dischi temporanei del sistema operativo vengono crittografati inattivi tramite chiavi gestite dalla piattaforma.

Nel servizio AKS, i dischi del sistema operativo e i dischi dati usano per impostazione predefinita la crittografia lato server tramite chiavi gestite dalla piattaforma. Le cache per questi dischi vengono crittografate inattivi tramite chiavi gestite dalla piattaforma. È possibile usare la propria chiave di crittografia della chiave per crittografare la chiave di protezione dei dati. Questo metodo è denominato crittografia envelope o wrapping. La chiave di crittografia specificata crittografa anche la cache per i dischi del sistema operativo e i dischi dati.

La crittografia basata su host aggiunge un livello di sicurezza per gli ambienti multi-tenant. I dati di ogni tenant nel disco del sistema operativo e nelle cache dei dischi dati vengono crittografati inattivi tramite chiavi gestite dal cliente o gestite dalla piattaforma, a seconda del tipo di crittografia del disco selezionato. Per altre informazioni, vedere le risorse seguenti:

• Crittografia basata su host su AKS
• BYOK con dischi di Azure nel Servizio Azure Kubernetes (AKS)
• Crittografia lato server dell'archiviazione su disco di Azure

Aggiornamenti e aggiornamenti

Azure aggiorna periodicamente la piattaforma di hosting delle macchine virtuali per migliorare l'affidabilità, le prestazioni e la sicurezza. Questi aggiornamenti vanno dall'applicazione di patch ai componenti software nell'ambiente di hosting all'aggiornamento dei componenti di rete o alla messa fuori servizio dell'hardware. Per altre informazioni, vedere Manutenzione per le macchine virtuali in Azure.

Gli aggiornamenti dell'infrastruttura di hosting delle macchine virtuali in genere non influiscono sulle macchine virtuali ospitate, ad esempio i nodi agente dei cluster del servizio Azure Kubernetes esistenti. Per gli aggiornamenti che influiscono sulle macchine virtuali ospitate, Azure riduce al minimo i casi che richiedono riavvii sospendo la macchina virtuale durante l'aggiornamento dell'host o la migrazione in tempo reale della macchina virtuale a un host già aggiornato.

Se un aggiornamento richiede un riavvio, Azure fornisce una notifica e un intervallo di tempo quando è possibile avviare l'aggiornamento. La finestra di manutenzione automatica per i computer host è in genere di 35 giorni, a meno che l'aggiornamento non sia urgente.

È possibile usare la manutenzione pianificata per aggiornare le macchine virtuali. Gestire le notifiche di manutenzione pianificata usando l'interfaccia della riga di comando di Azure, Azure PowerShell o il portale di Azure. La manutenzione pianificata rileva se si usa automaticamente la funzionalità di aggiornamento automatico del cluster e pianifica gli aggiornamenti durante la finestra di manutenzione. Per altre informazioni, vedere Usare la manutenzione pianificata per pianificare le finestre di manutenzione per il cluster del servizio Azure Kubernetes e il comando az aks maintenanceconfiguration.

Aggiornamenti di Kubernetes

Parte del ciclo di vita del cluster del servizio Azure Kubernetes include l'aggiornamento periodico alla versione più recente di Kubernetes. È consigliabile applicare gli aggiornamenti per ottenere le versioni e le funzionalità di sicurezza più recenti. Per aggiornare la versione Kubernetes delle macchine virtuali del pool di nodi esistenti, è necessario assegnare e svuotare i nodi e sostituirli con nuovi nodi basati su un'immagine del disco Kubernetes aggiornata.

Per impostazione predefinita, AKS configura gli aggiornamenti per effettuare un aumento con un nodo extra. Un valore predefinito di uno per le impostazioni max-surge riduce al minimo l'interruzione del carico di lavoro. Questa configurazione crea un nodo aggiuntivo per sostituire i nodi con versioni precedenti prima di mettere in quarantena o svuotare le applicazioni esistenti. È possibile personalizzare il max-surge valore per pool di nodi per ottimizzare il compromesso tra velocità di aggiornamento e interruzione dell'aggiornamento. Un valore maggiore max-surge aumenta la velocità del processo di aggiornamento, ma un valore elevato per max-surge può causare interruzioni durante il processo di aggiornamento.

Ad esempio, un max-surge valore pari a 100% fornisce il processo di aggiornamento più rapido possibile raddoppiando il numero di nodi. Ma questo valore svuota anche tutti i nodi nel pool di nodi contemporaneamente. È possibile usare questo valore elevato per il test, ma per i pool di nodi di produzione usare un'impostazione max-surge di 33%.

Il servizio Azure Kubernetes accetta valori interi e percentuali per il max-surge valore. Un numero intero, ad 5 esempio, indica cinque nodi aggiuntivi da aumentare. È possibile impostare il valore percentuale per max-surge da 1% a 100%, arrotondato al numero di nodi più vicino. Un valore di 50% indica un valore di aumento della metà del numero di nodi corrente nel pool.

Durante un aggiornamento, è possibile impostare il max-surge valore su almeno 1 e un valore massimo uguale al numero di nodi nel pool di nodi. È possibile impostare valori più grandi, ma il numero massimo di nodi per max-surge non può superare il numero di nodi nel pool.

Aggiornare i pool di nodi

Per visualizzare gli aggiornamenti disponibili, usare az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Per visualizzare lo stato dei pool di nodi, usare az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Per aggiornare un pool a nodo singolo, usare az aks nodepool upgrade.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Per altre informazioni, vedere le risorse seguenti:

• Aggiornamento dell’immagine del nodo del servizio Azure Kubernetes
• Aggiornare un piano di controllo del cluster con più pool di nodi

Considerazioni sull'aggiornamento

Quando si aggiorna la versione di Kubernetes in un cluster AKS, tenere in considerazione le seguenti best practice:

• È consigliabile aggiornare tutti i pool di nodi in un cluster del servizio Azure Kubernetes alla stessa versione di Kubernetes. Il comportamento predefinito di az aks upgrade è di aggiornare tutti i pool di nodi e il piano di controllo.

• Eseguire manualmente gli aggiornamenti o impostare un canale di aggiornamento automatico nel cluster. Se si usa la manutenzione pianificata per applicare patch alle macchine virtuali, gli aggiornamenti automatici vengono avviati anche durante la finestra di manutenzione specificata. Per ulteriori informazioni, vedere Aggiornare un cluster AKS.

• Il az aks upgrade comando con il --control-plane-only flag aggiorna il piano di controllo del cluster e non modifica i pool di nodi associati nel cluster. Per aggiornare i singoli pool di nodi, specificare il pool di nodi di destinazione e la az aks nodepool upgrade versione di Kubernetes nel comando .

• Un aggiornamento del cluster del servizio Azure Kubernetes attiva un processo di blocco e svuotamento dei nodi. Se è disponibile una quota di calcolo ridotta, l'aggiornamento può non riuscire. Per altre informazioni, vedere Aumentare le quote vCPU a livello di area.

• Configurare il max-surge parametro in base alle esigenze. Usare un valore intero o percentuale. Per i pool di nodi di produzione, usare un'impostazione max-surge del 33%. Per altre informazioni, vedere Personalizzare l'aggiornamento della sovratensione del numero di nodi.

• Quando si aggiorna un cluster AKS che usa l'interfaccia di rete di Azure Container Networking, assicurarsi che la subnet disponga di indirizzi IP privati sufficienti per i nodi aggiuntivi creati dalle impostazioni max-surge. Per ulteriori informazioni, vedere Configurare l'interfaccia di rete di Azure Container Networking in AKS.

• Se i pool di nodi del cluster si estendono su più zone di disponibilità all'interno di un'area, il processo di aggiornamento può creare temporaneamente una configurazione della zona sbilanciata. Per ulteriori informazioni, consulta Pool di nodi che si estendono su più zone di disponibilità.

Contributori

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

Autori principali:

• Paolo Salvatori | Ingegnere del sistema principale

Altri collaboratori:

• Laura Nicolas | Senior Software Engineer
• Chad Kittel | Principal Software Engineer
• Prezzo ed | Senior Content Program Manager
• Theano Petersen | Redattore tecnico

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

Passaggi successivi

• Pratiche migliori per i cluster AKS
• Creare un cluster privato AKS con una zona DNS pubblica
• Crea un cluster AKS (Azure Kubernetes Service) privato usando Terraform e Azure DevOps
• Creare un cluster del servizio Azure Kubernetes pubblico o privato con il gateway applicazione NAT di Azure e il gateway applicazione di Azure
• Usare endpoint privati con un cluster AKS privato
• Creare un cluster AKS con l'Application Gateway Ingress Controller
• Training: Introduzione a Kubernetes
• Formazione: Introduzione a Kubernetes su Azure
• Training: Sviluppare e distribuire applicazioni in Kubernetes
• Training: Ottimizzare i costi di calcolo nel servizio Azure Kubernetes

" output is necessary.)

• AKS per i professionisti di Amazon EKS
• Gestione delle identità e degli accessi Kubernetes
• Monitoraggio e registrazione Kubernetes
• Accesso sicuro alla rete Kubernetes
• Opzioni di archiviazione per un cluster Kubernetes
• Gestione dei costi per Kubernetes
• Governance del cluster
• Percorso della soluzione AKS
• Guida alle operazioni di gestione avanzata del servizio Azure Kubernetes (AKS)
• Scegliere un'opzione di calcolo Kubernetes ai margini della rete
• GitOps per AKS