**Contribuisci a migliorare questa pagina** 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti
<a name="managed-node-groups"></a>

I gruppi di nodi gestiti di Amazon EKS automatizzano il provisioning e la gestione del ciclo di vita dei nodi ( EC2 istanze Amazon) per i cluster Amazon EKS Kubernetes.

Con i gruppi di nodi gestiti di Amazon EKS, non è necessario effettuare il provisioning o registrare separatamente EC2 le istanze Amazon che forniscono capacità di calcolo per eseguire le applicazioni Kubernetes. È possibile creare, aggiornare o terminare automaticamente i nodi per il cluster con una singola operazione. Gli aggiornamenti e le interruzioni dei nodi svuotano automaticamente i nodi per garantire che le applicazioni rimangano disponibili.

Ogni nodo gestito viene fornito come parte di un gruppo Amazon EC2 Auto Scaling gestito per te da Amazon EKS. Ogni risorsa, incluse le istanze e i gruppi Auto Scaling, viene eseguita all'interno AWS del tuo account. Ogni gruppo di nodi viene eseguito su più zone di disponibilità definite.

I gruppi di nodi gestiti possono anche sfruttare opzionalmente la riparazione automatica, che monitora continuamente lo stato di integrità dei nodi. In pratica, reagisce automaticamente ai problemi rilevati e sostituisce i nodi quando possibile. Ciò aiuta la disponibilità complessiva del cluster con un intervento manuale minimo. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).

