Modifica

Condividi tramite

Gestione del nodo e del pool di nodi Kubernetes

Servizio Azure Kubernetes
Macchine virtuali di Azure

L'architettura kubernetes si basa su due livelli: il piano di controllo e uno o più nodi nei pool di nodi. Questo articolo descrive e confronta il modo in cui Amazon Elastic Kubernetes Service (Amazon EKS) e servizio Azure Kubernetes (AKS) gestiscono i nodi agente o di lavoro.

Nota

Questo articolo fa parte di una serie di articoli che aiutano i professionisti che hanno familiarità con Amazon EKS per comprendere servizio Azure Kubernetes (servizio Azure Kubernetes).

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.

Diagramma che mostra il piano di controllo e i nodi nell'architettura 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 eseguito il provisioning di ogni nodo gestito come parte di un gruppo Amazon EC2 Auto Scaling che Amazon EKS gestisce e controlla. 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. Ogni gruppo di nodi può essere configurato per l'esecuzione in più zone di disponibilità all'interno di un'area.

Per altre informazioni sui nodi gestiti di Amazon EKS, vedere Creazione di un gruppo di nodi gestiti e Aggiornamento di 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 su come usare Fargate con Amazon EKS, vedere AWS Fargate.

Karpenter

Karpenter è un progetto open source progettato per 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, consentendo un ridimensionamento efficiente e l'ottimizzazione dei costi. Le funzioni principali sono:

  • Monitorare i pod che l'utilità di pianificazione Kubernetes non può pianificare a causa di vincoli di risorse.
  • Valutare i requisiti di pianificazione (richieste di risorse, selettori di nodo, affinità, tolerazioni e così via) dei pod non pianificabili.
  • Effettuare il provisioning di nuovi nodi che soddisfano i requisiti di tali pod.
  • Rimuovere i nodi quando non sono più necessari.

Con Karpenter è possibile definire NodePools con vincoli sul provisioning dei nodi, ad esempio taints, etichette, requisiti (tipi di istanza, zone e così via) e limiti per le risorse di cui è stato effettuato il provisioning totale. Quando si distribuiscono carichi di lavoro, si specificano vari vincoli di pianificazione nelle specifiche dei pod, ad esempio richieste/limiti delle risorse, selettori di nodo, affinità nodo/pod, tolerazioni e vincoli di distribuzione della topologia. Karpenter effettua quindi il provisioning di nodi di dimensioni corrette in base a queste specifiche.

Prima del lancio di Karpenter, gli utenti del servizio Azure Kubernetes si affidavano principalmente ai gruppi di scalabilità automatica amazon EC2 e al cluster Kubernetes Autoscaler (CAS) per regolare dinamicamente la capacità di calcolo dei cluster. Non è necessario creare decine di gruppi di nodi per ottenere la flessibilità e la diversità che si ottiene con Karpenter. A differenza di Kubernetes Cluster Autoscaler, Karpenter non è strettamente associato alle versioni di Kubernetes e non richiede di passare 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 compatibile con il cluster. Karpenter è stato progettato per superare alcune delle sfide presentate da Cluster Autoscaler offrendo modi semplificati per:

  • Effettuare il provisioning dei nodi in base ai requisiti del carico di lavoro.
  • Creare configurazioni di nodi diverse in base al tipo di istanza, usando opzioni NodePool flessibili. Invece di gestire molti gruppi di nodi personalizzati specifici, Karpenter può consentire di gestire capacità di carico di lavoro diverse con un singolo NodePool flessibile.
  • È possibile migliorare la pianificazione dei pod su larga scala avviando rapidamente i nodi e pianificando i pod.

Per informazioni e documentazione sull'uso di Karpenter, visitare il sito karpenter.sh.

Karpenter avvicina la gestione del ridimensionamento alle API native di Kubernetes che gruppi di ridimensionamento automatico (ASG) e gruppi di nodi gestiti (MNG). I gruppi di sicurezza e i gruppi di sicurezza di rete sono astrazioni native di AWS in cui il ridimensionamento viene attivato in base alle metriche a livello di AWS, ad esempio il carico della CPU EC2. l'utilità di scalabilità automatica del cluster collega le astrazioni Kubernetes alle astrazioni AWS, ma perde una certa flessibilità, ad esempio la pianificazione per una zona di disponibilità specifica.

