**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à. # Aggiornamento dei nodi autogestiti per il tuo cluster Quando viene rilasciata una nuova AMI ottimizzata per Amazon EKS, considerare la sostituzione dei nodi nel gruppo di nodi autogestiti con la nuova AMI. Analogamente, se hai aggiornato la versione Kubernetes per il tuo cluster Amazon EKS, aggiornare i nodi per l'utilizzo di nodi con la stessa versione Kubernetes. **Importante** In questo argomento vengono descritti gli aggiornamenti dei nodi per i gruppi di nodi autogestiti. Se utilizzi [gruppi di nodi gestiti](managed-node-groups.md), consulta [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md). Esistono due modi di base per aggiornare i gruppi di nodi autogestiti nei cluster per utilizzare una nuova AMI: ** [Migrate applications to a new node group](migrate-stack.md) ** : crea un nuovo gruppo di nodi ed esegui la migrazione dei pod verso questo gruppo. La migrazione a un nuovo gruppo di nodi è più aggraziata del semplice aggiornamento dell’ID AMI in una pila AWS CloudFormation esistente. Questo perché il processo di migrazione [esclude](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) il vecchio gruppo di nodi come `NoSchedule` e svuota i nodi dopo che una nuova pila è pronta ad accettare il carico di lavoro del pod esistente. ** [Aggiornamento di una pila di nodi AWS CloudFormation](update-stack.md) ** Aggiorna la pila AWS CloudFormation per un gruppo di nodi esistente in modo che utilizzi la nuova AMI. Questo metodo non è supportato per i gruppi di nodi creati con `eksctl`. # Esegui la migrazione delle applicazioni a un nuovo gruppo di nodi Questo argomento consente di creare un nuovo gruppo di nodi, di migrare correttamente le applicazioni esistenti al nuovo gruppo e di rimuovere il precedente gruppo di nodi dal cluster. È possibile eseguire la migrazione a un nuovo gruppo di nodi utilizzando `eksctl` o la Console di gestione AWS. + [`eksctl`](#eksctl_migrate_apps) + [Console di gestione AWS e AWS CLI](#console_migrate_apps) ## `eksctl` **Esegui la migrazione delle applicazioni a un nuovo gruppo di nodi con `eksctl`** Per ulteriori informazioni sull’utilizzo di eksctl per la migrazione, consulta [Unmanaged nodegroups](https://eksctl.io/usage/nodegroup-unmanaged/) nella documentazione di `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`. **Nota** Questa procedura funziona solo per i cluster e per i gruppi di nodi creati con `eksctl`. 1. Recuperare il nome dei gruppi di nodi esistenti, sostituendo *my-cluster* con il nome del cluster. ``` eksctl get nodegroups --cluster=my-cluster ``` Di seguito viene riportato un output di esempio: ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Avvia un nuovo gruppo di nodi con `eksctl` con il comando seguente. Nel comando, sostituire ogni *example value* con i propri valori. Il numero di versione non può essere successivo alla versione Kubernetes per il piano di controllo. Inoltre, non può essere più di due versioni secondarie precedenti rispetto a quella Kubernetes per il piano di controllo. Si consiglia di utilizzare la stessa versione del piano di controllo. 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 [Limitazione dell’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). Per bloccare l’accesso del pod a IMDS, aggiungere l’opzione `--disable-pod-imds` al seguente comando. **Nota** Per ulteriori flag disponibili e relative descrizioni, vedere https://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Quando il comando precedente viene completato, verificare che tutti i nodi abbiano raggiunto lo stato `Ready` con il comando seguente: ``` kubectl get nodes ``` 1. Eliminare il gruppo di nodi originale con il comando seguente. Nel comando, sostituire ogni *example value* con i nomi dei cluster e dei gruppi di nodi: ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## Console di gestione AWS e AWS CLI **Migra le tue applicazioni in un nuovo gruppo di nodi con Console di gestione AWS e AWS CLI** 1. Avvia un nuovo gruppo di nodi seguendo i passaggi descritti in [Create self-managed Amazon Linux nodes](launch-workers.md). 1. Al termine della creazione dello stack, selezionalo nella console e scegli **Output**. 1. Registra il **NodeInstanceRole**per il gruppo di nodi che è stato creato. Ciò è necessario per aggiungere i nuovi nodi Amazon EKS al cluster. **Nota** Se si dispone di policy IAM aggiuntive associate al vecchio ruolo IAM del gruppo di nodi, associa le stesse policy al nuovo ruolo IAM del gruppo di nodi per mantenere tale funzionalità nel nuovo gruppo. Questo vale se hai aggiunto le autorizzazioni per il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) Kubernetes, ad esempio. 1. Aggiorna i gruppi di sicurezza per entrambi i gruppi di nodi in modo che possano comunicare tra loro. Per ulteriori informazioni, consulta [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). 1. Registra il gruppo di sicurezza IDs per entrambi i gruppi di nodi. Questo viene mostrato come **NodeSecurityGroup**valore negli output dello AWS CloudFormation stack. È possibile utilizzare i seguenti comandi AWS CLI per ottenere il gruppo di sicurezza IDs dai nomi dello stack. In questi comandi, `oldNodes` c'è il nome AWS CloudFormation dello stack del vecchio stack di nodi ed `newNodes` è il nome dello stack verso cui state migrando. Sostituisci ogni *example value* con i valori in tuo possesso. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Aggiungi regole in ingresso per ciascun gruppo di sicurezza del nodo in modo da accettare il traffico tra loro. I seguenti comandi AWS CLI aggiungono regole in entrata a ciascun gruppo di sicurezza che consentono tutto il traffico su tutti i protocolli dell'altro gruppo di sicurezza. Questo consente ai pod in ogni gruppo di nodi di comunicare tra loro durante la migrazione del carico di lavoro verso il nuovo gruppo. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Modifica la configmap `aws-auth` per mappare il nuovo ruolo dell’istanza del nodo in RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Aggiungi una nuova voce `mapRoles` per il nuovo gruppo di nodi. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` [Sostituisci lo *ARN of instance role (not instance profile)* snippet con il **NodeInstanceRole**valore registrato nel passaggio precedente.](#node-instance-role-step) Quindi, salva e chiudi il file per applicare la configmap aggiornata. 1. Guarda lo stato dei nodi e attendi fino a quando i nuovi nodi si uniscono al cluster e raggiungono lo stato `Ready`. ``` kubectl get nodes --watch ``` 1. (Facoltativo) Se stai utilizzando il [Cluster Autoscaler Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), 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. Utilizzare il comando seguente per il taint di ciascuno dei nodi che si desidera rimuovere con `NoSchedule`. In questo modo i nuovi pod non vengono pianificati o riprogrammati sui nodi che stai sostituendo. Per ulteriori informazioni, consulta [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nella documentazione di Kubernetes. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Se aggiorni i nodi a una nuova versione di Kubernetes, puoi identificare ed eseguire il taint di tutti i nodi di una determinata versione di Kubernetes (in questo caso, `1.33`) con il seguente frammento di codice. Il numero di versione non può essere successivo alla versione Kubernetes del piano di controllo. Inoltre, non può essere più di due versioni secondarie precedenti rispetto alla versione Kubernetes del piano di controllo. Si consiglia di utilizzare la stessa versione del piano di controllo. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Determina 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`): ``` 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 `kubedns` se l'output del comando precedente ha avuto tale risultato. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Svuotare ciascuno dei nodi che si desidera rimuovere dal cluster con il comando seguente: ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Se stai aggiornando i tuoi nodi a una nuova versione di Kubernetes, identifica e svuota tutti i nodi di una particolare versione di Kubernetes (in questo caso) con il seguente frammento di codice. *1.33* ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Una volta terminata tale operazione, revocare le regole in ingresso del gruppo di sicurezza autorizzate in precedenza. Quindi, elimina lo stack per terminare le istanze. AWS CloudFormation **Nota** Se hai collegato politiche IAM aggiuntive al tuo vecchio ruolo IAM del gruppo di nodi, ad esempio aggiungendo autorizzazioni per [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), scollega quelle politiche aggiuntive dal ruolo prima di poter eliminare lo stack. AWS CloudFormation 1. Revocare le regole in ingresso create in precedenza per i gruppi di sicurezza dei nodi. In questi comandi, `oldNodes` c'è il nome dello AWS CloudFormation stack del tuo vecchio stack di nodi ed `newNodes` è il nome dello stack verso cui stai migrando. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/). 1. Selezionare la pila del nodo precedente. 1. Scegli **Elimina**. 1. Nella finestra di dialogo di conferma **Delete stack** (Elimina stack) scegliere **Delete stack**.(Elimina stack). 1. Modifica il configmap `aws-auth` per rimuovere il precedente ruolo dell’istanza del nodo da RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Eliminare la voce `mapRoles` per il precedente gruppo di nodo. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Salvare e chiudere il file per applicare la configmap aggiornata. 1. (Facoltativo) Se si sta utilizzando il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) Kubernetes, dimensionare l’implementazione a 1 replica. **Nota** È inoltre necessario applicare i tag al nuovo gruppo Auto Scaling in modo appropriato (ad esempio, `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) e aggiornare il comando di implementazione di Cluster Autoscaler per puntare al nuovo gruppo Auto Scaling contrassegnato. [Per ulteriori informazioni, consulta Cluster Autoscaler on. AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws) ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Facoltativo) Verifica se stai utilizzando la versione più recente del [plug-in CNI di Amazon VPC per Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Potrebbe essere necessario aggiornare la versione CNI 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). 1. Se il cluster utilizza `kube-dns` per la risoluzione DNS (vedi [[migrate-determine-dns-step]](#migrate-determine-dns-step)), riduci orizzontalmente l’implementazione `kube-dns` a 1 replica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Aggiornare uno AWS CloudFormation stack di nodi 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).