

 **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à.

# 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.