Karpenter rimuove un livello di astrazione DI AWS per introdurre una certa flessibilità direttamente in Kubernetes. Karpenter è meglio usato per i cluster con carichi di lavoro che riscontrano periodi di domanda elevata, spiky o hanno requisiti di calcolo diversi. I gruppi di sicurezza di rete e i gruppi di sicurezza di Azure sono validi per i cluster che eseguono carichi di lavoro che tendono a essere più statici e coerenti. È possibile usare una combinazione di nodi gestiti in modo dinamico e statico, a seconda dei requisiti.

Contenitori Kata

i contenitori Kata è un progetto open source che fornisce un runtime di contenitori sicuro che combina la natura leggera dei contenitori con i vantaggi di sicurezza delle macchine virtuali. Risolve la necessità di un maggiore isolamento e 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 eseguono contenitori in una macchina virtuale conforme a OCI, fornendo un isolamento rigoroso tra contenitori nella stessa macchina host. i contenitori Kata forniscono le funzionalità seguenti:

  • Isolamento avanzato del carico di lavoro: ogni contenitore viene eseguito nella propria macchina virtuale leggera, garantendo l'isolamento a livello di hardware.
  • miglioramento della sicurezza: l'uso della tecnologia della macchina virtuale offre un ulteriore livello di sicurezza, riducendo il rischio di interruzioni dei contenitori.
  • Compatibilità con gli standard di settore: i contenitori Kata si integrano con strumenti standard del settore, ad esempio il formato del contenitore OCI e l'interfaccia CRI di Kubernetes.
  • supporto per più architetture e hypervisor: i contenitori Kata supportano le architetture AMD64 e ARM e possono essere usati con hypervisor come Cloud-Hypervisor e Firecracker.
  • Facile distribuzione e gestione: Kata Containers astrae la complessità dell'orchestrazione dei carichi di lavoro sfruttando il sistema di orchestrazione Kubernetes.

I clienti AWS possono configurare ed eseguire Kata Containers in AWS configurando un cluster Amazon Elastic Kubernetes Service (EKS) per l'uso di Firecracker, una tecnologia di virtualizzazione open source sviluppata da Amazon per creare e gestire servizi sicuri, multi-tenant e basati su funzioni. Firecracker consente ai clienti di distribuire carichi di lavoro in macchine virtuali leggere, denominate microVM, che offrono sicurezza e isolamento dei carichi di lavoro avanzati sulle macchine virtuali tradizionali, consentendo al tempo stesso la velocità e l'efficienza delle risorse dei contenitori. L'abilitazione di contenitori Kata in AWS EKS richiede una serie di passaggi manuali descritti in Miglioramento dell'isolamento e della sicurezza del carico di lavoro Kubernetes con Kata Containers.

Host dedicati

Quando si usa EKS (Amazon Elastic Kubernetes Service) per distribuire ed eseguire contenitori, è possibile eseguirli in host dedicati Amazon EC2. Tuttavia, è importante notare che questa funzionalità è disponibile solo per i gruppi di nodi autogestito. Ciò significa che i clienti devono creare manualmente un modello di avvio , i gruppi di ridimensionamento automaticoe registrarli con il cluster del servizio Azure Kubernetes. Il processo di creazione di queste risorse è uguale a quello per il ridimensionamento automatico ec2 generale.

Per informazioni più dettagliate sull'esecuzione di contenitori in host dedicati EC2 con AWS EKS, vedere la documentazione seguente:

Nodi e pool di nodi del servizio Azure Kubernetes

La creazione di un cluster del servizio Azure Kubernetes crea e configura automaticamente 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 del servizio Azure Kubernetes senza costi come risorsa gestita di Azure. Il piano di controllo e le relative risorse esistono solo nell'area in cui è stato creato il cluster.

I nodi, detti anche nodi agente o nodi di lavoro, ospitano i carichi di lavoro e le applicazioni. Nel servizio Azure Kubernetes i clienti gestiscono e pagano completamente i nodi agente collegati al cluster del servizio Azure Kubernetes.

Per eseguire applicazioni e servizi di supporto, un cluster del servizio Azure Kubernetes necessita di almeno un nodo: Una macchina virtuale di Azure deve eseguire 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 raggruppa i nodi della stessa configurazione in pool di nodi di macchine virtuali che eseguono carichi di lavoro del servizio Azure Kubernetes. I pool di nodi di sistema servono allo scopo principale di ospitare pod di sistema critici, ad esempio CoreDNS. I pool di nodi utente servono allo scopo principale di ospitare i pod del carico di lavoro. Se si vuole avere 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.

