

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

# Aggiornare uno AWS CloudFormation stack di nodi
<a name="update-stack"></a>

Questo argomento descrive come aggiornare uno stack di nodi AWS CloudFormation autogestito esistente con una nuova AMI. È possibile utilizzare questa procedura per aggiornare i nodi a una nuova versione di Kubernetes in seguito all'aggiornamento di un cluster. In caso contrario, è possibile eseguire l'aggiornamento all'AMI ottimizzata per Amazon EKS più recente per una versione Kubernetes esistente.

**Importante**  
In questo argomento vengono descritti gli aggiornamenti dei nodi per i gruppi di nodi autogestiti. Per informazioni sull’utilizzo di [Simplify node lifecycle con gruppi di nodi gestiti](managed-node-groups.md), consulta [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md).

L'ultimo AWS CloudFormation modello di nodo Amazon EKS predefinito è configurato per avviare un'istanza con la nuova AMI nel cluster prima di rimuoverne una vecchia, una alla volta. Questa configurazione garantisce sempre il conteggio desiderato del gruppo Auto Scaling delle istanze attive nel cluster durante l’aggiornamento in sequenza.

**Nota**  
Questo metodo non è supportato per i gruppi di nodi creati con `eksctl`. Se è stato creato il cluster o il gruppo di nodi con `eksctl`, consultare [Esegui la migrazione delle applicazioni a un nuovo gruppo di nodi](migrate-stack.md).

1. Determinare il provider DNS del cluster.

   ```
   kubectl get deployments -l k8s-app=kube-dns -n kube-system
   ```

   Di seguito viene riportato un output di esempio. Questo cluster utilizza CoreDNS per la risoluzione DNS, ma il cluster può invece restituire `kube-dns`. L’output potrebbe avere un aspetto diverso a seconda della versione di `kubectl` che stai utilizzando.

   ```
   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   coredns   1         1         1            1           31m
   ```

1. Se l'implementazione corrente è in esecuzione per un numero di volte inferiore a 2 repliche, scalare la distribuzione a 2 repliche. Sostituire *coredns* con `kube-dns` se l'output del comando precedente ha avuto tale risultato.

   ```
   kubectl scale deployments/coredns --replicas=2 -n kube-system
   ```

1. (Facoltativo) Se si sta utilizzando il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Kubernetes, dimensiona l’implementazione fino a zero (0) repliche per evitare azioni di dimensionamento conflittuali.

   ```
   kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
   ```

1.  Determina il tipo di istanza e il numero di istanze desiderato del gruppo di nodi corrente. Questi valori vengono inseriti in un secondo momento, quando si aggiorna il AWS CloudFormation modello per il gruppo.

   1. Apri la console Amazon EC2 all'indirizzo. https://console.aws.amazon.com/ec2/

   1. Nel pannello di navigazione a sinistra, scegli **Launch Configurations** (Configurazioni di avvio) e prendi nota del tipo di istanza per la configurazione di avvio del nodo esistente.

   1. Nel pannello di navigazione a sinistra, scegli **Auto Scaling Groups** (Gruppi Auto Scaling) e prendi nota del conteggio delle istanze **Desired** (Desiderato) per il gruppo Auto Scaling del nodo.

1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/).

1. Selezionare la pila del gruppo di nodi, quindi scegliere **Aggiorna**.

1. Selezionare **Replace current template (Sostituisci modello corrente)** e scegliere **Amazon S3 URL (URL Amazon S3)**.

1. Per **l'URL di Amazon S3**, incolla il seguente URL nell'area di testo per assicurarti di utilizzare la versione più recente del modello di nodo AWS CloudFormation . Quindi scegliere **Next (Successivo)**:

   ```
   https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
   ```