Puoi aggiungere un gruppo di nodi gestiti a cluster nuovi o esistenti utilizzando la console Amazon EKS, la AWS CLI `eksctl` AWS , l'API o l'infrastruttura come strumenti di codice, tra cui. AWS CloudFormation I nodi avviati come parte di un gruppo di nodi gestiti vengono automaticamente taggati per l’individuazione automatica tramite [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes. É possibile utilizzare il gruppo di nodi per applicare le etichette Kubernetes ai nodi e aggiornarle in qualsiasi momento.

Non ci sono costi aggiuntivi per l'utilizzo dei gruppi di nodi gestiti di Amazon EKS, paghi solo per le AWS risorse fornite. Questi includono EC2 istanze Amazon, volumi Amazon EBS, orari dei cluster Amazon EKS e qualsiasi altra AWS infrastruttura. Non sono previste tariffe minime né impegni anticipati.

Per iniziare a utilizzare un nuovo cluster Amazon EKS e un gruppo di nodi gestiti, vedi [Inizia a usare Amazon EKS Console di gestione AWS e AWS CLI](getting-started-console.md).

Per aggiungere un gruppo di nodi gestiti a un cluster esistente, vedi [Creare un gruppo di nodi gestiti per il cluster](create-managed-node-group.md).

## Concetti sui gruppi di nodi gestiti
<a name="managed-node-group-concepts"></a>
+ I gruppi di nodi gestiti di Amazon EKS creano e gestiscono EC2 istanze Amazon per te.
+ Ogni nodo gestito viene fornito come parte di un gruppo Amazon EC2 Auto Scaling gestito per te da Amazon EKS. Inoltre, tutte le risorse, incluse EC2 le istanze Amazon e i gruppi di Auto Scaling, vengono eseguite all'interno AWS del tuo account.
+ Il gruppo Auto Scaling di un gruppo di nodi gestiti si estende su ogni sottorete specificata al momento della creazione del gruppo.
+ Amazon EKS applica tag alle risorse del gruppo di nodi gestiti in modo che siano configurate per utilizzare [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes.
**Importante**  
Se si esegue un’applicazione stateful in più zone di disponibilità supportate dai volumi Amazon EBS e che utilizza il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes, è necessario configurare più gruppi di nodi, ognuno dei quali definito per una singola zona di disponibilità. Inoltre, è necessario abilitare la funzionalità `--balance-similar-node-groups`.
+ È possibile utilizzare un modello di avvio personalizzato per un maggiore livello di flessibilità e personalizzazione durante l’implementazione dei nodi gestiti. Ad esempio, è possibile specificare argomenti `kubelet` aggiuntivi e utilizzare un’AMI personalizzata. Per ulteriori informazioni, consulta [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md). Se non si utilizza un modello di avvio personalizzato quando si crea per la prima volta un gruppo di nodi gestiti, è disponibile un modello di avvio generato automaticamente. Non modificare manualmente questo modello generato automaticamente o si verificheranno errori.
+ Amazon EKS segue il modello di responsabilità condivisa CVEs e le patch di sicurezza sui gruppi di nodi gestiti. Quando i nodi gestiti eseguono un’AMI ottimizzata per Amazon EKS, Amazon EKS è responsabile della creazione di versioni con patch dell’AMI quando vengono segnalati bug o problemi. A questo scopo vengono pubblicate delle correzioni. Sei invece responsabile della distribuzione di queste versioni AMI con patch ai gruppi di nodi gestiti. Quando i nodi gestiti eseguono un’AMI personalizzata, sei responsabile della creazione di versioni con patch dell’AMI quando vengono segnalati bug o problemi, oltre che della distribuzione dell’AMI. Per ulteriori informazioni, consulta [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md).
+ I gruppi di nodi gestiti Amazon EKS possono essere avviati in sottoreti pubbliche e private. Se si avvia un gruppo di nodi gestiti in una sottorete pubblica in data 22 aprile 2020 o successiva, sarà necessario che la sottorete abbia `MapPublicIpOnLaunch` impostato su vero affinché le istanze possano partecipare correttamente a un cluster. Se la sottorete pubblica è stata creata utilizzando `eksctl` o i [AWS CloudFormation modelli forniti da Amazon EKS](creating-a-vpc.md) a partire dal 26 marzo 2020, questa impostazione è già impostata su true. Se le sottoreti pubbliche sono state create prima del 26 marzo 2020 devi modificare manualmente l’impostazione. Per ulteriori informazioni, consulta [Modifica dell'attributo di IPv4 indirizzamento pubblico per la](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) sottorete.
+ Quando implementi un gruppo di nodi gestito in sottoreti private, devi assicurarti che possa accedere ad Amazon ECR per estrarre le immagini dei container. È possibile farlo collegando un gateway NAT alla tabella di routing della sottorete o aggiungendo i seguenti [endpoint VPC AWS PrivateLink ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create):
  + Interfaccia endpoint dell'API di Amazon ECR: `com.amazonaws.region-code.ecr.api` 
  + Interfaccia endpoint dell’API del registro Docker di Amazon ECR: `com.amazonaws.region-code.ecr.dkr` 
  + Endpoint del gateway Amazon S3: `com.amazonaws.region-code.s3` 

  Per altri servizi ed endpoint di uso comune, consulta la sezione [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md).
+ I gruppi di nodi gestiti non possono essere distribuiti su [AWS Outposts](eks-outposts.md) o in [AWS Wavelength](https://docs.aws.amazon.com/wavelength/). È possibile creare gruppi di nodi gestiti in [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Per ulteriori informazioni, consulta [Avvia cluster EKS a bassa latenza con AWS Local Zones](local-zones.md).
+ È possibile creare più gruppi di nodi gestiti all’interno di un singolo cluster. Ad esempio, puoi creare un gruppo di nodi con l’AMI Linux standard ottimizzata per Amazon EKS per alcuni carichi di lavoro e un altro gruppo con la variante GPU per i carichi di lavoro che richiedono il supporto della GPU.
+ Se il tuo gruppo di nodi gestiti rileva un errore di [controllo dello stato delle EC2 istanze Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html), Amazon EKS restituisce un codice di errore per aiutarti a diagnosticare il problema. Per ulteriori informazioni, consulta [Codici di errore dei gruppi di nodi gestiti](troubleshooting.md#troubleshoot-managed-node-groups).
+ Amazon EKS aggiunge etichette Kubernetes alle istanze del gruppo di nodi gestiti. Queste etichette fornite da Amazon EKS hanno il prefisso `eks.amazonaws.com`.
+ Amazon EKS svuota automaticamente i nodi utilizzando l’API Kubernetes durante le interruzioni o gli aggiornamenti.
+ I budget di interruzione del pod non vengono rispettati quando si termina un nodo con `AZRebalance` o si riduce il numero di nodi desiderato. Queste operazioni cercano di espellere pod dal nodo. Tuttavia, se trascorrono più di 15 minuti, il nodo viene terminato a prescindere dal fatto che tutti i pod sul nodo siano stati terminati. Per prolungare il periodo fino alla terminazione del nodo, aggiungi un hook del ciclo di vita al gruppo con scalabilità automatica. Per ulteriori informazioni, consulta [Add lifecycle hook](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html) nella Amazon * EC2 Auto Scaling* User Guide.
+ Per eseguire correttamente il processo di scarico dopo aver ricevuto una notifica di interruzione spot o una notifica di ribilanciamento della capacità, `CapacityRebalance` deve essere impostato su `true`.
+ L’aggiornamento di gruppi di nodi gestiti rispettano i budget di interruzione dei pod impostati per i pod. Per ulteriori informazioni, consulta [Comprendi ogni fase degli aggiornamenti dei nodi](managed-node-update-behavior.md).
+ I gruppi di nodi gestiti Amazon EKS non prevedono costi aggiuntivi. Paghi solo per le AWS risorse che fornisci.
+ Se si desidera crittografare i volumi Amazon EBS per i nodi, è possibile implementare i nodi utilizzando un modello di avvio. Per implementare nodi gestiti con volumi Amazon EBS crittografati senza utilizzare un modello di avvio, crittografare tutti i nuovi volumi Amazon EBS creati nell’account. Per ulteriori informazioni, consulta [Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) nella *Amazon EC2 User Guide*.

## Tipi di capacità del gruppo di nodi gestiti
<a name="managed-node-group-capacity-types"></a>

Quando si crea un gruppo di nodi gestito, è possibile scegliere il tipo di capacità su on demand o Spot. Amazon EKS implementa un gruppo di nodi gestiti con un gruppo Amazon EC2 Auto Scaling che contiene solo istanze On-Demand o solo istanze Amazon EC2 Spot. All’interno di un singolo cluster Kubernetes, è possibile pianificare i pod per le applicazioni tolleranti ai guasti sia per i gruppi di nodi gestiti Spot che per i gruppi di nodi on-demand. Per impostazione predefinita, un gruppo di nodi gestiti distribuisce istanze Amazon EC2 On-Demand.

### On demand
<a name="managed-node-group-capacity-types-on-demand"></a>

Con Istanze on demand, sono previsti costi per la capacità di calcolo entro la seconda ora senza impegni a lungo termine.

Per impostazione predefinita, se non specifichi un **Tipo capacità**, per il gruppo di nodi gestiti viene eseguito il provisioning con Istanze on demand. Un gruppo di nodi gestito configura un gruppo Amazon EC2 Auto Scaling per tuo conto con le seguenti impostazioni applicate:
+ La strategia di allocazione per il provisioning della capacità On-Demand è impostata su `prioritized`. Il gruppo di nodi gestiti utilizza l’ordine dei tipi di istanze approvata dall’API per determinare quale tipo di istanza utilizzare prima per soddisfare la capacità on demand. Ad esempio, è possibile specificare tre tipi di istanza nell’ordine seguente: `c5.large`, `c4.large`, e `c3.large`. Quando le istanze on demand vengono avviate, il gruppo di nodi gestiti soddisfa la capacità on demand a partire da `c5.large`, quindi `c4.large`, e infine `c3.large`. Per ulteriori informazioni, consulta il [gruppo Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) nella *Amazon Auto EC2 Scaling User Guide*.
+ Amazon EKS aggiunge la seguente etichetta Kubernetes a tutti i nodi del gruppo di nodi gestito che specifica il tipo di capacità: `eks.amazonaws.com/capacityType: ON_DEMAND`. È possibile utilizzare questa etichetta sui nodi on demand per pianificare applicazioni con stato o fault intolerant.

### Spot
<a name="managed-node-group-capacity-types-spot"></a>

Le istanze Amazon EC2 Spot sono una EC2 capacità Amazon inutilizzata che offre forti sconti sui prezzi On-Demand. Le istanze Amazon EC2 Spot possono essere interrotte con un avviso di interruzione di due minuti quando è EC2 necessario ripristinare la capacità. Per ulteriori informazioni, consulta le [istanze Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) nella *Amazon EC2 User Guide*. Puoi configurare un gruppo di nodi gestiti con Amazon EC2 Spot Instances per ottimizzare i costi per i nodi di calcolo in esecuzione nel tuo cluster Amazon EKS.

Per utilizzare istanze spot all’interno di un gruppo di nodi gestiti, creare un gruppo di nodi gestiti impostando il tipo di capacità come `spot`. Un gruppo di nodi gestito configura un gruppo Amazon EC2 Auto Scaling per tuo conto applicando le seguenti best practice Spot:
+ Per garantire che il provisioning dei nodi Spot venga eseguito nei pool di capacità Spot ottimali, la strategia di allocazione è impostata su uno dei seguenti valori:
  +  `price-capacity-optimized` (PCO): quando si creano nuovi gruppi di nodi in un cluster con Kubernetes versione `1.28` o successive, la strategia di allocazione è impostata su `price-capacity-optimized`. Tuttavia, la strategia di allocazione non viene modificata per i gruppi di nodi già creati con `capacity-optimized` prima che i gruppi di nodi gestiti da Amazon EKS inizino a supportare PCO.
  +  `capacity-optimized` (CO): quando si creano nuovi gruppi di nodi in un cluster con Kubernetes versione `1.27` o precedenti, la strategia di allocazione è impostata su `capacity-optimized`.

  Per aumentare il numero di pool di capacità Spot disponibili da cui allocare le capacità, configurare un gruppo di nodi gestiti per l’utilizzo di più tipi di istanza.
+ Amazon EC2 Spot Capacity Rebalancing è abilitato in modo che Amazon EKS possa drenare e ribilanciare in modo corretto i nodi Spot per ridurre al minimo l'interruzione delle applicazioni quando un nodo Spot è a elevato rischio di interruzione. Per ulteriori informazioni, consulta [Amazon EC2 Auto Scaling Capacity Rebalancing nella](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) Amazon Auto *Scaling EC2 * User Guide.
  + Quando un nodo Spot riceve un consiglio di ribilanciamento, Amazon EKS tenta automaticamente di avviare un nuovo nodo Spot sostitutivo.
  + Se un avviso di interruzione Spot di due minuti arriva prima che il nodo Spot sostitutivo si trovi in uno stato `Ready`, Amazon EKS inizia a svuotare il nodo Spot che ha ricevuto il suggerimento di ribilanciamento. Amazon EKS svuota il nodo nel modo migliore possibile. Di conseguenza, non c’è alcuna garanzia che Amazon EKS attenda che il nodo sostitutivo si unisca al cluster prima di svuotare il nodo esistente.
  + Quando un nodo Spot sostitutivo viene avviato ed è allo stato `Ready` su Kubernetes, Amazon EKS isola e svuota il nodo Spot che ha ricevuto il suggerimento di ribilanciamento. L’isolamento del nodo Spot assicura che il controller di servizio non invii nuove richieste a questo nodo Spot. Il nodo viene rimosso anche dall’elenco di nodi Spot sani e attivi. Lo svuotamento del nodo Spot assicura che i pod in esecuzione vengano espulsi in modo corretto.
+ Amazon EKS aggiunge la seguente etichetta Kubernetes a tutti i nodi del gruppo di nodi gestito che specifica il tipo di capacità: `eks.amazonaws.com/capacityType: SPOT`. È possibile utilizzare questa etichetta per pianificare applicazioni fault tolerant sui nodi Spot.
**Importante**  
EC2 emette un [avviso di interruzione Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) due minuti prima della chiusura dell'istanza Spot. Tuttavia, i Pod sui nodi Spot potrebbero non ricevere l'intera finestra di 2 minuti necessaria per uno spegnimento regolare. Quando EC2 emette l'avviso, c'è un ritardo prima che Amazon EKS inizi a sfrattare i Pods. Gli sfratti avvengono in sequenza per proteggere il server dell'API Kubernetes, quindi durante più reclami Spot simultanei, alcuni Pod potrebbero ricevere avvisi di sfratto ritardato. I Pod possono essere chiusi forzatamente senza ricevere segnali di terminazione, in particolare su nodi ad alta densità di Pod, durante reclami simultanei o quando si utilizzano periodi di tolleranza di terminazione prolungati. Per i carichi di lavoro Spot, consigliamo di progettare le applicazioni in modo da tollerare le interruzioni, utilizzando periodi di tolleranza di terminazione pari o inferiori a 30 secondi, evitando agganci PreStop di lunga durata e monitorando le metriche di sfratto dei Pod per comprendere i periodi di tolleranza effettivi nei cluster. Per i carichi di lavoro che richiedono una terminazione corretta e garantita, consigliamo invece di utilizzare la capacità On-Demand.

Quando si decide se implementare un gruppo di nodi con capacità On-Demand o Spot, è necessario considerare le seguenti condizioni:
+ Le istanze Spot sono consigliate per applicazioni senza stato, fault tolerant e flessibili. Questi includono carichi di lavoro di formazione in batch e machine learning, big data ETLs come Apache Spark, applicazioni di elaborazione delle code ed endpoint API stateless. Poiché Spot è una EC2 capacità Amazon inutilizzata, che può cambiare nel tempo, ti consigliamo di utilizzare la capacità Spot per carichi di lavoro tolleranti alle interruzioni. Più specificamente, la capacità Spot è adatta per carichi di lavoro in grado di tollerare periodi in cui la capacità richiesta non è disponibile.
+ Consigliamo di utilizzare On-demand per le applicazioni che sono fault intolerant. Ciò include strumenti di gestione dei cluster come strumenti di monitoraggio e operativi, implementazioni che richiedono `StatefulSets` e applicazioni con stato, come database.
+ Per ottimizzare la disponibilità delle applicazioni durante l’utilizzo di istanze Spot, è consigliabile configurare un gruppo di nodi gestiti Spot per l’utilizzo di più tipi di istanza. Quando si utilizzano più tipi di istanza, si consiglia di applicare le seguenti regole:
  + All’interno di un gruppo di nodi gestiti, se utilizzi [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), ti consigliamo di utilizzare un set flessibile di tipi di istanza con la stessa quantità di vCPU e risorse di memoria. Questo per garantire che i nodi del cluster vengano dimensionati come previsto. Ad esempio, se hai bisogno di quattro v CPUs e otto GiB di memoria,,`c3.xlarge`,`c4.xlarge`, `c5.xlarge` `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, o altri tipi di istanza simili.
  + Per migliorare la disponibilità delle applicazioni, si consiglia di implementare più gruppi di nodi gestiti Spot. Per questo, ogni gruppo dovrebbe utilizzare un set flessibile di tipi di istanza con le stesse risorse vCPU e memoria. Ad esempio, se hai bisogno di memoria 4 v CPUs e 8 GiB, ti consigliamo di creare un gruppo di nodi gestiti con`c3.xlarge`,,,`c4.xlarge`, `c5.xlarge` `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, o altri tipi di istanze simili e un secondo gruppo di nodi gestiti con`m3.xlarge`,,, `m4.xlarge` `m5.xlarge` `m5d.xlarge``m5a.xlarge`, `m5n.xlarge` o altri tipi di istanze simili.
  + Quando si implementa il gruppo di nodi con il tipo di capacità Spot che utilizza un modello di avvio personalizzato, utilizza l’API per passare più tipi di istanza. Non passare un singolo tipo di istanza tramite il modello di avvio. Per ulteriori informazioni sull’implementazione di un gruppo di nodi tramite un modello di avvio, vedere [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md).

# Creare un gruppo di nodi gestiti per il cluster
<a name="create-managed-node-group"></a>

In questo argomento viene descritto come avviare gruppi di nodi gestiti Amazon EKS per nodi che si registrano con il cluster Amazon EKS. Dopo che i nodi vengono aggiunti al cluster, puoi implementare applicazioni Kubernetes per gli stessi.

Se si avvia un gruppo di nodi gestiti Amazon EKS per la prima volta, consigliamo invece di seguire una delle nostre guide in [Nozioni di base su Amazon EKS](getting-started.md). Queste guide forniscono procedure dettagliate per la creazione di un cluster Amazon EKS con nodi.

**Importante**  
I nodi Amazon EKS sono istanze Amazon EC2 standard. La fatturazione viene effettuata in base ai normali prezzi Amazon EC2. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Non puoi creare nodi gestiti in una AWS regione in cui AWS Outposts o Wavelength AWS sono abilitati. È possibile, invece creare nodi autogestiti. Per ulteriori informazioni, consultare [Crea nodi Amazon Linux autogestiti](launch-workers.md), [Crea nodi Microsoft Windows autogestiti](launch-windows-workers.md) e [Crea nodi autogestiti Bottlerocket](launch-node-bottlerocket.md). Puoi anche creare un gruppo di nodi Amazon Linux autogestito su un Outpost. Per ulteriori informazioni, consulta [Crea nodi Amazon Linux su AWS Outposts](eks-outposts-self-managed-nodes.md).
Se non si [specifica un ID AMI](launch-templates.md#launch-template-custom-ami) per il file `bootstrap.sh` incluso in Linux o Bottlerocket ottimizzato per Amazon EKS, i gruppi di nodi gestiti impongono un numero massimo sul valore di `maxPods`. Per le istanze con meno di 30 vCPUs, il numero massimo è. `110` Per le istanze con più di 30 vCPUs, il numero massimo salta a. `250` Questa applicazione ha la precedenza su altre `maxPods` configurazioni, tra cui. `maxPodsExpression` Per ulteriori informazioni su come `maxPods` viene determinato e su come personalizzarlo, vedere. [Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence)
+ Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Crea un cluster Amazon EKS.](create-cluster.md).
+ Un ruolo IAM esistente per i nodi da utilizzare. Per crearne uno, consulta [Ruolo IAM del nodo Amazon EKS](create-node-role.md). Se questo ruolo non prevede nessuna delle policy per VPC CNI, per i pod VPC CNI è necessario il ruolo separato riportato di seguito.
+ (Facoltativo, ma consigliato) Il componente aggiuntivo plug-in CNI di Amazon VPC per Kubernetes configurato con il proprio ruolo IAM a cui è allegata la policy IAM necessaria. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
+ Familiarità con le considerazioni presenti alla pagina [Choose an optimal Amazon EC2 node instance type](choosing-instance-type.md). A seconda del tipo di istanza scelto, potrebbero esserci ulteriori prerequisiti per il cluster e il VPC.
+ Per aggiungere un gruppo di nodi gestiti da Windows, è prima necessario abilitare il supporto Windows per il cluster. Per ulteriori informazioni, consulta [Implementazione dei nodi Windows su cluster EKS](windows-support.md).

È possibile creare un gruppo di nodi gestito con uno di questi due strumenti:
+  [`eksctl`](#eksctl_create_managed_nodegroup) 
+  [Console di gestione AWS](#console_create_managed_nodegroup) 

## `eksctl`
<a name="eksctl_create_managed_nodegroup"></a>

 **Creare un gruppo di nodi gestito con eksctl** 

Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente:

```
eksctl version
```

Per istruzioni sull’installazione o sull’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.

1. (Facoltativo) Se la policy IAM gestita **AmazonEKS\$1CNI\$1Policy** è collegata al [ruolo IAM del nodo Amazon EKS](create-node-role.md), si consiglia, invece, di assegnarla a un ruolo IAM associato all’account di servizio Kubernetes `aws-node`. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).

1. Creare un gruppo di nodi gestiti con o senza utilizzare un modello di avvio personalizzato. La specifica manuale di un modello di avvio consente una maggiore personalizzazione di un gruppo di nodi. Ad esempio, può consentire l'implementazione di un'AMI personalizzata o la presenza di argomenti sullo script `boostrap.sh` in un'AMI ottimizzata per Amazon EKS. Per avere un elenco completo di tutte le opzioni e le impostazioni predefinite disponibili, inserisci il comando seguente.

   ```
   eksctl create nodegroup --help
   ```

   Nel comando seguente, sostituisci *my-cluster* con il nome del tuo cluster e sostituisci *my-mng* con il nome del gruppo di nodi. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.
**Importante**  
Se non si utilizza un modello di avvio personalizzato durante la prima creazione di un gruppo di nodi gestiti, non utilizzarne uno per il gruppo di nodi in un secondo momento. Se non è stato specificato un modello di avvio personalizzato, il sistema genera automaticamente un modello di avvio che non è consigliabile modificare manualmente. La modifica manuale di questo modello di avvio generato in automatico potrebbe causare errori.

 **Senza un modello di avvio** 

 `eksctl` crea un modello di avvio Amazon EC2 predefinito nell'account e implementa il gruppo di nodi utilizzando un modello di avvio creato in base alle opzioni specificate. Prima di specificare un valore per `--node-type`, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md).

Sostituisci *ami-family* con una parola chiave consentita. Per ulteriori informazioni, consulta [Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) (Impostazione della famiglia AMI dei nodi) nella documentazione di `eksctl`. Sostituisci *my-key* con il nome della coppia di chiavi Amazon EC2 o della chiave pubblica. Questa chiave viene utilizzata per eseguire il SSH nei nodi dopo il loro avvio.

**Nota**  
Per Windows, questo comando non abilita SSH. Associa, invece, la coppia di chiavi Amazon EC2 all'istanza e ti consente di eseguire il protocollo RDP nell'istanza.

Se non si dispone di una coppia di chiavi Amazon EC2, è possibile crearla nella Console di gestione AWS. Per informazioni su Linux, consultare [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Per informazioni su Windows, consultare [Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*.

Consigliamo di bloccare l’accesso dei pod a IMDS se si verificano le seguenti condizioni:
+ Prevedi di assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie.
+ Nessun pod nel cluster richiede l'accesso al servizio di metadati dell'istanza Amazon EC2 (IMDS) per altri motivi, come il recupero della regione corrente. AWS 

Per ulteriori informazioni, consulta [Limita l'accesso al profilo dell'istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

Se si desidera bloccare l’accesso del pod a IMDS, aggiungere l’opzione `--disable-pod-imds` al seguente comando.

```
eksctl create nodegroup \
  --cluster my-cluster \
  --region region-code \
  --name my-mng \
  --node-ami-family ami-family \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 4 \
  --ssh-access \
  --ssh-public-key my-key
```

Le istanze possono opzionalmente assegnare un numero di indirizzi IP significativamente superiore ai pod, assegnare indirizzi IP ai pod da un intervallo CIDR diverso da quello dell’istanza ed essere distribuite in un cluster senza accesso a Internet. Per ulteriori informazioni, consultare [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md), [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md), e [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md) per ulteriori opzioni da aggiungere al comando precedente.

I gruppi di nodi gestiti calcolano e applicano un singolo valore per il numero massimo di pod che possono essere eseguiti su ogni nodo del gruppo in base al tipo di istanza. Se si crea un gruppo di nodi con tipi di istanza diversi, il valore più piccolo calcolato in tutti i tipi di istanza viene applicato come numero massimo di pod che possono essere eseguiti su ogni tipo di istanza nel gruppo di nodi. I gruppi di nodi gestiti calcolano il valore utilizzando lo script a cui si fa riferimento nella pagina .

 **Con un modello di lancio** 

Il modello di avvio deve esistere già e deve soddisfare i requisiti specificati nella pagina [Launch template configuration basics](launch-templates.md#launch-template-basics). Consigliamo di bloccare l’accesso dei pod a IMDS se si verificano le seguenti condizioni:
+ Prevedi di assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie.
+ Nessun pod nel cluster richiede l'accesso al servizio di metadati dell'istanza Amazon EC2 (IMDS) per altri motivi, come il recupero della regione corrente. AWS 

Per ulteriori informazioni, consulta [Limita l'accesso al profilo dell'istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

Se si desidera bloccare l’accesso del pod a IMDS, specificare le impostazioni necessarie nel modello di avvio.

1. Copia i seguenti contenuti sul dispositivo. Sostituisci i valori di esempio e quindi esegui il comando modificato per creare il file. `eks-nodegroup.yaml` Diverse impostazioni specificate durante l'implementazione senza un modello di avvio vengono spostate nel modello di avvio. Se non si specifica una `version`, viene utilizzata la versione predefinita del modello.

   ```
   cat >eks-nodegroup.yaml <<EOF
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   metadata:
     name: my-cluster
     region: region-code
   managedNodeGroups:
   - name: my-mng
     launchTemplate:
       id: lt-id
       version: "1"
   EOF
   ```

   Per un elenco completo delle impostazioni del file di configurazione `eksctl`, consulta [Schema dei file config](https://eksctl.io/usage/schema/) nella documentazione di `eksctl`. Le istanze possono opzionalmente assegnare un numero di indirizzi IP significativamente superiore ai pod, assegnare indirizzi IP ai pod da un intervallo CIDR diverso da quello dell’istanza ed essere implementate in un cluster senza accesso a Internet in uscita. Per ulteriori informazioni, consultare [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md), [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md), e [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md) per altre opzioni da aggiungere al file di configurazione.

   Se non è stato specificato un ID AMI nel modello di avvio, i gruppi di nodi gestiti calcolano e applicano un singolo valore per il numero massimo di pod che possono essere eseguiti su ogni nodo del gruppo in base al tipo di istanza. Se si crea un gruppo di nodi con tipi di istanza diversi, il valore più piccolo calcolato in tutti i tipi di istanza viene applicato come numero massimo di pod che possono essere eseguiti su ogni tipo di istanza nel gruppo di nodi. I gruppi di nodi gestiti calcolano il valore utilizzando lo script a cui si fa riferimento nella pagina .

   Se nel modello di avvio è stato specificato un ID AMI, specificare il numero massimo di pod che possono essere eseguiti su ciascun nodo del gruppo se si utilizza una [rete personalizzata](cni-custom-network.md) o se si vuole [aumentare il numero di indirizzi IP assegnati all’istanza](cni-increase-ip-addresses.md). Per ulteriori informazioni, consulta .

1. Implementare il gruppo di nodi mediante il comando seguente.

   ```
   eksctl create nodegroup --config-file eks-nodegroup.yaml
   ```

## Console di gestione AWS
<a name="console_create_managed_nodegroup"></a>

 **Creare un gruppo di nodi gestiti utilizzando la Console di gestione AWS ** 

1. Attendi che lo stato del cluster risulti `ACTIVE`. Non è possibile creare un gruppo di nodi gestiti per un cluster non ancora `ACTIVE`.

1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Scegli il nome del cluster in cui desideri creare un gruppo di nodi gestiti.

1. Seleziona la scheda **Compute** (Calcolo).

1. Scegli **Add node group** (Aggiungi gruppo di nodi).

1. Nella pagina **Configura il gruppo di nodi**, compila i parametri di conseguenza e quindi scegli **Successivo**.
   +  **Nome**: inserisci un nome univoco per il gruppo di nodi gestiti. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.
   +  **Ruolo IAM del nodo**: scegli il ruolo dell'istanza del nodo da utilizzare con il gruppo di nodi. Per ulteriori informazioni, consulta [Ruolo IAM del nodo Amazon EKS](create-node-role.md).
**Importante**  
Non è possibile usare lo stesso ruolo utilizzato per creare i cluster.
Consigliamo di utilizzare un ruolo che non è attualmente in uso da alcun gruppo di nodi autogestiti. In caso contrario, prevedi l'utilizzo di un nuovo gruppo di nodi autogestiti. Per ulteriori informazioni, consulta [Eliminare un gruppo di nodi gestito dal cluster](delete-managed-node-group.md).
   +  **Usa modello di avvio** (Facoltativo): scegli se desideri utilizzare un modello di avvio esistente. Seleziona un **Launch Template Name** (Nome del modello di avvio). Quindi, seleziona una **Launch template version** (Versione del modello di avvio). Se non si seleziona una versione, Amazon EKS utilizza la versione predefinita del modello. I modelli di avvio permettono una maggiore personalizzazione del gruppo di nodi, ad esempio consentendo di implementare un’AMI personalizzata, assegnare un numero significativamente superiore di indirizzi IP ai pod, assegnare indirizzi IP ai pod da un intervallo CIDR diverso da quello dell’istanza e implementare i nodi in un cluster senza accesso a Internet in uscita. Per ulteriori informazioni, consultare [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md), [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md) e [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md).

     Il modello di avvio deve soddisfare i requisiti descritti nella pagina [Customize managed nodes with launch templates](launch-templates.md). Se non si utilizza il proprio modello, l’API di Amazon EKS crea un modello di avvio Amazon EC2 predefinito nell’account e implementa il gruppo di nodi utilizzando il modello di avvio predefinito.

     Se implementate [i ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md), assegnate le autorizzazioni necessarie direttamente a ogni Pod che richiede l'accesso ai AWS servizi e nessun Pod del cluster richiede l'accesso a IMDS per altri motivi, come il recupero della AWS regione corrente, allora potete anche disabilitare l'accesso a IMDS per i Pod che non utilizzano la rete host in un modello di lancio. Per ulteriori informazioni, consulta [Limita l'accesso al profilo dell'istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
   +  **Etichette Kubernetes** – (Facoltativo) È possibile scegliere di applicare etichette Kubernetes ai nodi del gruppo di nodi gestiti.
   +  **Taint Kubernetes**: (facoltativo) è possibile scegliere di applicare i taint Kubernetes ai nodi del gruppo di nodi gestiti. Nel menu **Effetto** sono disponibili le opzioni ` NoSchedule `, ` NoExecute ` e ` PreferNoSchedule `. Per ulteriori informazioni, consulta [Ricetta: impedire che i pod siano programmati su nodi specifici](node-taints-managed-node-groups.md).
   +  **Tag**: (facoltativo) è possibile scegliere di aggiungere tag al gruppo di nodi gestiti Amazon EKS. Questi tag non si propagano ad altre risorse del gruppo di nodi, ad esempio gruppi Auto Scaling o istanze. Per ulteriori informazioni, consulta [Organizzazione delle risorse Amazon EKS con tag](eks-using-tags.md).

1. Nella pagina **Imposta configurazione di calcolo e dimensionamento**, compila i parametri di conseguenza e quindi scegli **Successivo**.
   +  **Tipo di AMI:** selezionare un tipo di AMI. Se stai distribuendo istanze Arm, assicurati di rivedere le considerazioni in [Arm Amazon Linux AMIs ottimizzato per Amazon EKS prima](eks-optimized-ami.md#arm-ami) della distribuzione.

     Se nella pagina precedente sono stati specificati un modello di avvio e un’AMI nel modello, non è possibile selezionare un valore. Viene visualizzato il valore del modello. L’AMI specificata nel modello deve soddisfare i requisiti indicati alla pagina [Specifying an AMI](launch-templates.md#launch-template-custom-ami).
   +  **Tipo di capacità**: seleziona un tipo di capacità. Per ulteriori informazioni sulla scelta di un tipo di capacità, consulta [Tipi di capacità del gruppo di nodi gestiti](managed-node-groups.md#managed-node-group-capacity-types). Non è possibile combinare diversi tipi di capacità all’interno dello stesso gruppo di nodi. Se desideri utilizzare entrambi i tipi di capacità, crea gruppi di nodi separati, ognuno con i propri tipi di capacità e istanza. [ GPUs Per informazioni sul provisioning e la scalabilità dei nodi di lavoro accelerati da GPU, consulta Reserve for managed node groups](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html).
   +  **Tipi di istanza**: per impostazione predefinita, viene specificato uno o più tipi di istanza. Per rimuovere un tipo di istanza predefinito, seleziona il `X` sul lato destro del tipo di istanza. Scegli il tipo di istanza da utilizzare nel gruppo di nodi gestiti. Per ulteriori informazioni, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md).

     Nella console viene visualizzato un insieme di tipi di istanza di uso comune. Se devi creare un gruppo di nodi gestito con un tipo di istanza che non viene visualizzato`eksctl`, usa la AWS CLI o un SDK per creare il gruppo di nodi. AWS CloudFormation Se nella pagina precedente è stato specificato un modello di avvio, non è possibile selezionare un valore perché il tipo di istanza deve essere specificato nel modello di avvio. Viene visualizzato il valore del modello di avvio. Se è stato selezionato **Spot** per **Tipo capacità**, al fine di migliorare la disponibilità è consigliabile specificare più tipi di istanza.
   +  **Dimensioni disco**: inserire le dimensioni del disco (in GiB) da utilizzare per il volume root del nodo.

     Se nella pagina precedente è stato specificato un modello di avvio, non è possibile selezionare un valore perché deve essere specificato nel modello di avvio.
   +  **Dimensione desiderata**: specifica il numero corrente di nodi che il gruppo di nodi gestiti deve mantenere all'avvio.
**Nota**  
Amazon EKS non aumenta o riduce orizzontalmente in automatico il gruppo di nodi. Tuttavia, è possibile configurare il Cluster Autoscaler di Kubernetes per eseguire questa operazione. Per ulteriori informazioni, consulta [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) on. AWS
   +  **Dimensione minima**: specifica il numero minimo di nodi a cui il gruppo di nodi gestiti può essere ridotto.
   +  **Dimensione massima**: specifica il numero massimo di nodi a cui il gruppo di nodi gestiti può essere aumentato.
   +  **Configurazione dell'aggiornamento dei gruppi di nodi**: (facoltativo) puoi selezionare il numero o la percentuale di nodi da aggiornare in parallelo. Questi nodi non saranno disponibili durante l'aggiornamento. Per **Numero massimo non disponibile**, seleziona una delle seguenti opzioni e specifica un **Valore**:
     +  **Numero**: seleziona e specifica il numero di nodi nel gruppo nodi che possono essere aggiornati in parallelo.
     +  **Percentuale**: seleziona e specifica la percentuale di nodi nel gruppo di nodi che possono essere aggiornati in parallelo. Questa funzione è utile se disponi di un numero elevato di nodi nel gruppo di nodi.
   +  **Configurazione di riparazione automatica del nodo**: (facoltativo) se viene attivata la casella di controllo **Abilita la riparazione automatica del nodo**, Amazon EKS sostituirà automaticamente i nodi quando si verificano i problemi rilevati. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).

1. Nella pagina **Specifica reti**, compila i parametri opportunamente, quindi scegli **Successivo**.
   +  **Sottoreti**: sceglii le sottoreti in cui avviare i nodi gestiti.
**Importante**  
Se si esegue un’applicazione stateful in più zone di disponibilità supportate dai volumi Amazon EBS e che utilizza il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes, è necessario configurare più gruppi di nodi, ognuno dei quali definito per una singola zona di disponibilità. Inoltre, è necessario abilitare la funzionalità `--balance-similar-node-groups`.
**Importante**  
Se si sceglie una sottorete pubblica e nel cluster è abilitato solo l'endpoint del server API pubblico, è necessario che la sottorete disponga di `MapPublicIPOnLaunch` impostato su `true` per consentire alle istanze di unirsi correttamente a un cluster. Se la sottorete è stata creata utilizzando `eksctl` o i [AWS CloudFormation modelli forniti da Amazon EKS](creating-a-vpc.md) a partire dal 26 marzo 2020, allora questa impostazione è già impostata su. `true` Se le sottoreti sono state create con `eksctl` o i AWS CloudFormation modelli prima del 26 marzo 2020, devi modificare l'impostazione manualmente. Per ulteriori informazioni, vedere [Modifica dell'attributo di IPv4 indirizzamento pubblico per la](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) sottorete.
Se si utilizza un modello di avvio e si specificano più interfacce di rete, Amazon EC2 non assegnerà automaticamente un indirizzo `IPv4` pubblico, anche se `MapPublicIpOnLaunch` è impostato su `true`. Affinché i nodi possano unirsi al cluster in questo scenario, è necessario abilitare l’endpoint del server API privato del cluster, oppure avviare i nodi in una sottorete privata con accesso Internet in uscita fornito attraverso un metodo alternativo, ad esempio un gateway NAT. Per ulteriori informazioni, consultare la pagina [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) della *Guida per l’utente di Amazon EC2*.
   +  **Configurazione dell'accesso SSH ai nodi** (facoltativo). L'abilitazione di SSH consente di connettersi alle istanze e raccogliere informazioni diagnostiche in caso di problemi. Consigliamo vivamente di abilitare l'accesso remoto quando crei un gruppo di nodi. Non è possibile abilitare l’accesso remoto dopo la creazione del gruppo di nodi.

     Se si sceglie di utilizzare un modello di avvio, questa opzione non viene visualizzata. Per abilitare l'accesso remoto ai nodi, specifica una coppia di chiavi nel modello di avvio e assicurati che la porta appropriata sia aperta ai nodi nei gruppi di sicurezza specificati nel modello di avvio. Per ulteriori informazioni, consulta [Utilizzo di gruppi di sicurezza personalizzati](launch-templates.md#launch-template-security-groups).
**Nota**  
Per Windows, questo comando non abilita SSH. Associa, invece, la coppia di chiavi Amazon EC2 all'istanza e ti consente di eseguire il protocollo RDP nell'istanza.
   + Per **Coppia di chiavi SSH** (facoltativo), scegli una chiave SSH Amazon EC2 da utilizzare. Per informazioni su Linux, consultare [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Per informazioni su Windows, consultare [Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Se si sceglie di utilizzare un modello di avvio, non è possibile selezionarne una. Quando viene fornita una chiave SSH Amazon EC2 per i gruppi di nodi che utilizzano Bottlerocket AMIs, viene abilitato anche il contenitore amministrativo. Per ulteriori informazioni, consulta [Container amministratore](https://github.com/bottlerocket-os/bottlerocket#admin-container) su GitHub.
   + Per **Autorizzazione di accesso remoto SSH da**, se desideri limitare l'accesso a istanze specifiche, seleziona i gruppi di sicurezza associati a tali istanze. Se non si selezionano gruppi di sicurezza specifici, l’accesso SSH è consentito da qualsiasi indirizzo di Internet (`0.0.0.0/0`).

1. Nella pagina **Rivedi e crea**, controlla la configurazione del gruppo di nodi gestiti e scegli **Crea**.

   Se i nodi di lavoro non riescono a unirsi al cluster, consultare [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) nel capitolo dedicato alla risoluzione dei problemi.

1. Guarda lo stato dei nodi e attendi che raggiungano lo stato `Ready`.

   ```
   kubectl get nodes --watch
   ```

1. (Solo nodi GPU) Se hai scelto un tipo di istanza GPU e un'AMI accelerata ottimizzata per Amazon EKS, devi applicare [il plug-in del dispositivo NVIDIA per](https://github.com/NVIDIA/k8s-device-plugin) Kubernetes sul tuo cluster. DaemonSet Sostituiscilo *vX.X.X* con la versione di [s-device-pluginNVIDIA/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) desiderata prima di eseguire il comando seguente.

   ```
   kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
   ```

## Installare i componenti aggiuntivi Kubernetes
<a name="_install_kubernetes_add_ons"></a>

Ora che si dispone di un cluster Amazon EKS funzionante con nodi, è possibile avviare l’installazione dei componenti aggiuntivi Kubernetes e l’implementazione di applicazioni al cluster. I seguenti argomenti della documentazione consentono di estendere la funzionalità del cluster.
+ Il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) in grado di creare il cluster è l’unico principale che può effettuare chiamate al server API Kubernetes tramite `kubectl` o la Console di gestione AWS. Se si desidera che altri principali IAM abbiano accesso al cluster, è necessario aggiungerli. Per ulteriori informazioni, consultare [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md) e [Autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Consigliamo di bloccare l’accesso dei pod a IMDS se si verificano le seguenti condizioni:
  + Prevedi di assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie.
  + Nessun pod nel cluster richiede l'accesso al servizio di metadati dell'istanza Amazon EC2 (IMDS) per altri motivi, come il recupero della regione corrente. AWS 

  Per ulteriori informazioni, consulta [Limita l’accesso al profilo dell’istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ Configurare il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes per regolare automaticamente il numero di nodi nei gruppi di nodi.
+ Implementare [un’applicazione di esempio](sample-deployment.md) al cluster.
+  [Organizzare e monitorare le risorse del cluster](eks-managing.md) con strumenti importanti per la gestione.

# Aggiornamento del gruppo di nodi gestito per il cluster
<a name="update-managed-node-group"></a>

Quando si avvia un aggiornamento di un gruppo di nodi gestiti, Amazon EKS aggiorna automaticamente i nodi, completando i passaggi elencati in [Understand each phase of node updates](managed-node-update-behavior.md). Se si utilizza un’AMI ottimizzata per Amazon EKS, Amazon EKS applica automaticamente le patch di sicurezza più recenti e gli aggiornamenti del sistema operativo ai nodi come parte dell’ultima versione di AMI.

Esistono diversi scenari in cui è utile aggiornare la versione o la configurazione del gruppo di nodi gestiti Amazon EKS:
+ Hai aggiornato la versione di Kubernetes per il cluster Amazon EKS e vuoi aggiornare i nodi per utilizzare la stessa versione di Kubernetes.
+ Una nuova versione dell'AMI è disponibile per il gruppo di nodi gestiti. Per ulteriori informazioni sulle versioni AMI, consultare le seguenti sezioni:
  +  [Recupero delle informazioni sulla versione dell’AMI Amazon Linux](eks-linux-ami-versions.md) 
  +  [Crea nodi con Bottlerocket ottimizzato AMIs](eks-optimized-ami-bottlerocket.md) 
  +  [Recupero delle informazioni sulla versione delle AMI Windows](eks-ami-versions-windows.md) 
+ Per regolare il conteggio minimo, massimo o desiderato delle istanze nel gruppo di nodi gestiti.
+ Per aggiungere o rimuovere le etichette Kubernetes dalle istanze del gruppo di nodi gestiti.
+ Vuoi aggiungere o rimuovere AWS tag dal tuo gruppo di nodi gestito.
+ È necessario implementare una nuova versione di un modello di avvio con modifiche alla configurazione, ad esempio un'AMI personalizzata aggiornata.
+ Hai distribuito una versione `1.9.0` o successiva del componente aggiuntivo Amazon VPC CNI, abilitato il componente aggiuntivo per la delega dei prefissi e desideri che AWS nuove istanze Nitro System in un gruppo di nodi supportino un numero significativamente maggiore di Pod. Per ulteriori informazioni, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md).
+ Hai abilitato la delega del prefisso IP per i nodi Windows e desideri che nuove istanze di AWS Nitro System in un gruppo di nodi supportino un numero significativamente maggiore di Pod. Per ulteriori informazioni, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md).

Se esiste una versione dell’AMI più recente per la versione Kubernetes del gruppo di nodi gestiti rispetto a quella in esecuzione nel gruppo di nodi, è possibile aggiornare quest’ultima per utilizzare la nuova versione dell’AMI. Analogamente, se nel cluster è in esecuzione una versione di Kubernetes più recente rispetto al gruppo di nodi, è possibile aggiornare il gruppo di nodi per utilizzare la versione più recente dell’AMI che corrisponde alla versione di Kubernetes del cluster.

Quando un nodo in un gruppo di nodi gestiti è terminato a causa di un’operazione di dimensionamento o di un aggiornamento, i pod nel nodo sono svuotati per primi. Per ulteriori informazioni, consulta [Comprendi ogni fase degli aggiornamenti dei nodi](managed-node-update-behavior.md).

## Aggiornare la versione di un gruppo di nodi
<a name="mng-update"></a>

È possibile aggiornare la versione di un gruppo di nodi con uno dei seguenti:
+  [`eksctl`](#eksctl_update_managed_nodegroup) 
+  [Console di gestione AWS](#console_update_managed_nodegroup) 

La versione a cui si aggiorna non può essere successiva alla versione del piano di controllo.

## `eksctl`
<a name="eksctl_update_managed_nodegroup"></a>

 **Aggiornare un gruppo di nodi gestito utilizzando `eksctl`** 

Aggiorna un gruppo di nodi gestiti alla stessa versione AMI più recente di Kubernetes attualmente implementata nei nodi con il comando seguente. Sostituisci ogni *example value* con i valori in tuo possesso.

```
eksctl upgrade nodegroup \
  --name=node-group-name \
  --cluster=my-cluster \
  --region=region-code
```

**Nota**  
Se stai aggiornando un gruppo di nodi implementato con un modello di avvio a una nuova versione del modello di avvio, aggiungi `--launch-template-version version-number ` al precedente comando. Il modello di avvio deve soddisfare i requisiti descritti in [Customize managed nodes with launch templates](launch-templates.md). Se il modello di avvio include un’AMI personalizzata, l’AMI deve soddisfare i requisiti in [Specificare un’AMI](launch-templates.md#launch-template-custom-ami). Quando si aggiorna il gruppo di nodi a una versione più recente del modello di avvio, tutti i nodi sono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata.

Non è possibile aggiornare direttamente un gruppo di nodi implementato senza un modello di avvio a una nuova versione del modello di avvio. È invece necessario implementare un nuovo gruppo di nodi utilizzando il modello di avvio per aggiornare il gruppo di nodi a una nuova versione del modello di avvio.

È possibile aggiornare un gruppo di nodi alla stessa versione della versione Kubernetes del piano di controllo. Ad esempio, se hai un cluster che esegue Kubernetes `1.35`, puoi aggiornare i nodi che attualmente eseguono Kubernetes `1.34` alla versione `1.35` con il comando seguente.

```
eksctl upgrade nodegroup \
  --name=node-group-name \
  --cluster=my-cluster \
  --region=region-code \
  --kubernetes-version=1.35
```

## Console di gestione AWS
<a name="console_update_managed_nodegroup"></a>

 **Aggiornare un gruppo di nodi gestito utilizzando Console di gestione AWS ** 

1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Scegliere il cluster che contiene il gruppo di nodi da aggiornare.

1. Se almeno un gruppo di nodi dispone di un aggiornamento disponibile, nella parte superiore della pagina viene visualizzata una casella di notifica dell'aggiornamento disponibile. Se selezioni la scheda **Calcolo**, visualizzerai **Aggiorna ora** nella colonna **Versione rilascio AMI** nella tabella **Gruppi di nodi** per il gruppo di nodi per cui è disponibile un aggiornamento. Per aggiornare il gruppo di nodi, scegli **Update now** (Aggiorna ora).

   Non verrà visualizzata una notifica per i gruppi di nodi implementati con un’AMI personalizzata. Se i nodi vengono implementati con un'AMI personalizzata, completare la procedura seguente per implementare una nuova AMI personalizzata aggiornata.

   1. Crea una nuova versione dell'AMI.

   1. Creare una nuova versione del modello di avvio con il nuovo ID AMI.

   1. Aggiornamento dei i nodi alla nuova versione del modello di avvio.

1. Nella finestra di dialogo **Update node group version** (Aggiorna la versione del gruppo di nodi), attiva o disattiva le seguenti opzioni:
   +  **Update node group version** (Aggiorna la versione del gruppo di nodi): questa opzione non è disponibile se hai implementato un'AMI personalizzata o se l'AMI ottimizzata per Amazon EKS attualmente è disponibile nella versione più recente del cluster.
   +  **Change launch template version** (Modifica la versione del modello di avvio): questa opzione non è disponibile se il gruppo di nodi è implementato senza un modello di avvio personalizzato. È possibile aggiornare la versione del modello di avvio solo per un gruppo di nodi implementato con un modello di avvio personalizzato. Seleziona la **Launch template version** (Versione del modello di avvio) a cui eseguire l'aggiornamento del gruppo di nodi. Se il gruppo di nodi è configurato con un'AMI personalizzata, anche la versione selezionata deve specificare un'AMI. Quando si esegue l'aggiornamento a una versione più recente del modello di avvio, tutti i nodi vengono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata.

1. Per **Update strategy** (Strategia aggiornamento), seleziona una delle seguenti opzioni:
   +  **Aggiornamento in sequenza**: questa opzione rispetta i budget di interruzione del pod per il cluster. Gli aggiornamenti non riescono se c’è un problema di budget che interrompe il pod, che fa sì che Amazon EKS non riesca a svuotare correttamente i pod in esecuzione su questo gruppo di nodi.
   +  **Forza aggiornamento**: questa opzione non rispetta i budget per le interruzioni dei pod. Gli aggiornamenti sono eseguiti indipendentemente dai problemi di budget di interruzione del pod forzando il riavvio dei nodi.

1. Scegliere **Aggiorna**.

## Modificare la configurazione di un gruppo di nodi
<a name="mng-edit"></a>

È possibile modificare parte della configurazione di un gruppo di nodi gestiti.

1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Scegliere il cluster che contiene il gruppo di nodi da modificare.

1. Seleziona la scheda **Compute** (Calcolo).

1. Seleziona il gruppo di nodi da modificare, e scegli **Edit** (Modifica).

1. (Facoltativo) Nella pagina **Edit node group** (Modifica gruppo di nodi), effettua le seguenti operazioni:

   1. Modifica la **configurazione di scalabilità del gruppo di nodi**.
      +  **Dimensione desiderata**: specifica il numero corrente di nodi che il gruppo di nodi gestiti deve mantenere.
      +  **Dimensione minima**: specifica il numero minimo di nodi a cui il gruppo di nodi gestiti può essere ridotto.
      +  **Dimensione massima**: specifica il numero massimo di nodi a cui il gruppo di nodi gestiti può essere aumentato orizzontalmente. Per il numero massimo di nodi supportati in un gruppo di nodi, vedere [Visualizzazione e gestione di quote di servizio di Amazon EKS e Fargate](service-quotas.md).

   1. (Facoltativo) Aggiungi o rimuovi **etichette Kubernetes** ai nodi nel gruppo di nodi. Le etichette mostrate qui sono solo le etichette applicate con Amazon EKS. Altre etichette, non mostrate qui, possono essere presenti sui nodi.

   1. (Facoltativo) Aggiungi o rimuovi **taint Kubernetes** ai nodi nel gruppo di nodi. I taint aggiunti possono avere l'effetto di ` NoSchedule `, ` NoExecute `, oppure ` PreferNoSchedule `. Per ulteriori informazioni, consulta [Ricetta: impedire che i pod siano programmati su nodi specifici](node-taints-managed-node-groups.md).

   1. (Facoltativo) Aggiungi o rimuovi **Tag** dalla risorsa del gruppo di nodi. Questi tag vengono applicati solo al gruppo di nodi Amazon EKS. I tag dei gruppi di nodi non si propagano ad altre risorse come istanze o le sottoreti di Amazon EC2 nel gruppo di nodi.

   1. (Facoltativo) Modifica la **Configurazione dell'aggiornamento del gruppo di nodi**. Seleziona un'opzione tra **Numero** o **Percentuale**.
      +  **Numero**: seleziona e specifica il numero di nodi nel gruppo nodi che possono essere aggiornati in parallelo. Questi nodi non saranno disponibili durante l'aggiornamento.
      +  **Percentuale**: selezionare e specificare la percentuale di nodi nel gruppo di nodi che possono essere aggiornati in parallelo. Questi nodi non saranno disponibili durante l'aggiornamento. Questa funzione è utile se si dispone di diversi nodi nel gruppo di nodi.

   1. Al termine della modifica, scegli **Salva modifiche**.

**Importante**  
Quando si aggiorna la configurazione del gruppo di nodi, la modifica di Pod [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)non rispetta i budget di interruzione delle attività dei Pod (). PDBs A differenza del processo di [aggiornamento del gruppo di nodi](managed-node-update-behavior.md) (che prosciuga i nodi e li rispetta PDBs durante la fase di aggiornamento), l'aggiornamento della configurazione di scalabilità causa la chiusura immediata dei nodi tramite una chiamata di scale-down di Auto Scaling Group (ASG). Ciò avviene senza considerarlo PDBs, indipendentemente dalla dimensione target a cui si sta effettuando la scalabilità. Ciò significa che quando riduci il numero `desiredSize` di un gruppo di nodi gestiti da Amazon EKS, i Pod vengono eliminati non appena i nodi vengono terminati, senza onorarne nessuno. PDBs

# Comprendi ogni fase degli aggiornamenti dei nodi
<a name="managed-node-update-behavior"></a>

La strategia di aggiornamento del nodo (worker) gestito di Amazon EKS ha quattro fasi diverse descritte nelle sezioni seguenti.

## Fase di configurazione
<a name="managed-node-update-set-up"></a>

La fase di configurazione prevede i seguenti passaggi:

1. Crea una nuova versione del modello di avvio Amazon EC2 per il gruppo Auto Scaling associato al gruppo di nodi. La nuova versione del modello di avvio utilizza l’AMI di destinazione o una versione del modello di avvio personalizzata per l’aggiornamento.

1. Il gruppo Auto Scaling viene aggiornato per utilizzare la versione più recente del modello di avvio.

1. Determina la quantità massima di nodi da aggiornare in parallelo utilizzando la proprietà `updateConfig` per il gruppo di nodi. Il massimo non disponibile ha una quota di 100 nodi. Il valore di default è un nodo. Per ulteriori informazioni, consulta la proprietà [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) nella *Documentazione di riferimento delle API di Amazon EKS*.

## Fase di scalabilità
<a name="managed-node-update-scale-up"></a>

Quando si aggiornano i nodi in un gruppo di nodi gestiti, i nodi aggiornati vengono avviati nella stessa zona di disponibilità di quelli in fase di aggiornamento. Per garantire questo posizionamento, utilizziamo il ribilanciamento della zona di disponibilità di Amazon EC2. Per ulteriori informazioni, consulta [Availability Zone Rebalancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) nella *Guida per l’utente di Amazon EC2 Auto Scaling*. Per soddisfare questo requisito, è possibile avviare fino a due istanze per zona di disponibilità nel gruppo di nodi gestiti.

La fase di scalabilità prevede i seguenti passaggi:

1. Incrementa la dimensione massima e la dimensione desiderata del gruppo Auto Scaling in base alla scelta maggiore tra:
   + Fino a due volte il numero di zone di disponibilità in cui è stato implementato il gruppo Auto Scaling.
   + Il massimo non disponibile per l’aggiornamento.

     Ad esempio, se il gruppo di nodi ha cinque zone di disponibilità e `maxUnavailable` è uno, il processo di aggiornamento può avviare al massimo 10 nodi. Tuttavia, quando `maxUnavailable` è 20 (o comunque superiore a 10), il processo avvia 20 nuovi nodi.

1. Dopo aver dimensionato il gruppo Auto Scaling, verifica se i nodi che utilizzano la configurazione più recente sono presenti nel gruppo di nodi. Questo passaggio ha esito positivo solo quando soddisfa i seguenti criteri:
   + Almeno un nuovo nodo viene avviato in ogni zona di disponibilità in cui esiste il nodo.
   + Ogni nuovo nodo deve essere nello stato `Ready`.
   + I nuovi nodi devono avere etichette applicate da Amazon EKS.

     Queste sono le etichette applicate da Amazon EKS sui nodi (worker) di un normale gruppo di nodi:
     +  `eks.amazonaws.com/nodegroup-image=$amiName` 
     +  `eks.amazonaws.com/nodegroup=$nodeGroupName` 

     Queste sono le etichette applicate da Amazon EKS sui nodi (worker) in un modello di avvio personalizzato o un gruppo di nodi AMI:
     +  `eks.amazonaws.com/nodegroup-image=$amiName` 
     +  `eks.amazonaws.com/nodegroup=$nodeGroupName` 
     +  `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId` 
     +  `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion` 

1. Contrassegna i nodi come non programmabili per evitare di programmare nuovi pod. Inoltre, etichetta i nodi con `node.kubernetes.io/exclude-from-external-load-balancers=true` per rimuovere i vecchi nodi dai sistemi di bilanciatore del carico prima di terminare i nodi.

Di seguito sono riportati i motivi noti che portano a un errore `NodeCreationFailure` in questa fase:

 **Capacità insufficiente nella zona di disponibilità**   
Esiste la possibilità che la zona di disponibilità non abbia capacità disponibile per i tipi di istanza richiesti. Si consiglia di configurare più tipi di istanze durante la creazione di un gruppo di nodi gestiti.

 **Limiti delle istanze EC2 dell’account**   
Potrebbe essere necessario aumentare il numero di istanze Amazon EC2 che il l’account può eseguire contemporaneamente utilizzando Service Quotas. Per ulteriori informazioni, consulta [Service Quotas di EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) nella *Guida per l’utente di Amazon Elastic Compute Cloud per le istanze Linux*.

 **Dati utente personalizzati**   
I dati utente personalizzati possono talvolta interrompere il processo di bootstrap. Questo scenario può portare al mancato avvio di `kubelet` sul nodo o sui nodi che non ricevono le etichette Amazon EKS previste. Per ulteriori informazioni, consulta [Specifica di un'AMI](launch-templates.md#launch-template-custom-ami).

 **Qualsiasi modifica che renda un nodo non integro o non pronto**   
La pressione del disco del nodo, la pressione della memoria e condizioni simili possono far sì che un nodo non assuma lo stato `Ready`.

 **Ogni nodo si avvia al massimo entro 15 minuti**   
Se un nodo impiega più di 15 minuti per avviarsi e unirsi al cluster, si verificherà il timeout dell’aggiornamento. Questo è il runtime totale per il bootstrap di un nuovo nodo misurato dal momento in cui è necessario un nuovo nodo al momento in cui si unisce al cluster. Quando si aggiorna un gruppo di nodi gestito, il contatore temporale si avvia non appena la dimensione del gruppo Auto Scaling aumenta.

## Fase di aggiornamento
<a name="managed-node-update-upgrade"></a>

La fase di aggiornamento si comporta in due modi diversi, a seconda della *strategia di aggiornamento*. Esistono due strategie di aggiornamento: **predefinita** e **minimale**.

Consigliamo una strategia predefinita nella maggior parte degli scenari. Infatti, questa crea nuovi nodi prima di terminare quelli vecchi, in modo da mantenere la capacità disponibile durante la fase di aggiornamento. La strategia minimale è utile in scenari in cui si è limitati per quanto riguarda risorse o costi, ad esempio con acceleratori hardware come le GPU. Infatti, termina i vecchi nodi prima di creare quelli nuovi, in modo che la capacità totale non aumenti mai oltre la quantità configurata.

La strategia di aggiornamento *predefinita* prevede i seguenti passaggi:

1. Aumenta la quantità di nodi (numero desiderato) nel gruppo Auto Scaling, facendo sì che il gruppo di nodi crei nodi aggiuntivi.

1. Seleziona casualmente un nodo che deve essere aggiornato, fino al massimo non disponibile configurato per il gruppo di nodi.

1. Svuota i pod dal nodo. Se i pod non lasciano il nodo entro 15 minuti e non c’è un flag di forzatura, la fase di aggiornamento non riesce con errore `PodEvictionFailure`. Per questo scenario, è possibile applicare il flag di forzatura con la richiesta `update-nodegroup-version` di eliminare i pod.

1. Isola il nodo dopo che ogni pod è stato espulso e aspetta 60 secondi. Ciò consente al controller di servizio di non inviare nuove richieste a questo nodo, e lo rimuove dall’elenco di nodi attivi.

1. Invia una richiesta di interruzione al gruppo con scalabilità automatica per il nodo isolato.

1. Ripete i passaggi di aggiornamento precedenti fino a quando non vi sono nodi nel gruppo implementato con la versione precedente del modello di avvio.

La strategia di aggiornamento *minimale* prevede i seguenti passaggi:

1. All’inizio isola tutti i nodi del gruppo di nodi, in modo che il controller di servizio non invii nuove richieste a questi nodi.

1. Seleziona casualmente un nodo che deve essere aggiornato, fino al massimo non disponibile configurato per il gruppo di nodi.

1. Drena i Pod dai nodi selezionati. Se i pod non lasciano il nodo entro 15 minuti e non c’è un flag di forzatura, la fase di aggiornamento non riesce con errore `PodEvictionFailure`. Per questo scenario, puoi applicare il flag di forzatura con la richiesta `update-nodegroup-version` di eliminare i pod.

1. Dopo che ogni pod è stato rimosso e ha atteso 60 secondi, invia una richiesta di interruzione al gruppo Auto Scaling per i nodi selezionati. Il gruppo Auto Scaling crea nuovi nodi (lo stesso numero di nodi selezionati) per sostituire la capacità mancante.

1. Ripete i passaggi di aggiornamento precedenti fino a quando non vi sono nodi nel gruppo implementato con la versione precedente del modello di avvio.

### Errori `PodEvictionFailure` durante la fase di aggiornamento
<a name="_podevictionfailure_errors_during_the_upgrade_phase"></a>

Di seguito sono riportati i motivi noti che portano a un errore `PodEvictionFailure` in questa fase:

 **PDB aggressivo**   
Sul pod è definito un PDB aggressivo oppure sono presenti più PDB che puntano allo stesso pod.

 **Implementazione che tollera tutti i taint**   
Una volta espulso ogni pod, il nodo dovrebbe essere vuoto in quanto [oggetto di taint](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nei passaggi precedenti. Tuttavia, se l’implementazione tollera ogni taint, è più probabile che il nodo non sia vuoto, causando un errore di espulsione dal pod.

## Fase di dimensionamento
<a name="managed-node-update-scale-down"></a>

La fase di dimensionamento diminuisce di uno la dimensione massima del gruppo Auto Scaling e la dimensione desiderata per tornare ai valori prima dell’avvio dell’aggiornamento.

Se il flusso di lavoro di aggiornamento determina che il Cluster Autoscaler stia dimensionando il gruppo di nodi durante la fase di dimensionamento del flusso di lavoro, esce immediatamente senza riportare il gruppo di nodi alle dimensioni originali.

# Personalizzazione dei nodi gestiti con modelli di avvio
<a name="launch-templates"></a>

Per il massimo livello di personalizzazione, puoi distribuire nodi gestiti con il tuo modello di lancio in base ai passaggi di questa pagina. L'utilizzo di un modello di avvio consente funzionalità come fornire argomenti di bootstrap durante la distribuzione di un nodo (ad esempio, argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi), assegnare indirizzi IP ai Pod da un blocco CIDR diverso dall'indirizzo IP assegnato al nodo, distribuire la propria AMI personalizzata ai nodi o distribuire il proprio CNI personalizzato sui nodi.

Quando fornisci il tuo modello di avvio alla prima creazione di un gruppo di nodi gestito, in seguito avrai anche una maggiore flessibilità. Dopo aver implementato un gruppo di nodi gestiti con un modello di avvio personalizzato, potrai aggiornarlo in maniera iterativa con una versione diversa dello stesso modello. Quando si aggiorna il gruppo di nodi a una versione diversa del modello di avvio, tutti i nodi del gruppo vengono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata.

I gruppi di nodi gestiti vengono sempre implementati con un modello di avvio da utilizzare con gruppo di Amazon EC2 Auto Scaling. Quando non è fornito un modello di avvio, l’API Amazon EKS ne crea automaticamente uno con i valori predefiniti nel tuo account. Tuttavia, consigliamo di non modificare i modelli di avvio generati automaticamente. Inoltre, i gruppi di nodi esistenti che non utilizzano un modello di avvio personalizzato non possono essere aggiornati direttamente. A tale scopo, sarà invece necessario creare un nuovo gruppo di nodi con un modello di avvio personalizzato.

## Informazioni di base sulla configurazione del modello di avvio
<a name="launch-template-basics"></a>

Puoi creare un modello di lancio di Amazon EC2 Auto Scaling con la Console di gestione AWS CLI AWS o un SDK. AWS Per ulteriori informazioni, consulta [Creazione di un modello di avvio per un gruppo con scalabilità automatica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*. Alcune impostazioni di un modello di avvio sono simili a quelle utilizzate per la configurazione dei nodi gestiti. Quando si implementa o si aggiorna un gruppo di nodi con un modello di avvio, è necessario specificare alcune impostazioni nella configurazione del gruppo di nodi o nel modello di avvio. Non specificare un’impostazione in entrambe le posizioni. Se un’impostazione è impostata dove non dovrebbe, operazioni come la creazione o l’aggiornamento di un gruppo di nodi non hanno esito positivo.

Nella tabella seguente sono elencate le impostazioni vietate in un modello di avvio. Elenca inoltre impostazioni simili, se disponibili, che sono necessarie per la configurazione del gruppo di nodi gestiti. Le impostazioni elencate sono quelle visualizzate nella console. Potrebbero avere nomi simili ma diversi nella AWS CLI e nell'SDK.


| Modello di avvio – Vietato | Configurazione del gruppo di nodi Amazon EKS | 
| --- | --- | 
|   **Sottorete** in **Interfacce di rete** (**Aggiungi interfaccia di rete**)  |   **Sottoreti** in **Configurazione di rete del gruppo di nodi** nella pagina **Specifica reti**  | 
|   **Profilo dell'istanza IAM** in **Dettagli avanzati**   |   **Ruolo IAM del nodo** in **Configurazione del gruppo di nodi** nella pagina **Configura gruppo di nodi**  | 
|   **Comportamento di arresto** e **Interrompi - Iberna comportamento** in **Dettagli avanzati**. Mantieni default **Non includere nell’impostazione del modello di avvio** nel modello di avvio per entrambe le impostazioni.  |  Nessun equivalente. Amazon EKS deve controllare il ciclo di vita dell'istanza, non il gruppo Auto Scaling.  | 

Nella tabella seguente sono elencate le impostazioni vietate nella configurazione di un gruppo di nodi gestiti. Elenca inoltre impostazioni simili, se disponibili, richieste in un modello di avvio. Le impostazioni elencate sono quelle visualizzate nella console. Potrebbero avere nomi simili nella AWS CLI e nell'SDK.


| Configurazione del gruppo di nodi Amazon EKS – Vietata | Modello di avvio | 
| --- | --- | 
|  (Solo se è stata specificata un'AMI personalizzata in un modello di avvio) **Tipo di AMI** in **Configurazione di calcolo del gruppo di nodi** sulla pagina **Imposta configurazione di calcolo e dimensionamento**: la console mostra il messaggio **Specificato nel modello di lancio** e l'ID AMI specificato. Se nel modello di avvio non è stato specificato **Applicazione e immagini OS (Amazon Machine Image)**, è possibile selezionare un’AMI nella configurazione del gruppo di nodi.  |   **Applicazione e immagini OS (Amazon Machine Image)** in **Contenuti del modello di avvio**: è necessario specificare un ID se soddisfi uno dei seguenti requisiti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/launch-templates.html)  | 
|   **Dimensioni del disco** in **Configurazione di calcolo del gruppo di nodi** nella pagina **Imposta configurazione di calcolo e dimensionamento**: la console mostra il messaggio **Specificato nel modello di lancio**.  |   **Dimensioni** in **Archiviazione (volumi)** (**Aggiungi nuovo volume**). È necessario specificarlo nel modello di avvio.  | 
|   **Coppia di chiavi SSH** in **Configurazione del gruppo di nodi** nella pagina **Specifica reti**: la console mostra la chiave specificata nel modello di avvio o mostra il messaggio **Non specificato nel modello di lancio**.  |   **Nome della coppia di chiavi** in **Coppia di chiavi (login)**.  | 
|  Non è possibile specificare gruppi di sicurezza di origine a cui è consentito l’accesso remoto quando si utilizza un modello di avvio.  |   **Gruppi di sicurezza** in **Impostazioni di rete** per l'istanza o **Gruppi di sicurezza** in **Interfacce di rete** (**Aggiungi interfaccia di rete**), ma non entrambi. Per ulteriori informazioni, consulta [Utilizzo di gruppi di sicurezza personalizzati](#launch-template-security-groups).  | 

**Nota**  
Se si esegue l'implementazione di un gruppo di nodi utilizzando un modello di avvio, specificare uno o nessun **Tipo di istanza** in **Contenuti del modello di avvio** in un modello di avvio. In alternativa, è possibile specificare 0-20 tipi di istanza per **Tipi di istanza** nella pagina **Impostare la configurazione di calcolo e dimensionamento** della console. In alternativa, è possibile farlo utilizzando altri strumenti che utilizzano l'API Amazon EKS. Se specifichi un tipo di istanza in un modello di avvio e si utilizza tale modello di avvio per implementare il gruppo di nodi, non è possibile specificare alcun tipo di istanza nella console o utilizzare altri strumenti che sfruttino l’API Amazon EKS. Se non specifichi un tipo di istanza in un modello di avvio nella console o in altri strumenti che utilizzano l’API Amazon EKS, il tipo di istanza `t3.medium` sarà utilizzato. Se il gruppo di nodi utilizza il tipo di capacità Spot, è consigliabile specificare più tipi di istanza utilizzando la console. Per ulteriori informazioni, consulta [Tipi di capacità del gruppo di nodi gestiti](managed-node-groups.md#managed-node-group-capacity-types).
Se i container che si implementano nel gruppo di nodi utilizzano Instance Metadata Service versione 2, assicurarsi di impostare il **Limite hop di risposta metadati** a `2` nel modello di avvio. Per ulteriori informazioni, consulta [Metadati e dati dell'utente delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) nella *Guida per l'utente di Amazon EC2*.
I modelli di avvio non supportano la funzionalità `InstanceRequirements` che consente la selezione flessibile del tipo di istanza.

## Assegnazione di tag a istanze Amazon EC2
<a name="launch-template-tagging"></a>

É possibile utilizzare il parametro `TagSpecification` di un modello di avvio per specificare quali tag applicare alle istanze Amazon EC2 nel gruppo di nodi. L'entità IAM che chiama `CreateNodegroup` o `UpdateNodegroupVersion` APIs deve disporre delle autorizzazioni per `ec2:RunInstances` and `ec2:CreateTags` e i tag devono essere aggiunti al modello di lancio.

## Utilizzo di gruppi di sicurezza personalizzati
<a name="launch-template-security-groups"></a>

É possibile utilizzare un modello di avvio per specificare i [gruppi di sicurezza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) Amazon EC2 da applicare alle istanze del gruppo di nodi. Questo può essere nel parametro gruppi di sicurezza a livello di istanza o come parte dei parametri di configurazione dell'interfaccia di rete. Non è possibile avviare un’istanza da un modello di avvio che specifica sia il livello di istanza sia l’interfaccia di rete dei gruppi di sicurezza. Considerare le seguenti condizioni che si applicano all'utilizzo di gruppi di sicurezza personalizzati con gruppi di nodi gestiti:
+ Quando si utilizza Console di gestione AWS, Amazon EKS consente solo modelli di avvio con una singola specifica di interfaccia di rete.
+ Per impostazione predefinita, Amazon EKS applica il [Gruppo di sicurezza del cluster](sec-group-reqs.md) alle istanze nel gruppo di nodi, per facilitare la comunicazione tra i nodi e il piano di controllo. Se specifichi gruppi di sicurezza personalizzati nel modello di avvio utilizzando entrambe le opzioni menzionate in precedenza, Amazon EKS non aggiunge il gruppo di sicurezza del cluster. Pertanto, è necessario assicurarsi che le regole in entrata e in uscita dei gruppi di sicurezza abilitino la comunicazione con l'endpoint del cluster. Se le regole del gruppo di sicurezza non sono corrette, i nodi (worker) non possono aggiungersi al cluster. Per ulteriori informazioni sulle regole del gruppo di sicurezza, consultare [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md).
+ Se è necessario l'accesso SSH alle istanze nel gruppo di nodi, includere un gruppo di sicurezza che consenta tale accesso.

## Dati utente Amazon EC2
<a name="launch-template-user-data"></a>

Il modello di avvio include una sezione per i dati utente personalizzati. Puoi specificare le impostazioni di configurazione per il tuo gruppo di nodi in questa sezione senza creare manualmente singole impostazioni personalizzate AMIs. Per ulteriori informazioni sulle impostazioni disponibili per Bottlerocket, consulta [Using user data on](https://github.com/bottlerocket-os/bottlerocket#using-user-data). GitHub

É possibile fornire i dati utente Amazon EC2 nel tuo modello di avvio utilizzando `cloud-init` durante l'avvio delle istanze. Per ulteriori informazioni, consultare la documentazione [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). I dati utente possono essere utilizzati per eseguire operazioni di configurazione comuni. Sono comprese le seguenti opzioni:
+  [Inclusione di utenti o gruppi.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) 
+  [Installazione di pacchetti](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) 

I dati utente di Amazon EC2 nei modelli di avvio utilizzati con gruppi di nodi gestiti devono essere nel formato di archivio [multiparte MIME per Amazon Linux AMIs e nel formato](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) TOML per Bottlerocket. AMIs Questo perché i dati utente vengono uniti con i dati utente Amazon EKS necessari ai nodi per aderire al cluster. Non specificare alcun comando nei dati utente che avviano o modificano `kubelet`. Questa operazione viene eseguita come parte dei dati utente uniti da Amazon EKS. Certi parametri `kubelet`, come l'impostazione delle etichette sui nodi, possono essere configurati direttamente tramite l'API dei gruppi di nodi gestiti.

**Nota**  
Per ulteriori informazioni sulle personalizzazioni `kubelet` avanzate, tra cui l'avvio manuale o il passaggio a parametri di configurazione personalizzati, vedere [Specifica di un'AMI](#launch-template-custom-ami). Amazon EKS non unisce i dati utente se un ID AMI viene specificato in un modello di avvio.

I seguenti dettagli forniscono ulteriori informazioni sulla sezione dei dati utente.

 **Dati utente di Amazon Linux 2**   
È possibile unire più blocchi di dati utente in un unico blocco, detto file MIME in più parti. Ad esempio, è possibile combinare un hook di avvio del cloud per la configurazione del daemon Docker con uno script di shell dei dati utente che installa un pacchetto personalizzato. Un file MIME in più parti è composto dai seguenti elementi:  
+ Il tipo di contenuto e la dichiarazione di delimitazione della parte: `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` 
+ La dichiarazione della versione MIME: `MIME-Version: 1.0` 
+ Uno o più blocchi di dati utente, che contengono i seguenti elementi:
  + La delimitazione di apertura, che indica l'inizio di un blocco di dati utente: `--==MYBOUNDARY==` 
  + La dichiarazione del tipo di contenuto per il blocco: `Content-Type: text/cloud-config; charset="us-ascii"`. Per ulteriori informazioni sui tipi di contenuto, consultare la documentazione di [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
  + Il contenuto dei dati utente, ad esempio un elenco di comandi shell o direttive `cloud-init`.
  + La delimitazione di chiusura, che indica la fine del file MIME in più parti: `--==MYBOUNDARY==--` 

  Di seguito è riportato un esempio di un file in più parti MIME che è possibile utilizzare per crearne uno.

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
echo "Running custom user data script"

--==MYBOUNDARY==--
```

 **Dati utente di Amazon Linux 2023**   
Amazon Linux 2023 (AL2023) introduce un nuovo processo di inizializzazione dei nodi `nodeadm` che utilizza uno schema di configurazione YAML. Se utilizzi gruppi di nodi autogestiti o un’AMI con un modello di avvio, ora dovrai fornire esplicitamente metadati del cluster aggiuntivi quando si crea un nuovo gruppo di nodi. Un [esempio](https://awslabs.github.io/amazon-eks-ami/nodeadm/) dei parametri minimi richiesti è come segue, dove ora `apiServerEndpoint`, `certificateAuthority` e il servizio `cidr` sono richiesti:  

```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
```
In genere questa configurazione è impostata nei dati utente, così com’è o incorporata in un documento MIME composto da più parti:  

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]

--BOUNDARY--
```
Nel AL2, i metadati di questi parametri sono stati scoperti dalla chiamata `DescribeCluster` API di Amazon EKS. Nel frattempo AL2023, questo comportamento è cambiato poiché la chiamata API aggiuntiva rischia di rallentare durante l'up-up di nodi su larga scala. Questa modifica non ha effetto su di te se utilizzi gruppi di nodi gestiti senza un modello di avvio o se utilizzi Karpenter. Per ulteriori informazioni su `certificateAuthority` e sul servizio `cidr`, consulta [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) nel *Riferimento di API Amazon EKS*.  
Ecco un esempio completo di dati AL2023 utente che combina uno script di shell per personalizzare il nodo (come l'installazione di pacchetti o la prememorizzazione nella cache delle immagini dei contenitori) con la configurazione richiesta. `nodeadm` Questo esempio mostra personalizzazioni comuni tra cui: \$1 Installazione di pacchetti di sistema aggiuntivi \$1 Pre-memorizzazione nella cache delle immagini dei container per migliorare il tempo di avvio del pod \$1 Impostazione della configurazione del proxy HTTP \$1 Configurazione dei flag `kubelet` per l’etichettatura dei nodi  

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset

# Install additional packages
yum install -y htop jq iptables-services

# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &

# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF

--BOUNDARY
Content-Type: application/node.eks.aws

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
  kubelet:
    config:
      clusterDNS:
      - 10.100.0.10
    flags:
    - --node-labels=app=my-app,environment=production

--BOUNDARY--
```

 **Dati utente Bottlerocket**   
I dati utente delle strutture Bottlerocket nel formato TOML. È possibile fornire i dati utente da unire con i dati utente forniti da Amazon EKS. Ad esempio, è possibile fornire ulteriori impostazioni `kubelet`.  

```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Per ulteriori informazioni sulle impostazioni supportate, consultare la [documentazione Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). È possibile configurare etichette di nodi e [taint](node-taints-managed-node-groups.md) nei dati utente. Consigliamo, tuttavia, di configurarle all'interno del gruppo di nodi. In questo caso, Amazon EKS applica queste configurazioni.  
Quando i dati utente sono uniti, la formattazione non è mantenuta, ma il contenuto rimane invariato. La configurazione fornita nei dati utente sostituisce tutte le impostazioni configurate da Amazon EKS. Quindi, se imposti `settings.kubernetes.max-pods` o `settings.kubernetes.cluster-dns-ip`, questi valori nei dati utente sono applicati ai nodi.  
Amazon EKS non supporta tutti i TOML validi. Di seguito è riportato un elenco di formati noti non supportati:  
+ Quote all'interno delle chiavi stimate: `'quoted "value"' = "value"` 
+ Quote evase nei valori: `str = "I’m a string. \"You can quote me\""` 
+ Galleggianti e numeri interi misti: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` 
+ Tipi misti nelle matrici: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` 
+ Intestazioni tra parentesi con chiavi stimate: `[foo."bar.baz"]` 

 **Dati utente Windows**   
I dati utente di Windows utilizzano i comandi. PowerShell Quando crei un gruppo di nodi gestiti, i dati utente personalizzati si combinano con i dati utente gestiti da Amazon EKS. PowerShell I tuoi comandi vengono prima, seguiti dai comandi gestiti per i dati utente, il tutto all'interno di un unico `<powershell></powershell>` tag.  
Durante la creazione di gruppi di nodi Windows, Amazon EKS aggiorna il file `aws-auth` `ConfigMap` per consentire ai nodi basati su Linux di unirsi al cluster. Il servizio non configura automaticamente le autorizzazioni per Windows AMIs. Se utilizzi i nodi Windows, dovrai gestire l’accesso tramite l’API della voce di accesso o aggiornando direttamente `aws-auth` `ConfigMap`. Per ulteriori informazioni, consulta [Implementazione dei nodi Windows su cluster EKS](windows-support.md).
Quando non è specificato alcun ID AMI nel modello di avvio, nei dati utente non utilizzare lo script bootstrap di Amazon EKS per Windows per configurare Amazon EKS.
Di seguito sono riportati dati utente di esempio.  

```
<powershell>
Write-Host "Running custom user data script"
</powershell>
```

## Specifica di un'AMI
<a name="launch-template-custom-ami"></a>

Se si dispone di uno dei seguenti requisiti, specificare un ID AMI nel campo `ImageId` del modello di avvio. Selezionare il requisito di cui si dispone per ulteriori informazioni.

### Fornisci i dati utente per passare argomenti al `bootstrap.sh` file incluso in un' Linux/Bottlerocket AMI ottimizzata per Amazon EKS
<a name="mng-specify-eks-ami"></a>

Il termine "bootstrapping" indica l'aggiunta di comandi che possono essere eseguiti all'avvio di un'istanza. Ad esempio, il bootstrap consente di utilizzare argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi. È possibile passare gli argomenti allo script `bootstrap.sh` utilizzando `eksctl` senza specificare un modello di avvio. Oppure è possibile farlo specificando le informazioni nella sezione dati utente di un modello di avvio.

 **eksctl senza specificare un modello di avvio**   
Crea un file denominato *my-nodegroup.yaml* con i seguenti contenuti. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` sono facoltativi, ma grazie alla loro definizione lo script `bootstrap.sh` può evitare di effettuare una chiamata a `describeCluster`. Ciò è utile nelle configurazioni di cluster privati o nei cluster in cui si effettuano dimensionamenti frequenti dei nodi. Per ulteriori informazioni sullo `bootstrap.sh` script, consulta il file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) su GitHub.  
+ L'unico argomento richiesto è il nome del cluster (*my-cluster*).
+ Per recuperare l’ID di un’AMI ottimizzata per `ami-1234567890abcdef0 `, consulta le sezioni seguenti:
  +  [Recupera le AMI Amazon Linux consigliate IDs](retrieve-ami-id.md) 
  +  [Recupera l'AMI Bottlerocket consigliata IDs](retrieve-ami-id-bottlerocket.md) 
  +  [Recupera l'AMI Microsoft Windows consigliata IDs](retrieve-windows-ami-id.md) 
+ Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Questo esempio fornisce un argomento `kubelet` per impostare un valore `max-pods` personalizzato utilizzando lo script `bootstrap.sh` incluso nell'AMI ottimizzata per Amazon EKS. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura. Per assistenza nella scelta di *my-max-pods-value*, consulta . Per ulteriori informazioni su come `maxPods` viene determinato quando si utilizzano i gruppi di nodi gestiti, vedere[Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence).

  ```
  ---
  apiVersion: eksctl.io/v1alpha5
  kind: ClusterConfig
  
  metadata:
    name: my-cluster
    region: region-code
  
  managedNodeGroups:
    - name: my-nodegroup
      ami: ami-1234567890abcdef0
      instanceType: m5.large
      privateNetworking: true
      disableIMDSv1: true
      labels: { x86-al2-specified-mng }
      overrideBootstrapCommand: |
        #!/bin/bash
        /etc/eks/bootstrap.sh my-cluster \
          --b64-cluster-ca certificate-authority \
          --apiserver-endpoint api-server-endpoint \
          --dns-cluster-ip service-cidr.10 \
          --kubelet-extra-args '--max-pods=my-max-pods-value' \
          --use-max-pods false
  ```

  Per ogni opzione disponibile per il file `eksctl` `config`, consulta [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione su `eksctl`. L'utility `eksctl` crea autonomamente un modello di avvio e popola i dati utente con i dati forniti nel file `config`.

  Crea un gruppo di nodi con il comando seguente.

  ```
  eksctl create nodegroup --config-file=my-nodegroup.yaml
  ```

 **Dati utente in un modello di avvio**   
Specifica le seguenti informazioni nella sezione dati utente del modello di avvio. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` sono facoltativi, ma grazie alla loro definizione lo script `bootstrap.sh` può evitare di effettuare una chiamata a `describeCluster`. Ciò è utile nelle configurazioni di cluster privati o nei cluster in cui si effettuano dimensionamenti frequenti dei nodi. Per ulteriori informazioni sullo `bootstrap.sh` script, vedere il file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) su GitHub.  
+ L'unico argomento richiesto è il nome del cluster (*my-cluster*).
+ Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Questo esempio fornisce un argomento `kubelet` per impostare un valore `max-pods` personalizzato utilizzando lo script `bootstrap.sh` incluso nell'AMI ottimizzata per Amazon EKS. Per assistenza nella scelta di *my-max-pods-value*, consulta . Per ulteriori informazioni su come `maxPods` viene determinato quando si utilizzano i gruppi di nodi gestiti, vedere[Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence).

  ```
  MIME-Version: 1.0
  Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
  
  --==MYBOUNDARY==
  Content-Type: text/x-shellscript; charset="us-ascii"
  
  #!/bin/bash
  set -ex
  /etc/eks/bootstrap.sh my-cluster \
    --b64-cluster-ca certificate-authority \
    --apiserver-endpoint api-server-endpoint \
    --dns-cluster-ip service-cidr.10 \
    --kubelet-extra-args '--max-pods=my-max-pods-value' \
    --use-max-pods false
  
  --==MYBOUNDARY==--
  ```

### Fornire i dati dell’utente per passare gli argomenti al file `Start-EKSBootstrap.ps1` incluso nell’AMI Windows ottimizzata per Amazon EKS
<a name="mng-specify-eks-ami-windows"></a>

Il termine "bootstrapping" indica l'aggiunta di comandi che possono essere eseguiti all'avvio di un'istanza. È possibile passare gli argomenti allo script `Start-EKSBootstrap.ps1` utilizzando `eksctl` senza specificare un modello di avvio. Oppure è possibile farlo specificando le informazioni nella sezione dati utente di un modello di avvio.

Per specificare un ID AMI Windows personalizzato, fai le seguenti considerazioni:
+ Devi utilizzare un modello di avvio e fornire i comandi bootstrap richiesti nella sezione dei dati utente. Per recuperare l'ID Windows desiderato, puoi utilizzare la tabella in [Crea nodi con Windows AMIs ottimizzato](eks-optimized-windows-ami.md).
+ Esistono vari limiti e condizioni. Ad esempio, è necessario aggiungere `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Per ulteriori informazioni, consulta [Limiti e condizioni quando si specifica un ID AMI](#mng-ami-id-conditions).

Specifica le seguenti informazioni nella sezione dati utente del modello di avvio. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `-APIServerEndpoint`, `-Base64ClusterCA` e `-DNSClusterIP` sono facoltativi, ma grazie alla loro definizione lo script `Start-EKSBootstrap.ps1` può evitare di effettuare una chiamata a `describeCluster`.
+ L'unico argomento richiesto è il nome del cluster (*my-cluster*).
+ Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Per ulteriori argomenti, consulta.[Parametri di configurazione dello script di bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**Nota**  
Se utilizzi il servizio personalizzato CIDR, devi specificarlo utilizzando il parametro `-ServiceCIDR`. In caso contrario, la risoluzione DNS per i pod nel cluster avrà esito negativo.

```
<powershell>
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
	 -Base64ClusterCA certificate-authority `
	 -APIServerEndpoint api-server-endpoint `
	 -DNSClusterIP service-cidr.10
</powershell>
```

### Eseguire un'AMI personalizzata a causa di specifici requisiti di sicurezza, conformità o policy interne
<a name="mng-specify-custom-ami"></a>

Per ulteriori informazioni, consulta [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) nella *Guida per l’utente di Amazon EC2*. La specifica di compilazione AMI Amazon EKS contiene risorse e script di configurazione per la creazione di un’AMI Amazon EKS personalizzata basata su Amazon Linux. Per ulteriori informazioni, consulta [Specifica della build AMI di Amazon EKS](https://github.com/awslabs/amazon-eks-ami/) su GitHub. Per creare AMIs installazioni personalizzate con altri sistemi operativi, consulta [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) on GitHub.

Non è possibile utilizzare riferimenti dinamici ai parametri per AMI IDs nei modelli di avvio utilizzati con gruppi di nodi gestiti.

**Importante**  
Quando si specifica un'AMI, Amazon EKS non convalida la versione di Kubernetes incorporata nell'AMI rispetto alla versione del piano di controllo del cluster. Sei responsabile di garantire che la versione Kubernetes della tua AMI personalizzata sia conforme alla politica di modifica della versione di [Kubernetes](https://kubernetes.io/releases/version-skew-policy):  
La `kubelet` versione sui tuoi nodi non deve essere più recente della versione del cluster
La `kubelet` versione sui tuoi nodi deve essere uguale o superiore a 3 versioni secondarie rispetto alla versione del cluster (per la versione Kubernetes `1.28` o successiva) o fino a 2 versioni minori rispetto alla versione del cluster (per la versione Kubernetes o precedente) `1.27`  
La creazione di gruppi di nodi gestiti con violazioni dell'asimmetria delle versioni può comportare:
I nodi non riescono a unirsi al cluster
Comportamento indefinito o incompatibilità delle API
Instabilità del cluster o errori del carico di lavoro
Quando si specifica una AMI, Amazon EKS non unisce alcun dato utente. È l’utente, piuttosto, ad essere responsabile della fornitura dei comandi `bootstrap` richiesti per unire i nodi al cluster. Se i nodi non riescono a unirsi al cluster, le operazioni `CreateNodegroup` e `UpdateNodegroupVersion` di Amazon EKS non vengono eseguite con successo.

## Limiti e condizioni quando si specifica un ID AMI
<a name="mng-ami-id-conditions"></a>

Di seguito sono riportati i limiti e le condizioni per la specifica di un ID AMI con gruppi di nodi gestiti:
+ È necessario creare un nuovo gruppo di nodi per passare dalla specifica o meno di un ID AMI in un modello di avvio.
+ Non riceverai una notifica nella console quando è disponibile una versione AMI più recente. Per aggiornare il gruppo di nodi a una versione AMI più recente, devi creare una nuova versione del modello di avvio con un ID AMI aggiornato. Quindi, è necessario aggiornare il gruppo di nodi con la nuova versione del modello di avvio.
+ I seguenti campi non possono essere impostati nell’API se si specifica un ID AMI:
  +  `amiType` 
  +  `releaseVersion` 
  +  `version` 
+ Se si specifica un ID AMI, qualsiasi set di `taints` nell'API viene applicato in modo asincrono. Per applicare i taint prima che un nodo si unisca al cluster, è necessario passare i taint a `kubelet` utilizzando il flag della riga di comando `--register-with-taints`. Per ulteriori informazioni, consulta [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) nella documentazione Kubernetes.
+ Quando specifichi un ID AMI personalizzato per i gruppi di nodi gestiti da Windows, aggiungilo `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Questa API è necessaria per il funzionamento di DNS.

  1. Apri la mappa di configurazione di AWS IAM Authenticator per modificarla.

     ```
     kubectl edit -n kube-system cm aws-auth
     ```

  1. Aggiungi questa voce all’elenco `groups` sotto ogni `rolearn` associato ai nodi Windows. [La tua mappa di configurazione dovrebbe essere simile a aws-auth-cm-windows .yaml.](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)

     ```
     - eks:kube-proxy-windows
     ```

  1. Salva il file ed esci dall’editor di testo.
+ Per ogni AMI che utilizza un modello di avvio personalizzato, l’impostazione predefinita `HttpPutResponseHopLimit` per i gruppi di nodi gestiti è impostata su `2`.

# Eliminare un gruppo di nodi gestito dal cluster
<a name="delete-managed-node-group"></a>

In questo argomento viene descritto come eliminare un gruppo di nodi gestiti Amazon EKS. Quando elimini un gruppo di nodi gestiti, Amazon EKS imposterà su zero la dimensione minima, massima e desiderata del tuo gruppo Auto Scaling. Questo fa sì che il gruppo di nodi venga dimensionato.

Prima che ogni istanza venga terminata, Amazon EKS invia un segnale per drenare quel nodo. Durante il processo di drenaggio, Kubernetes esegue le seguenti operazioni per ogni pod sul nodo: esegue tutti gli hook del `preStop` ciclo di vita configurati, invia `SIGTERM` segnali ai contenitori, quindi attende il corretto spegnimento. `terminationGracePeriodSeconds` Se il nodo non è stato svuotato dopo 5 minuti, Amazon EKS consente ad Auto Scaling di continuare la chiusura forzata dell'istanza. Dopo che tutte le istanze sono state terminate, il gruppo Auto Scaling viene eliminato.

**Importante**  
Se si elimina un gruppo di nodi gestiti che utilizza un ruolo IAM del nodo non impiegato da nessun altro gruppo di nodi gestiti nel cluster, il ruolo viene rimosso dalla `ConfigMap` `aws-auth`. Se i gruppi di nodi autogestiti nel cluster utilizzano lo stesso ruolo IAM del nodo, i nodi autogestiti passeranno allo stato `NotReady`. Inoltre, anche l’operazione del cluster viene interrotta. Per aggiungere una mappatura per il ruolo da utilizzare solo per i gruppi di nodi autogestiti, consultare la pagina [Creare voci di accesso](creating-access-entries.md), se la versione della piattaforma del cluster corrisponde almeno alla versione minima elencata nella sezione dei prerequisiti della pagina [Grant IAM users access to Kubernetes with EKS access entries](access-entries.md). Se la versione della piattaforma è precedente alla versione minima richiesta per le voci di accesso, è possibile aggiungere nuovamente la voce alla `ConfigMap` `aws-auth`. Per ulteriori informazioni, digita `eksctl create iamidentitymapping --help` nel terminale.

È possibile creare un gruppo di nodi gestiti con i seguenti strumenti:
+  [`eksctl`](#eksctl-delete-managed-nodegroup) 
+  [Console di gestione AWS](#console-delete-managed-nodegroup) 
+  [AWS CLI](#awscli-delete-managed-nodegroup) 

## `eksctl`
<a name="eksctl-delete-managed-nodegroup"></a>

 **Eliminare un gruppo di nodi gestiti con `eksctl`** 

Inserire il seguente comando. Sostituisci ogni `<example value>` con i valori in tuo possesso.

```
eksctl delete nodegroup \
  --cluster <my-cluster> \
  --name <my-mng> \
  --region <region-code>
```

Per ulteriori opzioni, consulta [Eliminazione e svuotamento dei gruppi di nodi](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) nella documentazione di `eksctl`.

## Console di gestione AWS
<a name="console-delete-managed-nodegroup"></a>

 **Eliminare un gruppo di nodi gestiti con Console di gestione AWS ** 

1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Nella pagina **Cluster**, scegli il cluster che contiene il gruppo di nodi da eliminare.

1. Nella pagina del cluster selezionata, scegli la scheda **Calcolo**.

1. Nella sezione **Gruppi di nodi**, scegliere il gruppo di nodi da eliminare. Scegli **Elimina**.

1. Nella finestra di dialogo di conferma di **Eliminazione del gruppo di nodi**, inserisci il nome del gruppo di nodi. Scegli **Elimina**.

## AWS CLI
<a name="awscli-delete-managed-nodegroup"></a>

 **Eliminare un gruppo di nodi gestito con AWS CLI** 

1. Inserire il seguente comando. Sostituisci ogni `<example value>` con i valori in tuo possesso.

   ```
   aws eks delete-nodegroup \
     --cluster-name <my-cluster> \
     --nodegroup-name <my-mng> \
     --region <region-code>
   ```

1. Se `cli_pager=` è impostato nella configurazione CLI, usa i tasti freccia sulla tastiera per scorrere l'output della risposta. Premere il tasto `q` al termine.

   Per ulteriori opzioni, consultate il ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` comando nella * AWS CLI Command* Reference.