Diagramma che mostra un singolo nodo Kubernetes.

È anche possibile creare più pool di nodi utente per separare carichi di lavoro diversi in nodi diversi per evitare il problema del vicino rumoroso o per supportare applicazioni con esigenze di calcolo o archiviazione diverse.

Ogni nodo agente di un pool di nodi di sistema o utente è una macchina virtuale di cui viene effettuato il provisioning come parte di Azure set di scalabilità di macchine virtuali e gestita dal cluster del servizio Azure Kubernetes. Per altre informazioni, vedere Nodi e pool di nodi.

È possibile definire il numero iniziale e le dimensioni per i nodi del ruolo 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.

Importante

Per garantire una migliore latenza per le chiamate all'interno del nodo e le comunicazioni con i servizi della piattaforma, selezionare una serie di macchine virtuali che supporta la rete accelerata.

Creazione del pool di nodi

È possibile aggiungere un pool di nodi a un cluster del servizio Azure Kubernetes nuovo o esistente usando la portale di Azure, l'interfaccia della riga di comando di Azure, l'API REST del servizio Azure Kubernetes o gli strumenti di infrastruttura come codice (IaC), ad esempio Bicep, modelli di Azure Resource Manager o Terraform. Per altre informazioni su come aggiungere pool di nodi a un cluster del servizio Azure Kubernetes esistente, vedere Creare e gestire più pool di nodi per un cluster in servizio Azure Kubernetes (servizio Azure Kubernetes).

Quando si crea un nuovo pool di nodi, il set di scalabilità di macchine virtuali associato viene creato nel gruppo di risorse del nodo, un gruppo di risorse di Azure che 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 durante l'eliminazione di un cluster, pertanto è consigliabile usare questo gruppo di risorse solo per le risorse che condividono il ciclo di vita del cluster.

Aggiungere un pool di nodi

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 a un cluster del myAKSCluster servizio Azure Kubernetes esistente denominato myResourceGroup 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. L'uso di macchine virtuali spot per i nodi con il cluster del servizio Azure Kubernetes sfrutta la capacità di Azure non utilizzata con un notevole risparmio sui costi. La quantità di capacità non utilizzata disponibile varia in base a molti fattori, tra cui dimensioni del nodo, area e ora del giorno.

Quando si distribuisce un pool di nodi spot, Azure alloca i nodi spot se è disponibile la capacità. Ma non esiste alcun contratto di servizio per i nodi spot. Un set di scalabilità spot che esegue il backup del pool di nodi spot viene distribuito in un singolo dominio di errore e non offre garanzie di disponibilità elevata. Quando Azure richiede di nuovo la capacità, l'infrastruttura di Azure rimuove i nodi spot e si riceve al massimo un avviso di 30 secondi prima della rimozione. Tenere presente che un pool di nodi spot non può essere il pool di nodi predefinito del cluster. Un pool di nodi spot può essere usato solo per un pool secondario.

I nodi spot sono destinati a carichi di lavoro che possono gestire interruzioni, terminazioni anticipata o eliminazioni. Ad esempio, i processi di elaborazione batch, gli ambienti di sviluppo e test e i carichi di lavoro di calcolo di grandi dimensioni sono buoni candidati per la pianificazione in un pool di nodi spot. Per altri dettagli, vedere le 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 altre informazioni sui pool di nodi spot, vedere Aggiungere un pool di nodi spot a un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes).

Dischi del sistema operativo temporanei

Per impostazione predefinita, Azure replica automaticamente il disco del sistema operativo della macchina virtuale in Archiviazione di Azure per evitare perdite di dati se la macchina virtuale deve essere spostata in un altro host. Tuttavia, poiché i contenitori non sono progettati per rendere persistente lo stato locale, mantenere il disco del sistema operativo nell'archiviazione offre un valore limitato per il servizio Azure Kubernetes. Esistono alcuni svantaggi, ad esempio il provisioning dei nodi più lento e una latenza di lettura/scrittura superiore.

Al contrario, i dischi temporanei del sistema operativo vengono archiviati solo nel computer host, come un disco temporaneo, e offrono una latenza di lettura/scrittura inferiore e un ridimensionamento dei nodi e aggiornamenti del cluster più veloci. Come un disco temporaneo, un disco del sistema operativo temporaneo è incluso nel prezzo della macchina virtuale, quindi non vengono addebitati costi di archiviazione aggiuntivi.