1. Nella pagina **Specify stack details (Specifica dettagli pila)**, compilare i parametri seguenti e scegliere **Next (Successivo)**:
   +  **NodeAutoScalingGroupDesiredCapacity**— Inserisci il numero di istanze desiderato che hai registrato nel [passaggio precedente](#existing-worker-settings-step). In alternativa, inserire il nuovo numero desiderato di nodi come riferimento del dimensionamento quando viene aggiornata la pila.
   +  **NodeAutoScalingGroupMaxSize**— Inserisci il numero massimo di nodi a cui il gruppo Auto Scaling del nodo può scalare orizzontalmente. Questo valore deve essere almeno un nodo in più rispetto alla capacità desiderata. Ciò consente di eseguire un aggiornamento in sequenza dei nodi senza ridurre il numero di nodi durante l'aggiornamento.
   +  **NodeInstanceType**— Scegli il tipo di istanza che hai registrato nel [passaggio precedente](#existing-worker-settings-step). In alternativa, scegliere un tipo di istanza diverso per i nodi. Prima di scegliere un tipo di istanza diverso, esamina [Choose an optimal Amazon EC2 node instance type](choosing-instance-type.md). Ogni tipo di istanza Amazon EC2 supporta un numero massimo di interfacce di rete elastiche (interfaccia di rete) e ogni interfaccia di rete supporta un numero massimo di indirizzi IP. Poiché a ogni nodo worker e pod è assegnato il proprio indirizzo IP, è importante scegliere un tipo di istanza che supporti il numero massimo di pod che si desidera eseguire su ciascun nodo Amazon EC2. Per un elenco del numero di interfacce di rete e di indirizzi IP supportati dai tipi di istanza, consulta [ Indirizzi IP per interfaccia di rete e per tipo di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Ad esempio, il tipo di istanza `m5.large` supporta un massimo di 30 indirizzi IP per il nodo (worker) e per i pod.
**Nota**  
I tipi di istanza supportati per la versione più recente del [plug-in CNI di Amazon VPC per Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) sono riportati in [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) su GitHub. Potrebbe essere necessario aggiornare la versione del plugin CNI di Amazon VPC per Kubernetes per utilizzare i tipi di istanze supportati più recenti. Per ulteriori informazioni, consulta [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md).
**Importante**  
Alcuni tipi di istanze potrebbero non essere disponibili in tutte le AWS regioni.
   +  **NodeImageIdSSMParam**— Il parametro Amazon EC2 Systems Manager dell'ID AMI a cui desideri eseguire l'aggiornamento. Il valore seguente utilizza l’AMI ottimizzata per Amazon EKS più recente per Kubernetes versione `1.35`.

     ```
     /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id
     ```

     Puoi sostituirlo *1.35* con una [versione della piattaforma che sia la stessa](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html). In alternativa, può essere fino a una versione precedente alla versione di Kubernetes in esecuzione sul piano di controllo. Si consiglia di mantenere i nodi alla stessa versione del piano di controllo. Puoi anche sostituirlo *amazon-linux-2* con un altro tipo di AMI. Per ulteriori informazioni, consulta [Recupera le AMI Amazon Linux consigliate IDs](retrieve-ami-id.md).
**Nota**  
L'utilizzo del parametro Amazon EC2 Systems Manager consente di aggiornare i nodi in futuro senza dover cercare e specificare un ID AMI. Se lo AWS CloudFormation stack utilizza questo valore, qualsiasi aggiornamento dello stack avvia sempre l'ultima AMI ottimizzata Amazon EKS consigliata per la versione di Kubernetes specificata. Questo è il caso anche se non si modificano valori nel modello.
   +  **NodeImageId**— Per utilizzare la tua AMI personalizzata, inserisci l'ID dell'AMI da utilizzare.
**Importante**  
Questo valore sostituisce qualsiasi valore specificato per. **NodeImageIdSSMParam** Se desideri utilizzare il **NodeImageIdSSMParam**valore, assicurati che il valore per **NodeImageId**sia vuoto.
   +  **Disabilita IMDSv1**: per impostazione predefinita, ogni nodo supporta Instance Metadata Service versione 1 (IMDSv1) e IMDSv2. Tuttavia, è possibile disabilitare IMDSv1. Seleziona **true** se non desideri utilizzare IMDSv1 alcun nodo o pod programmato nel gruppo di nodi. Per ulteriori informazioni su IMDS, consulta [Configurazione del servizio di metadati dell’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Se hai implementato i ruoli IAM per gli account di servizio, assegna le autorizzazioni necessarie direttamente a tutti i Pod che richiedono l'accesso ai servizi. AWS In questo modo, nessun Pod del cluster richiede l'accesso a IMDS per altri motivi, come il recupero della regione corrente. AWS Quindi, puoi anche disabilitare l'accesso ai Pod che non utilizzano IMDSv2 la rete host. Per ulteriori informazioni, consulta [Limita l'accesso al profilo di 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).

1. (Facoltativo) Nella pagina **Options (Opzioni)**, contrassegna con dei tag le risorse della pila. Scegli **Next (Successivo)**.

1. Nella pagina **Verifica**, esaminare le informazioni, confermare che la pila è in grado di creare risorse IAM, quindi scegliere **Aggiorna pila**.
**Nota**  
L'aggiornamento di ogni nodo nel cluster richiede diversi minuti. Attendi il completamento dell'aggiornamento di tutti i nodi prima di eseguire la procedura successiva.

1. Se il provider DNS del cluster è `kube-dns`, riduci orizzontalmente l’implementazione di `kube-dns` a una replica.

   ```
   kubectl scale deployments/kube-dns --replicas=1 -n kube-system
   ```

1. (Facoltativo) Se si sta utilizzando il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Kubernetes, dimensionare l'implementazione al numero di repliche desiderato.

   ```
   kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
   ```

1. (Facoltativo) Verifica che si sta utilizzando la versione più recente del [plugin CNI di Amazon VPC per Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Potrebbe essere necessario aggiornare la versione del plugin CNI di Amazon VPC per Kubernetes per utilizzare i tipi di istanze supportati più recenti. Per ulteriori informazioni, consulta [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md).