Importante

Se non si richiedono in modo esplicito i dischi gestiti per il sistema operativo, il servizio Azure Kubernetes usa per impostazione predefinita un sistema operativo temporaneo, se possibile per una configurazione specifica del pool di nodi.

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 I/O come dimensioni della cache in gibibyte (GiB).

Ad esempio, le dimensioni predefinite del servizio Azure Kubernetes Standard_DS2_v2 con le dimensioni predefinite del disco del sistema operativo da 100 GB supportano il sistema operativo temporaneo, ma ha solo 86 GB di dimensioni della cache. Questa configurazione viene impostata per impostazione predefinita su disco gestito 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 da 100 GB supporta il sistema operativo temporaneo e ha 200 GB di spazio nella cache. Se un utente non specifica il tipo di disco del sistema operativo, per impostazione predefinita un pool di nodi ottiene un 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 sui dischi temporanei del sistema operativo, vedere Sistema operativo temporaneo.

Pool di nodi di macchine virtuali nel servizio Azure Kubernetes

Ogni gruppo di nodi gestiti in del servizio Azure Kubernetes è supportato da un gruppo di scalabilità automatica amazon EC2, gestito da Amazon EKS. Questa integrazione consente al servizio Azure Kubernetes di gestire automaticamente il provisioning e il ridimensionamento delle istanze EC2 all'interno del gruppo di nodi. Anche se i gruppi di ridimensionamento automatico possono essere configurati per supportare più tipi di istanza EC2, non offrono la possibilità di 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 definiti dall'utente. In questo modo si garantisce un processo di gestione semplificato e automatizzato per il gruppo di nodi offrendo flessibilità nella selezione dei tipi di istanza EC2 in base ai requisiti del carico di lavoro. Tuttavia, i clienti AWS possono avviare nodi Amazon Linux autogestito con eksctl o AWS Management Console.

Con pool di nodi di macchine virtuali, il servizio Azure Kubernetes gestisce il provisioning e il bootstrap di ogni nodo agente. Per i pool di nodi dei set di scalabilità di macchine virtuali, il servizio Azure Kubernetes gestisce il modello dei set di scalabilità di macchine virtuali e lo usa per ottenere coerenza tra tutti i nodi dell'agente nel pool di nodi. I pool di nodi macchine virtuali consentono invece di orchestrare il cluster con le macchine virtuali più adatte ai singoli carichi di lavoro e 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 (SKU) designate per supportare diversi tipi di carichi di lavoro. Queste dimensioni delle macchine virtuali, denominate SKU, vengono classificate in famiglie diverse ottimizzate per scopi specifici. Per altre informazioni sugli SKU delle macchine virtuali, vedere la panoramica SKU delle macchine virtuali.

Per abilitare il ridimensionamento di più dimensioni di macchine virtuali, il tipo di pool di nodi macchine virtuali usa un ScaleProfile che configura la scalabilità del pool di nodi, in particolare l'elenco desiderato di dimensioni e conteggio delle macchine virtuali. Un ManualScaleProfile è un profilo di scalabilità che specifica le dimensioni e il numero di macchine virtuali desiderate. In un ManualScaleProfileè consentita una sola dimensione di macchina virtuale. È necessario creare un ManualScaleProfile separato 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à: le specifiche del nodo possono essere aggiornate 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.
  • l'efficienza: è possibile ridurre il footprint del nodo per il cluster, semplificando i requisiti operativi.

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

Nella tabella seguente vengono confrontati i pool di nodi delle macchine virtuali con pool di nodi standard set di scalabilità.

Tipo di pool di nodi Funzionalità
Pool di nodi macchine virtuali È possibile aggiungere, rimuovere o aggiornare nodi in un pool di nodi. I tipi di macchina virtuale possono essere qualsiasi macchina virtuale dello stesso tipo di famiglia (ad esempio, serie D, serie A e così via).
Pool di nodi basato su set di scalabilità di macchine virtuali È possibile aggiungere o rimuovere nodi con le stesse dimensioni e digitare in un pool di nodi. Se si aggiungono nuove dimensioni della macchina virtuale al cluster, è necessario creare un nuovo pool di nodi.

I pool di nodi della macchina virtuale presentano le limitazioni seguenti:

  • il di scalabilità automatica del cluster non è supportato.
  • 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 CRUD o gestire il pool.
  • snapshot del pool di nodi non è supportato.
  • Tutte le dimensioni delle macchine virtuali selezionate 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 macchina virtuale 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 offrono il provisioning rapido dei pod e si paga solo al secondo per il tempo di esecuzione. Non è necessario attendere che il ridimensionamento automatico del cluster distribuisca nuovi nodi di lavoro per eseguire più repliche pod. I nodi virtuali sono supportati solo con pod e nodi Linux. Il componente aggiuntivo nodi virtuali per il servizio Azure Kubernetes si basa sul progetto Kubelet virtuale open source.

La funzionalità del nodo virtuale dipende da Istanze di Azure Container. Per altre informazioni sui nodi virtuali, vedere Creare e configurare un cluster servizio Azure Kubernetes del servizio Azure Kubernetes per l'uso di nodi virtuali.

Taints, labels e tag

Quando si crea un pool di nodi, è possibile aggiungere tag e etichette Kubernetes a tale pool di nodi. Quando si aggiunge un taint, un'etichetta o un tag, tutti i nodi all'interno del pool di nodi ottengono tale taint, etichetta o tag.

Per creare un pool di nodi con un taint, è possibile usare il az aks nodepool add comando con il --node-taints parametro . Per etichettare i nodi in un pool di nodi, è possibile 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à. Il servizio Azure Kubernetes 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 alcun nodo:

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

Per altri prefissi riservati, vedere Etichette, annotazioni etaints note di Kubernetes.

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

Nella colonna Utilizzo nodo virtuale:

  • N/D indica che la proprietà non si applica ai nodi virtuali perché richiederebbe la modifica dell'host.
  • Lo stesso significa che i valori previsti sono gli stessi per un pool di nodi virtuali come per un pool di nodi standard.
  • La macchina virtuale sostituisce i valori dello SKU della macchina virtuale, perché i pod dei nodi virtuali non espongono alcuna macchina virtuale sottostante.
  • 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 Azure Container.
  • La rete virtuale del nodo virtuale è la rete virtuale che contiene la subnet del nodo virtuale.
Etichetta Valore Esempio, opzioni Utilizzo dei nodi virtuali
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Uguali
kubernetes.io/arch amd64 runtime.GOARCH N/D
kubernetes.io/os <OS Type> Linux oppure Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Uguali
topology.kubernetes.io/zone <Azure zone> 0 Uguali
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Uguali
kubernetes.azure.com/mode <mode> User oppure System User
kubernetes.azure.com/role agent Agent Uguali
kubernetes.azure.com/scalesetpriority <scale set priority> Spot oppure Regular N/D
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Uguali
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N/D
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N/D
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Versione del nodo virtuale
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Nome della subnet del nodo virtuale
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Rete virtuale del nodo virtuale
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N/D
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N/D
kubernetes.azure.com/accelerator <accelerator> nvidia N/D
kubernetes.azure.com/fips_enabled <fips enabled> True N/D
kubernetes.azure.com/os-sku <os/sku> Vedere Creare o aggiornare lo SKU del sistema operativo Linux SKU

Pool di nodi Windows

Il servizio Azure Kubernetes supporta la creazione e l'uso di pool di nodi del contenitore Windows Server tramite il plug-in di rete CNI (Azure Container Network Interface). Per pianificare gli intervalli di subnet e le considerazioni di rete necessari, vedere Configurare la rete CNI di Azure.

Il comando seguente az aks nodepool add aggiunge un pool di nodi che esegue i 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 del servizio Azure Kubernetes. Per altre informazioni su come creare un cluster del servizio Azure Kubernetes con un pool di nodi Di Windows, vedere Creare un contenitore di Windows Server nel servizio Azure Kubernetes.

Considerazioni sul pool di nodi

Quando si creano e gestiscono pool di nodi e più pool di nodi, 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 del servizio Azure Kubernetes è presente un altro pool di nodi di sistema. 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 del servizio Azure Kubernetes deve usare i servizi di bilanciamento del carico dello SKU Standard. I servizi di bilanciamento del carico sku basic non supportano più pool di nodi.
  • Tutti i pool di nodi del cluster devono trovarsi nella stessa rete virtuale e tutte le subnet assegnate a qualsiasi pool di nodi devono trovarsi nella stessa rete virtuale.
  • Se si creano più pool di nodi in fase di creazione del cluster, le versioni di Kubernetes per tutti i pool di nodi devono corrispondere alla versione del piano di controllo. È possibile aggiornare le versioni dopo il provisioning del cluster usando le operazioni per ogni pool di nodi.

Ridimensionamento del pool di nodi

Quando il carico di lavoro dell'applicazione cambia, potrebbe essere necessario modificare il numero di nodi in un pool di nodi. È possibile aumentare o ridurre manualmente il numero di nodi usando 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 usando il ridimensionamento automatico del cluster

Il servizio Azure Kubernetes supporta automaticamente il ridimensionamento automatico dei pool di nodi con il ridimensionamento automatico del cluster. Questa funzionalità viene abilitata in ogni pool di nodi e viene definito 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 e 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

È possibile disabilitare il ridimensionamento automatico del cluster con az aks nodepool update passando 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 az aks nodepool update, specificando 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 Ridimensionare automaticamente un cluster per soddisfare le esigenze delle applicazioni in servizio Azure Kubernetes (servizio Azure Kubernetes).

Pod Sandboxing

I clienti del servizio Azure Kubernetes possono configurare ed eseguire facilmente contenitori Kata nel servizio Azure Kubernetes in modo completamente gestito. Ciò è reso possibile tramite l'uso di Pod Sandboxing, una funzionalità che crea un limite di isolamento tra l'applicazione contenitore e il kernel condiviso e le risorse di calcolo dell'host contenitore.

Il servizio Azure Kubernetes include un meccanismo denominato Pod Sandboxing che fornisce 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. Pod Sandboxing integra altre misure di sicurezza o controlli di protezione dei dati per aiutare i carichi di lavoro tenant a proteggere le informazioni sensibili e soddisfare i requisiti normativi, di settore o di conformità della governance, ad esempio Payment Card Industry Data Security Standard (PCI DSS), International Organization for Standardization (ISO) 27001 e Health Insurance Portability and Accountability Act (HIPAA).

Distribuendo applicazioni in cluster o pool di nodi separati, è possibile isolare fortemente i carichi di lavoro del tenant di team o clienti diversi. L'uso di più cluster e pool di nodi potrebbe essere adatto ai requisiti di isolamento di molte organizzazioni e soluzioni SaaS, ma esistono scenari in cui un singolo cluster con pool di nodi di macchine virtuali condivise è più efficiente. Ad esempio, è possibile usare un singolo cluster quando si eseguono pod non attendibili e attendibili nello stesso nodo o si concatenano DaemonSet e contenitori con privilegi nello stesso nodo per una comunicazione locale e un raggruppamento funzionale più veloci. pod Sandboxing consente di isolare fortemente le applicazioni tenant negli stessi nodi del cluster senza dover eseguire questi carichi di lavoro in cluster o pool di nodi separati. Per altri metodi è necessario ricompilare il codice o causare altri problemi di compatibilità, ma 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 nel servizio Azure Kubernetes si basa su contenitori Kata eseguiti nell'host contenitore Linux di Azure per lo stack di del servizio Azure Kubernetes per fornire l'isolamento imposto dall'hardware. I contenitori Kata nel servizio Azure Kubernetes sono basati su un hypervisor di Azure con protezione avanzata. Ottiene l'isolamento per ogni pod tramite una macchina virtuale Kata annidata e leggera che usa risorse da un 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 molti contenitori Kata in una singola macchina virtuale guest, continuando a eseguire i contenitori nella macchina virtuale padre. Questo modello fornisce un limite di isolamento sicuro in un cluster del servizio Azure Kubernetes condiviso.

Per altre informazioni, vedere:

Host dedicato di Azure

host dedicato di Azure è un servizio che fornisce server fisici dedicati a una singola sottoscrizione di Azure e forniscono 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 ed è possibile inserire le macchine virtuali direttamente negli host di cui è stato effettuato il provisioning.

L'uso di host dedicato di Azure con il servizio Azure Kubernetes offre diversi vantaggi, tra cui:

  • 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 di Azure 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 di Azure 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 altre informazioni, vedere Aggiungere un host dedicato di Azure a un cluster del servizio Azure Kubernetes.

Karpenter

Karpenter è un progetto di gestione del ciclo di vita dei nodi open source creato per Kubernetes. L'aggiunta di Karpenter a un cluster Kubernetes può 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. Esegue anche il provisioning e la gestione dinamica dei nodi che possono soddisfare i requisiti del pod.

Karpenter offre un controllo granulare sul provisioning dei nodi e sul posizionamento del carico di lavoro in un cluster gestito. Questo controllo migliora la multi-tenancy ottimizzando l'allocazione delle risorse, garantendo l'isolamento tra le applicazioni di ogni tenant e riducendo i costi operativi. Quando si compila una soluzione multi-tenant nel servizio Azure Kubernetes, Karpenter offre funzionalità utili per gestire requisiti applicativi diversi per 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 una bassa latenza per l'archiviazione, è possibile usare Karpenter per indicare che un pod richiede un nodo che viene eseguito in una zona di disponibilità specifica in modo che sia possibile condividere il livello di archiviazione e applicazione.

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 scegliere di ospitare autonomamente Karpenter. Per altre informazioni, vedere il provider karpenter del servizio Azure Kubernetes .

Macchine virtuali riservate

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

La piattaforma AWS supporta il confidential computing tramite Nitro Enclaves, disponibili su istanze EC2, nonché su Amazon Elastic Kubernetes Service (EKS). Per altre informazioni, vedere questo articolo nella documentazione di Amazon. Inoltre, le istanze di Amazon EC2 supportano AMD SEV-SNP. Questo repository gitHub fornisce elementi per compilare e distribuire un AMI (Amazon Machine Image) per il servizio Azure Kubernetes con supporto di AMD SEV-SNP.

D'altra parte, Azure offre ai clienti macchine virtuali riservate per soddisfare rigorosi requisiti 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 Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP), che nega l'accesso all'hypervisor e ad altri codici di gestione host alla memoria e allo stato della macchina virtuale. In questo modo viene aggiunto un ulteriore livello di difesa e protezione dall'accesso degli operatori. Per altri dettagli, è possibile fare riferimento alla documentazione su usando macchine virtuali riservate in un cluster del servizio Azure Kubernetes e la panoramica delle macchine virtuali riservate in Azure.

Standard FIPS (Federal Information Process Standards)

FIPS 140-3 è uno standard del governo degli Stati Uniti che definisce i requisiti minimi di sicurezza per i moduli crittografici nei prodotti e nei sistemi informatici. Abilitando conformità FIPS per i pool di nodi del servizio Azure Kubernetes, è possibile migliorare l'isolamento, la privacy e la sicurezza dei carichi di lavoro del tenant. conformità fips garantisce l'uso di moduli crittografici convalidati per la crittografia, l'hashing e altre operazioni correlate alla sicurezza. Con i pool di nodi del servizio Azure Kubernetes abilitati per FIPS, è possibile soddisfare i requisiti normativi e di conformità del settore usando algoritmi e meccanismi crittografici affidabili. Azure fornisce la documentazione su come abilitare FIPS per i pool di nodi del servizio Azure Kubernetes, che consente di rafforzare il comportamento di sicurezza degli ambienti del servizio Azure Kubernetes multi-tenant. Per altre informazioni, vedere Abilitare FIPS per i pool di nodi del servizio Azure Kubernetes.

Crittografia basata su host

Nel servizio Azure Kubernetes l'architettura potrebbe aver usato le funzionalità seguenti per migliorare la sicurezza dei dati:

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, il servizio Azure Kubernetes crittografa i dati inattivi nei computer host sottostanti, assicurandosi che le informazioni riservate del tenant siano protette da accessi non autorizzati. I dischi temporanei e i dischi temporanei del sistema operativo vengono crittografati inattivi con chiavi gestite dalla piattaforma quando si abilita la crittografia end-to-end.

Nel servizio Azure Kubernetes, il sistema operativo e i dischi dati usano la crittografia lato server con chiavi gestite dalla piattaforma per impostazione predefinita. Le cache per questi dischi vengono crittografate inattive con chiavi gestite dalla piattaforma. È possibile specificare la propria chiave di crittografia della chiave di per crittografare la chiave di protezione dei dati usando la crittografia envelope, nota anche come wrapping . La cache per il sistema operativo e i dischi dati viene crittografata anche tramite il BYOK specificato.

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

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 rimozione delle autorizzazioni dell'hardware. Per altre informazioni sull'aggiornamento delle macchine virtuali di Azure, 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 interessano le macchine virtuali ospitate, Azure riduce al minimo i casi che richiedono riavvii sospendo la macchina virtuale durante l'aggiornamento dell'host o eseguendo 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 in modo da poter avviare l'aggiornamento quando funziona automaticamente. La finestra di manutenzione automatica per i computer host è in genere di 35 giorni, a meno che l'aggiornamento non sia urgente.

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

Aggiornamenti di Kubernetes

Parte del ciclo di vita del cluster del servizio Azure Kubernetes esegue periodicamente l'aggiornamento alla versione più recente di Kubernetes. È importante 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, il servizio Azure Kubernetes configura gli aggiornamenti per l'aumento con un nodo aggiuntivo. Un valore predefinito di uno per le impostazioni riduce al minimo l'interruzione del max-surge carico di lavoro creando un nodo aggiuntivo per sostituire i nodi con controllo delle versioni precedenti prima di completare o svuotare le applicazioni esistenti. È possibile personalizzare il max-surge valore per ogni pool di nodi per consentire un compromesso tra la velocità di aggiornamento e l'interruzione dell'aggiornamento. L'aumento del max-surge valore completa il processo di aggiornamento più velocemente, ma un valore elevato per max-surge potrebbe causare interruzioni durante il processo di aggiornamento.

Ad esempio, un max-surge valore pari al 100% fornisce il processo di aggiornamento più rapido possibile raddoppiando il numero di nodi, ma comporta anche lo svuotamento simultaneo di tutti i nodi nel pool di nodi. È possibile usare questo valore elevato per i test, ma per i pool di nodi di produzione, un'impostazione max-surge del 33% è migliore.

Il servizio Azure Kubernetes accetta valori interi e percentuali per max-surge. Un numero intero, ad 5 esempio, indica cinque nodi aggiuntivi da aumentare. I valori di percentuale per max-surge possono essere minimo 1% e massimo di , arrotondati fino al numero di 100%nodi più vicino. Un valore di 50% indica un valore di aumento della metà del numero di nodi corrente nel pool.

Durante un aggiornamento, il max-surge valore può essere minimo 1 e un valore massimo uguale al numero di nodi nel pool di nodi. È possibile impostare valori maggiori, ma il numero massimo di nodi usati per max-surge non sarà maggiore del numero di nodi nel pool.

Importante

Per le operazioni di aggiornamento, i picchi di nodo richiedono una quota di sottoscrizione sufficiente per il conteggio richiesto max-surge . Ad esempio, un cluster con cinque pool di nodi, ognuno con quattro nodi, ha un totale di 20 nodi. Se ogni pool di nodi ha un max-surge valore pari al 50%, per completare l'aggiornamento è necessario un calcolo aggiuntivo e una quota IP di 10 nodi o due volte cinque pool.

Se si usa Azure Container Networking Interface (CNI), assicurarsi anche di disporre di indirizzi IP sufficienti nella subnet per soddisfare i requisiti CNI per il servizio Azure Kubernetes.

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>

Il comando seguente usa az aks nodepool upgrade per aggiornare un singolo pool di nodi.

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

Per altre informazioni su come aggiornare la versione di Kubernetes per un piano di controllo del cluster e i pool di nodi, vedere:

Considerazioni sull'aggiornamento

Si notino queste procedure consigliate e considerazioni per l'aggiornamento della versione di Kubernetes in un cluster del servizio Azure Kubernetes.

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

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

  • Il az aks upgrade comando con il --control-plane-only flag aggiorna solo il piano di controllo del cluster e non modifica alcun pool di nodi associato 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 potrebbe non riuscire. Per altre informazioni sull'aumento della quota, vedere Aumentare le quote di vCPU a livello di area.

  • Configurare il max-surge parametro in base alle esigenze, usando un numero intero o un valore 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 del servizio Azure Kubernetes che usa la rete CNI, assicurarsi che la subnet disponga di indirizzi IP privati sufficienti per i nodi aggiuntivi creati dalle max-surge impostazioni. Per altre informazioni, vedere Configurare la rete CNI di Azure nel servizio Azure Kubernetes.

  • Se i pool di nodi del cluster si estendono su più zone di disponibilità all'interno di un'area, il processo di aggiornamento può causare temporaneamente una configurazione della zona sbilanciata. Per altre informazioni, vedere Considerazioni speciali per i pool di nodi che si estendono su più zone di disponibilità.

Collaboratori

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

Autori principali:

Altri contributori:

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

Passaggi successivi