**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à. # Gestione autonoma dei nodi con nodi autogestiti Un cluster contiene uno o più nodi Amazon EC2 su cui sono pianificati i pod. I nodi Amazon EKS vengono eseguiti nell'account AWS e si connettono al piano di controllo del cluster tramite l'endpoint del server API del cluster. La loro fatturazione è basata sui prezzi Amazon EC2. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/). Un cluster può contenere diversi gruppi di nodi. Ciascun gruppo di nodi contiene uno o più nodi implementati in un [gruppo Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). Il tipo di istanza dei nodi all’interno del gruppo può variare, ad esempio quando si utilizza la [selezione del tipo di istanza basata sugli attributi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) con [Karpenter](https://karpenter.sh/). Tutte le istanze di un gruppo di nodi devono utilizzare il [ruolo IAM del nodo Amazon EKS](create-node-role.md). Amazon EKS fornisce Amazon Machine Image (AMI) specializzate chiamate AMI ottimizzate per Amazon EKS. Le AMI sono configurate per funzionare con Amazon EKS. I loro componenti includono `containerd`, `kubelet` e l'AWS IAM Authenticator. L’AMI contiene anche uno [script di bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) specializzato che consente di individuare e connettersi automaticamente al piano di controllo del cluster. Se si limita l'accesso all'endpoint pubblico del cluster utilizzando blocchi CIDR, è consigliabile abilitare anche l'accesso agli endpoint privati. In questo modo i nodi possono comunicare con il cluster. Senza l'endpoint privato abilitato, i blocchi CIDR specificati per l'accesso pubblico devono includere le origini di uscita dal VPC. Per ulteriori informazioni, consulta [Endpoint del server API del cluster](cluster-endpoint.md). Per aggiungere nodi autogestiti al cluster Amazon EKS, consultare gli argomenti che seguono. Se si avviano manualmente i nodi autogestiti, è necessario aggiungere il seguente tag a ciascun nodo, assicurandosi al contempo che `` corrisponda al cluster. Per ulteriori informazioni, consultare [Aggiunta ed eliminazione di tag in una singola risorsa](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Se si seguono i passaggi della guida, il tag richiesto viene aggiunto al nodo per conto dell'utente. | Chiave | Valore | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **Importante** I tag nel servizio di metadati di istanza (IMDS) di Amazon EC2 non sono compatibili con i nodi EKS. Quando i tag dei metadati delle istanze sono abilitati, è impedito l’uso di barre (“/”) nei valori dei tag. Tale limitazione può causare errori nell’avvio delle istanze, in particolare quando si utilizzano strumenti di gestione dei nodi come Karpenter o un dispositivo di dimensionamento automatico dei cluster, poiché questi servizi si basano solo su tag contenenti barre per una corretta funzionalità. Per ulteriori informazioni sui nodi da un prospettiva Kubernetes generale, consultare [Nodi](https://kubernetes.io/docs/concepts/architecture/nodes/) nella documentazione Kubernetes. **Topics** + [Crea nodi Amazon Linux autogestiti](launch-workers.md) + [Crea nodi autogestiti Bottlerocket](launch-node-bottlerocket.md) + [Crea nodi Microsoft Windows autogestiti](launch-windows-workers.md) + [Creazione di nodi Ubuntu Linux autogestiti](launch-node-ubuntu.md) + [Aggiornamento dei nodi autogestiti per il tuo cluster](update-workers.md) # Crea nodi Amazon Linux autogestiti In questo argomento viene descritto come avviare gruppi con scalabilità automatica di nodi Linux che si registrano con il cluster Amazon EKS. Dopo che i nodi vengono aggiunti al cluster, puoi implementare applicazioni Kubernetes per gli stessi. Puoi anche avviare nodi Amazon Linux autogestiti con `eksctl` o. Console di gestione AWS Se devi avviare nodi su AWS Outposts, consulta. [Crea nodi Amazon Linux su AWS Outposts](eks-outposts-self-managed-nodes.md) + Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Crea un cluster Amazon EKS.](create-cluster.md). Se hai delle sottoreti nella AWS regione in cui hai abilitato AWS Outposts, AWS Wavelength o AWS Local Zones, tali sottoreti non devono essere state passate al momento della creazione del cluster. + 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). + Conoscenza delle considerazioni elencate in [Scegli un tipo di istanza di EC2 nodo Amazon ottimale](choosing-instance-type.md). A seconda del tipo di istanza scelto, potrebbero esserci ulteriori prerequisiti per il cluster e il VPC. È possibile avviare nodi Linux autogestiti con uno dei seguenti modi: + [`eksctl`](#eksctl_create_managed_amazon_linux) + [Console di gestione AWS](#console_create_managed_amazon_linux) ## `eksctl` **Avvia nodi Linux autogestiti utilizzando `eksctl`** 1. Installa la versione `0.215.0` o successiva dello strumento da riga di `eksctl` comando installato sul tuo dispositivo o. AWS CloudShell Per l’installazione o l’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), ti consigliamo, 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. Il comando seguente crea un gruppo di nodi in un cluster esistente. Sostituisci *al-nodes* con un nome per il 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. Sostituisci *my-cluster* con il nome del cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster. Sostituisci i *example value* rimanenti con i valori in tuo possesso. Per impostazione predefinita, i nodi vengono creati con la stessa versione Kubernetes del piano di controllo. Prima di scegliere un valore per`--node-type`, consulta [Scegli un tipo di istanza Amazon EC2 node ottimale](choosing-instance-type.md). Sostituiscilo *my-key* con il nome della tua coppia di EC2 chiavi Amazon o della tua chiave pubblica. Questa chiave viene utilizzata per eseguire il SSH nei nodi dopo il loro avvio. Se non disponi già di una coppia di EC2 chiavi Amazon, puoi crearne una in Console di gestione AWS. Per ulteriori informazioni, consulta le [coppie di EC2 chiavi Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Amazon EC2 User Guide*. Crea il tuo gruppo di nodi con il comando seguente. **Importante** Se desideri distribuire un gruppo di nodi nelle sottoreti AWS Outposts, Wavelength o Local Zone, ci sono altre considerazioni: Le sottoreti non devono essere state trasmesse al momento della creazione del cluster. È necessario creare il gruppo di nodi con un file di configurazione, specificando le sottoreti e ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`. Per ulteriori informazioni, consulta [Creazione di un gruppo di nodi da un file di configurazione](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e lo [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione di `eksctl`. ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` Per implementare un gruppo di nodi che: + può assegnare un numero significativamente più elevato di indirizzi IP a pod rispetto alla configurazione predefinita, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md). + può assegnare gli indirizzi `IPv4` a pod da un altro intervallo CIDR rispetto a quello dell’istanza, consulta [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md). + può assegnare gli indirizzi `IPv6` a pod e servizi, consulta [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md). + non dispone di accesso a Internet in uscita, consulta [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md). Per un elenco completo di tutte le opzioni e i valori predefiniti disponibili, immetti il comando seguente. ``` eksctl create nodegroup --help ``` Se i nodi di lavoro non riescono a unirsi al cluster, consulta [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) nel capitolo sulla risoluzione dei problemi. Di seguito viene riportato un output di esempio. Durante la creazione dei nodi vengono generate diverse righe. Una delle ultime righe di output è simile alla seguente riga di esempio. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Facoltativo) implementare [un’applicazione di esempio](sample-deployment.md) per testare il cluster e i nodi Linux. 1. 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 delle EC2 istanze Amazon (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). ## Console di gestione AWS **Passaggio 1: avvia i nodi Linux autogestiti utilizzando la Console di gestione AWS ** 1. Scarica l'ultima versione del modello. AWS CloudFormation ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. Attendi che lo stato del cluster risulti `ACTIVE`. Se vengono avviati prima che il cluster sia attivo, i nodi non riescono a effettuare la registrazione al cluster e sarà necessario riavviarli. 1. Apri la [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/). 1. Scegli **Crea stack** e quindi seleziona **Con nuove risorse (standard)**. 1. In **Specifica modello**, seleziona **Carica un file di modello** e **Scegli file**. 1. Seleziona il file `amazon-eks-nodegroup.yaml` scaricato. 1. Seleziona **Successivo**. 1. Nella pagina **Specifica i dettagli dello stack**, immetti i parametri seguenti e scegli **Successivo**: + **Nome dello stack**: scegli un nome per lo stack. AWS CloudFormation Ad esempio, è possibile chiamarlo *my-cluster-nodes*. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno della AWS regione e AWS dell'account in cui stai creando il cluster. + **ClusterName**: inserisci il nome che hai usato per creare il cluster Amazon EKS. Questo nome deve corrispondere a quello del cluster o i nodi non verranno aggiunti al cluster. + **ClusterControlPlaneSecurityGroup**: scegli il **SecurityGroups**valore dall' AWS CloudFormation output che hai generato quando hai creato il tuo [VPC](creating-a-vpc.md). Nella procedura seguente viene illustrata un’operazione per recuperare il gruppo applicabile. 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Scegli il nome del cluster. 1. Scegli la scheda **Reti**. 1. Utilizza il valore dei **gruppi di sicurezza aggiuntivi** come riferimento quando selezioni dall'**ClusterControlPlaneSecurityGroup**elenco a discesa. + **ApiServerEndpoint**: Inserite l'API Server Endpoint per il vostro cluster EKS. È possibile trovarlo nella sezione Dettagli della console EKS Cluster + **CertificateAuthorityData**: Immettete i dati dell'Autorità di certificazione codificati in base 64, disponibili anche nella sezione Dettagli della console EKS Cluster. + **ServiceCidr**: Inserisci l'intervallo CIDR utilizzato per allocare gli indirizzi IP ai servizi Kubernetes all'interno del cluster. Si trova nella scheda di rete della console del cluster EKS. + **AuthenticationMode**: Seleziona la modalità di autenticazione in uso nel cluster EKS esaminando la scheda di accesso all'interno della console del cluster EKS. + **NodeGroupName**: Inserisci un nome per il tuo gruppo di nodi. Questo nome può essere utilizzato in seguito per identificare il gruppo di nodi con dimensionamento automatico creato per i tuoi 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. + **NodeAutoScalingGroupMinSize**: Inserisci il numero minimo di nodi su cui il gruppo Auto Scaling del nodo può scalare. + **NodeAutoScalingGroupDesiredCapacity**: Inserisci il numero di nodi desiderato su cui scalare quando viene creato lo stack. + **NodeAutoScalingGroupMaxSize**: Inserisci il numero massimo di nodi su cui il gruppo Auto Scaling del nodo può scalare orizzontalmente. + **NodeInstanceType**: scegli un tipo di istanza per i tuoi nodi. Per ulteriori informazioni, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md). + **NodeImageIdSSMParam**: precompilato con il parametro Amazon EC2 Systems Manager di una recente AMI Amazon Linux 2023 ottimizzata per Amazon EKS per una versione variabile di Kubernetes. Se si desidera utilizzare una diversa versione secondaria di Kubernetes supportata da Amazon EKS, è possibile sostituire *1.XX* con una [versione supportata](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) differente. Si consiglia di specificare la stessa versione Kubernetes del cluster. Puoi anche sostituirlo *amazon-linux-2023* con un altro tipo di AMI. Per ulteriori informazioni, consulta [Recupera le AMI Amazon Linux consigliate IDs](retrieve-ami-id.md). **Nota** I nodi Amazon EKS AMIs sono basati su Amazon Linux. Puoi tenere traccia degli eventi di sicurezza o privacy per Amazon Linux 2023 nell'[Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) o abbonarti al [feed RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associato. Gli eventi di sicurezza e privacy includono una panoramica del problema, quali sono i pacchetti interessati e come aggiornare le istanze per risolvere il problema. + **NodeImageId**: (Facoltativo) Se utilizzi un'AMI personalizzata (anziché un'AMI ottimizzata per Amazon EKS), inserisci un ID AMI del nodo per la tua AWS regione. Se specifichi un valore qui, questo sostituisce tutti i valori nel **NodeImageIdSSMParam**campo. + **NodeVolumeSize**: Specificate la dimensione del volume root per i nodi, in GiB. + **NodeVolumeType**: Specificate un tipo di volume root per i nodi. + **KeyName**: inserisci il nome di una coppia di chiavi Amazon EC2 SSH che puoi usare per connetterti tramite SSH ai tuoi nodi dopo il loro avvio. Se non disponi già di una coppia di EC2 chiavi Amazon, puoi crearne una in Console di gestione AWS. Per ulteriori informazioni, consulta le [coppie di EC2 chiavi Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Amazon EC2 User Guide*. + **VpcId**: inserisci l'ID per il [VPC](creating-a-vpc.md) che hai creato. + **Sottoreti**: scegli le sottoreti create per il VPC. Se hai creato il VPC utilizzando i passaggi descritti in [Create an Amazon VPC for your Amazon EKS cluster](creating-a-vpc.md), specifica solo le sottoreti private all’interno del VPC per avviare i nodi. È possibile visualizzare le sottoreti private aprendo ogni collegamento relativo alla sottorete dalla scheda **Reti** del cluster. **Importante** Se una qualsiasi delle sottoreti è pubblica, devi abilitare l’impostazione di assegnazione automatica degli indirizzi IP pubblici. Se l'impostazione non è abilitata per la sottorete pubblica, a tutti i nodi distribuiti in quella sottorete pubblica non verrà assegnato un indirizzo IP pubblico e non saranno in grado di comunicare con il cluster o altri servizi. AWS Se la sottorete è stata distribuita prima del 26 marzo 2020 utilizzando uno dei [modelli AWS CloudFormation VPC di Amazon EKS](creating-a-vpc.md) o utilizzando`eksctl`, l'assegnazione automatica degli indirizzi IP pubblici è disabilitata per le sottoreti pubbliche. Per informazioni su come abilitare l'assegnazione di indirizzi IP pubblici per una sottorete, consulta [Modifica](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) dell'attributo di indirizzamento pubblico per la sottorete. IPv4 Se il nodo viene distribuito in una sottorete privata, è in grado di comunicare con il cluster e altri AWS servizi tramite un gateway NAT. Se le sottoreti non hanno accesso a Internet, leggi con attenzione le considerazioni e i passaggi aggiuntivi descritti in [Deploy private clusters with limited internet access](private-clusters.md). Se si AWS selezionano le sottoreti Outposts, Wavelength o Local Zone, le sottoreti non devono essere state passate al momento della creazione del cluster. 1. Seleziona le opzioni desiderate nella pagina **Configura opzioni dello stack**, quindi scegli **Next** (Avanti). 1. Seleziona la casella di controllo a sinistra di **Riconosco** che potrebbe creare risorse IAM. AWS CloudFormation , quindi scegli **Create stack**. 1. Al termine della creazione dello stack, selezionalo nella console e scegli **Output**. Se utilizzi le `EKS API` o le modalità di `EKS API and ConfigMap` autenticazione, questo è l'ultimo passaggio. 1. Se stai usando la modalità di `ConfigMap` autenticazione, registra il **NodeInstanceRole**per il gruppo di nodi che è stato creato. **Fase 2: abilitazione dell’aggiunta di nodi al cluster** **Nota** I due passaggi seguenti sono necessari solo se si utilizza la modalità di autenticazione Configmap all'interno del cluster EKS. Inoltre, se hai avviato nodi all'interno di un VPC privato senza accesso a Internet in uscita, assicurati di consentire ai nodi di unirsi al cluster dall'interno del VPC. 1. Verifica se disponi già di una `ConfigMap` per `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Se ti viene mostrata una `ConfigMap` per `aws-auth`, aggiornala se necessario. 1. Apri `ConfigMap` per la modifica. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Aggiungi una nuova voce `mapRoles`, se necessario. Impostate il `rolearn` valore sul **NodeInstanceRole**valore registrato nella procedura precedente. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Salva il file ed esci dall’editor di testo. 1. Se hai ricevuto un messaggio di errore che indica "`Error from server (NotFound): configmaps "aws-auth" not found`", applica lo `ConfigMap` di stock. 1. Scarica la mappa di configurazione. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. Nel `aws-auth-cm.yaml` file, impostate il `rolearn` **NodeInstanceRole**valore sul valore registrato nella procedura precedente. Per eseguire questa operazione, utilizza un editor di testo o sostituisci *my-node-instance-role* eseguendo il comando seguente: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Applica la configurazione. L’esecuzione di questo comando potrebbe richiedere alcuni minuti. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Guarda lo stato dei nodi e attendi che raggiungano lo stato `Ready`. ``` kubectl get nodes --watch ``` Inserisci `Ctrl`\$1`C` per tornare a un prompt dello shell (interprete di comandi). **Nota** Se ricevi qualsiasi altro errore di tipo di risorsa o autorizzazione, consulta la sezione [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized) nell’argomento relativo alla risoluzione dei problemi. Se i nodi di lavoro non riescono a unirsi al cluster, consulta [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) nel capitolo sulla risoluzione dei problemi. 1. (Solo nodi GPU) Se hai scelto un tipo di istanza GPU e l'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 [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 ``` **Fase 3: Azioni aggiuntive** 1. (Facoltativo) implementare [un’applicazione di esempio](sample-deployment.md) per testare il cluster e i nodi Linux. 1. (Facoltativo) Se la policy IAM gestita da **Amazoneks\$1CNI\$1Policy** (se hai `IPv4` un cluster) o la (che hai [creato tu stesso](cni-iam-role.md#cni-iam-role-create-ipv6-policy) se hai un `IPv6` cluster) è collegata al ruolo IAM *AmazonEKS\$1CNI\$1IPv6\$1Policy* del [nodo Amazon EKS, ti consigliamo invece di assegnarlo a un ruolo IAM](create-node-role.md) da associare all'account del 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. 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 delle EC2 istanze Amazon (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). # Crea nodi autogestiti Bottlerocket **Nota** I gruppi di nodi gestiti potrebbero offrire alcuni vantaggi per il tuo caso d’uso. Per ulteriori informazioni, consulta [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md). Questo argomento descrive l’avvio di gruppi Auto Scaling di nodi [Bottlerocket](https://aws.amazon.com/bottlerocket/) che si registrano con il cluster Amazon EKS. Bottlerocket è un sistema operativo open source basato su Linux AWS che è possibile utilizzare per eseguire contenitori su macchine virtuali o host bare metal. Dopo che i nodi vengono aggiunti al cluster, puoi implementare applicazioni Kubernetes per gli stessi. Per ulteriori informazioni su Bottlerocket, consulta [Utilizzo di un'AMI Bottlerocket con Amazon EKS attivo](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) GitHub e supporto [AMI personalizzato](https://eksctl.io/usage/custom-ami-support/) nella documentazione. `eksctl` [Per informazioni sugli aggiornamenti in loco, consulta Bottlerocket Update Operator su.](https://github.com/bottlerocket-os/bottlerocket-update-operator) GitHub **Importante** I nodi di lavoro Amazon EKS sono istanze Amazon EC2 standard e la loro fatturazione è basata sui normali prezzi dell’istanza Amazon EC2. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/). Puoi avviare nodi Bottlerocket nei cluster estesi di Amazon EKS su AWS Outposts, ma non puoi avviarli in cluster locali su Outposts. AWS Per ulteriori informazioni, consulta [Implementazione di Amazon EKS on-premises con AWS Outposts](eks-outposts.md). Puoi eseguire l’implementazione su istanze Amazon EC2 con processori `x86` o Arm. Tuttavia, non puoi eseguire l’implementazione su istanze con chip Inferentia. AWS CloudFormationBottlerocket è compatibile con. Tuttavia, non esiste un CloudFormation modello ufficiale che possa essere copiato per distribuire nodi Bottlerocket per Amazon EKS. Le immagini Bottlerocket non vengono fornite con un server SSH o una shell. Puoi utilizzare metodi di out-of-band accesso per consentire a SSH di abilitare il contenitore di amministrazione e per eseguire alcuni passaggi di configurazione di bootstrap con i dati utente. Per ulteriori informazioni, consulta le seguenti sezioni nel [README.md di Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) su GitHub: [Esplorazione](https://github.com/bottlerocket-os/bottlerocket#exploration) [Container amministratore](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Impostazioni Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente: ``` eksctl version ``` Per istruzioni su come installare o aggiornare `eksctl`, consulta [Installazione](https://eksctl.io/installation) nella documentazione `eksctl`. Nota: questa procedura funziona solo per i cluster creati con `eksctl`. 1. Copia i seguenti contenuti sul dispositivo. Sostituisci *my-cluster* con il nome del cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno della AWS regione e AWS dell'account in cui stai creando il cluster. Sostituisci *ng-bottlerocket* con un nome per il 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. Per implementare su istanze Arm, sostituire *m5.large* con un tipo di istanza Arm. Sostituisci *my-ec2-keypair-name* con il nome di una coppia di chiavi SSH Amazon EC2; che puoi utilizzare per connetterti utilizzando SSH nei nodi dopo l'avvio. Se non disponi già di una coppia di chiavi Amazon EC2, puoi crearla nella Console di gestione AWS. Per ulteriori informazioni, consulta la sezione relativa alle [coppie di chiavi Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Sostituisci tutti i valori esemplificativi rimanenti con i valori in tuo possesso. Dopo aver effettuato le sostituzioni, esegui il comando modificato per creare il file `bottlerocket.yaml`. Se specifichi un tipo di istanza Arm Amazon EC2, esamina le considerazioni [in Arm Amazon Linux ottimizzato per Amazon EKS prima della distribuzione AMIs](eks-optimized-ami.md#arm-ami). Per istruzioni su come implementare utilizzando un'AMI personalizzata, consulta [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) on e GitHub Custom [AMI support nella documentazione](https://eksctl.io/usage/custom-ami-support/). `eksctl` Per implementare un gruppo di nodi gestito, implementare un’AMI personalizzata utilizzando un modello di avvio. Per ulteriori informazioni, consulta [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md). **Importante** Per distribuire un gruppo di nodi nelle sottoreti AWS Outposts, AWS Wavelength AWS o Local Zone, non passare sottoreti AWS Outposts, AWS Wavelength o Local Zone quando crei il cluster. AWS È necessario specificare le sottoreti nell’esempio seguente. Per ulteriori informazioni, vedere [Creare un gruppo di nodi da un file di configurazione](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e lo [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione su `eksctl`. *region-code*Sostituiscilo con la regione in cui si trova il cluster. AWS ``` cat >bottlerocket.yaml < Questo argomento illustra l’avvio di gruppi con scalabilità automatica di nodi Windows che si registrano con il cluster Amazon EKS. Dopo che i nodi vengono aggiunti al cluster, puoi implementare applicazioni Kubernetes per gli stessi. **Importante** I nodi di lavoro Amazon EKS sono istanze Amazon EC2 standard e la loro fatturazione è basata sui normali prezzi dell’istanza Amazon EC2. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/). Puoi avviare nodi Windows nei cluster estesi di Amazon EKS su AWS Outposts, ma non puoi avviarli in cluster AWS locali su Outposts. Per ulteriori informazioni, consulta [Implementazione di Amazon EKS on-premises con AWS Outposts](eks-outposts.md). Abilitare il supporto Windows per il cluster. Si consiglia di rivedere le considerazioni importanti prima di avviare un gruppo di nodi Windows. Per ulteriori informazioni, consulta [Abilitazione del supporto Windows](windows-support.md#enable-windows-support). Puoi avviare nodi Windows autogestiti con uno dei seguenti modi: + [`eksctl`](#eksctl_create_windows_nodes) + [Console di gestione AWS](#console_create_windows_nodes) ## `eksctl` **Avvio dei nodi Windows autogestiti tramite `eksctl`** Questa procedura presuppone che `eksctl` sia installato e che la versione `eksctl` sia almeno `0.215.0`. È possibile verificare la tua versione con il seguente comando. ``` 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 creati con `eksctl`. 1. (Facoltativo) Se la policy IAM gestita da **Amazoneks\$1CNI\$1Policy** (se hai `IPv4` un cluster) o la (che hai [creato tu stesso](cni-iam-role.md#cni-iam-role-create-ipv6-policy) se hai un `IPv6` cluster) è collegata al ruolo IAM *AmazonEKS\$1CNI\$1IPv6\$1Policy* del [nodo Amazon EKS, ti consigliamo invece di assegnarlo a un ruolo IAM](create-node-role.md) da associare all'account del 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. In questa procedura si presuppone la disponibilità di un cluster. Se non disponi ancora di un cluster Amazon EKS e di un gruppo di nodi Amazon Linux a cui aggiungere un gruppo di nodi Windows, ti consigliamo di seguire [Nozioni di base su Amazon EKS: `eksctl`](getting-started-eksctl.md). Questa guida fornisce una spiegazione dettagliata completa per la creazione di un cluster Amazon EKS con nodi Amazon Linux. Crea il tuo gruppo di nodi con il comando seguente. *region-code*Sostituiscilo con la regione in cui si trova il cluster. AWS Sostituisci *my-cluster* con il nome del cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno AWS della regione e AWS dell'account in cui stai creando il cluster. Sostituisci *ng-windows* con un nome per il 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. Puoi sostituirlo *2019* con `2022` per usare Windows Server 2022 o `2025` usare Windows Server 2025. Sostituisci il resto dei valori di esempio con quelli in tuo possesso. **Importante** Per distribuire un gruppo di nodi nelle sottoreti AWS Outposts, AWS Wavelength AWS o Local Zone, non passare le sottoreti AWS Outposts, Wavelength o Local Zone quando crei il cluster. Crea il gruppo di nodi con un file di configurazione, specificando le sottoreti AWS Outposts, Wavelength o Local Zone. Per ulteriori informazioni, vedere [Creazione di un gruppo di nodi da un file di configurazione](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e lo [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione su `eksctl`. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **Nota** Se i nodi non riescono a unirsi al cluster, consultare [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) nella Guida alla risoluzione dei problemi. Per vedere le opzioni disponibili per i comandi `eksctl`, inserire il comando seguente. ``` eksctl command -help ``` Di seguito viene riportato un output di esempio: Durante la creazione dei nodi vengono generate diverse righe. Una delle ultime righe di output è simile alla seguente riga di esempio. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Opzionale) implementare [un’applicazione di esempio](sample-deployment.md) per testare il cluster e i nodi Windows. 1. 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). ## Console di gestione AWS **Prerequisiti** + Creazione di un cluster Amazon EKS e di un gruppo di nodi Linux. Se non disponi di tali risorse, ti consigliamo di crearle utilizzando una delle nostre guide in [Nozioni di base su Amazon EKS](getting-started.md). Queste guide descrivono come creare un cluster Amazon EKS con nodi Linux. + Creazione di un VPC e di un gruppo di sicurezza esistenti che soddisfano i requisiti per un cluster Amazon EKS. Per ulteriori informazioni, consulta [Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti](network-reqs.md) e [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md). Le guide in [Nozioni di base su Amazon EKS](getting-started.md) consentono di creare un VPC che soddisfa i requisiti. In alternativa, è possibile anche seguire [Create an Amazon VPC for your Amazon EKS cluster](creating-a-vpc.md) crearne uno nuovo manualmente. + Un cluster Amazon EKS esistente che utilizza un VPC e un gruppo di sicurezza in grado di soddisfare i requisiti di un cluster Amazon EKS. Per ulteriori informazioni, consulta [Crea un cluster Amazon EKS.](create-cluster.md). Se sono presenti sottoreti nella AWS regione in cui sono abilitati AWS Outposts, AWS Wavelength o AWS Local Zones, tali sottoreti non devono essere state passate al momento della creazione del cluster. **Passaggio 1: avvia i nodi Windows autogestiti utilizzando la Console di gestione AWS ** 1. Attendi che lo stato del cluster risulti `ACTIVE`. Se i nodi vengono avviati prima che il cluster sia attivo, la registrazione al cluster non riesce e sarà necessario riavviarli. 1. Apri la [console AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/) 1. Seleziona **Crea stack**. 1. Per **Specifica modello**, selezionare **URL Amazon S3**. 1. Copia il seguente URL e incollalo nell’**URL di Amazon S3**. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. Seleziona due volte **Next** (Avanti). 1. Nella pagina **Quick create stack (Creazione rapida pila)**, inserire i seguenti parametri di conseguenza: + Nome **dello stack: scegli un nome** per lo stack. AWS CloudFormation Ad esempio, è possibile chiamarlo `my-cluster-nodes`. + **ClusterName**: inserisci il nome che hai usato per creare il cluster Amazon EKS. **Importante** Questo nome deve corrispondere esattamente a quello presente in [Step 1: Create your Amazon EKS cluster](getting-started-console.md#eks-create-cluster). In caso contrario, i nodi non possono aggiungersi al cluster. + **ClusterControlPlaneSecurityGroup**: scegli il gruppo di sicurezza dall' AWS CloudFormation output che hai generato quando hai creato il tuo [VPC](creating-a-vpc.md). Nella procedura seguente viene illustrato un metodo per recuperare il gruppo applicabile. 1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Scegli il nome del cluster. 1. Scegli la scheda **Reti**. 1. Utilizza il valore dei **gruppi di sicurezza aggiuntivi** come riferimento quando selezioni dall'**ClusterControlPlaneSecurityGroup**elenco a discesa. + **NodeGroupName**: inserisci un nome per il tuo gruppo di nodi. Questo nome può essere utilizzato in seguito per identificare il gruppo di nodi con dimensionamento automatico creato per i tuoi 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. + **NodeAutoScalingGroupMinSize**: Inserisci il numero minimo di nodi su cui il gruppo Auto Scaling del nodo può scalare. + **NodeAutoScalingGroupDesiredCapacity**: Inserisci il numero di nodi desiderato su cui scalare quando viene creato lo stack. + **NodeAutoScalingGroupMaxSize**: Inserisci il numero massimo di nodi su cui il gruppo Auto Scaling del nodo può scalare orizzontalmente. + **NodeInstanceType**: scegli un tipo di istanza per i tuoi nodi. Per ulteriori informazioni, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md). **Nota** [I tipi di istanza supportati per l'ultima versione del [plug-in Amazon VPC CNI per Kubernetes sono elencati in vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub 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). + **NodeImageIdSSMParam**: precompilato con il parametro Amazon EC2 Systems Manager dell'attuale ID AMI Windows Core ottimizzato per Amazon EKS. Per utilizzare la versione completa di Windows, sostituire *Core* con `Full`. + **NodeImageId**: (Facoltativo) Se utilizzi un'AMI personalizzata (anziché un'AMI ottimizzata per Amazon EKS), inserisci un ID AMI del nodo per la tua AWS regione. Se specifichi un valore per questo campo, questo sostituisce tutti i valori presenti nel **NodeImageIdSSMParam**campo. + **NodeVolumeSize**: Specificate la dimensione del volume root per i nodi, in GiB. + **KeyName**: inserisci il nome di una coppia di chiavi SSH Amazon EC2 che puoi usare per connetterti tramite SSH ai tuoi nodi dopo il loro avvio. Se non hai già una coppia di chiavi Amazon EC2, puoi crearla nella Console di gestione AWS. Per ulteriori informazioni, consulta la sezione relativa alle [coppie di chiavi Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. **Nota** Se non fornisci una key pair qui, lo AWS CloudFormation stack non viene creato. + **BootstrapArguments**: Specificate eventuali argomenti opzionali da passare allo script di bootstrap del nodo, come ad esempio l'utilizzo di `kubelet` argomenti aggiuntivi. `-KubeletExtraArgs` + **Disabilita IMDSv1**: per impostazione predefinita, ogni nodo supporta Instance Metadata Service versione 1 (IMDSv1) e. IMDSv2 È possibile disabilitare IMDSv1. Per impedire l'utilizzo di nodi e Pod futuri nel gruppo di nodi MDSv1, imposta **Disable** su IMDSv1 **true**. 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). + **VpcId**: Seleziona l'ID per il [VPC](creating-a-vpc.md) che hai creato. + **NodeSecurityGroups**: Seleziona il gruppo di sicurezza che è stato creato per il tuo gruppo di nodi Linux quando hai creato il tuo [VPC](creating-a-vpc.md). Se ai nodi Linux è collegato più di un gruppo di sicurezza, specificarli tutti. Questo, ad esempio, se il gruppo di nodi Linux è stato creato con`eksctl`. + **Sottoreti**: scegliere le sottoreti create. Se hai creato il VPC utilizzando i passaggi descritti in [Create an Amazon VPC for your Amazon EKS cluster](creating-a-vpc.md), specifica solo le sottoreti private all’interno del VPC per avviare i nodi. **Importante** Se una qualsiasi delle sottoreti è pubblica, devi abilitare l’impostazione di assegnazione automatica degli indirizzi IP pubblici. Se l'impostazione non è abilitata per la sottorete pubblica, a tutti i nodi distribuiti in quella sottorete pubblica non verrà assegnato un indirizzo IP pubblico e non saranno in grado di comunicare con il cluster o altri servizi. AWS Se la sottorete è stata distribuita prima del 26 marzo 2020 utilizzando uno dei [modelli AWS CloudFormation VPC di Amazon EKS](creating-a-vpc.md) o utilizzando`eksctl`, l'assegnazione automatica degli indirizzi IP pubblici è disabilitata per le sottoreti pubbliche. Per informazioni su come abilitare l'assegnazione di indirizzi IP pubblici per una sottorete, consulta [Modifica](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) dell'attributo di indirizzamento pubblico per la sottorete. IPv4 Se il nodo viene distribuito in una sottorete privata, è in grado di comunicare con il cluster e altri AWS servizi tramite un gateway NAT. Se le sottoreti non hanno accesso a Internet, leggi con attenzione le considerazioni e i passaggi aggiuntivi descritti in [Deploy private clusters with limited internet access](private-clusters.md). Se si AWS selezionano le sottoreti Outposts, Wavelength o Local Zone, le sottoreti non devono essere state passate al momento della creazione del cluster. 1. Confermare che la pila sia in grado di creare risorse IAM, quindi scegliere **Crea pila**. 1. Al termine della creazione della pila, selezionala nella console e scegli **Outputs (Uscite)**. 1. Registra il per il gruppo di nodi che è stato **NodeInstanceRole**creato. Questo servirà durante la configurazione dei nodi Windows Amazon EKS. **Passaggio 2: abilita l’aggiunta di nodi al cluster** 1. Verifica se disponi già di una `ConfigMap` per `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Se ti viene mostrata una `ConfigMap` per `aws-auth`, aggiornala se necessario. 1. Apri `ConfigMap` per la modifica. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Aggiungi nuove voci `mapRoles`, se necessario. Imposta i `rolearn` valori **NodeInstanceRole**sui valori che hai registrato nelle procedure precedenti. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. Salva il file ed esci dall’editor di testo. 1. Se hai ricevuto un messaggio di errore che indica "`Error from server (NotFound): configmaps "aws-auth" not found`", applica lo `ConfigMap` di stock. 1. Scarica la mappa di configurazione. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. Nel `aws-auth-cm-windows.yaml` file, impostate i `rolearn` valori **NodeInstanceRole**sui valori applicabili registrati nelle procedure precedenti. Per eseguire questa operazione, utilizza un editor di testo o sostituisci i valori di esempio tramite il comando seguente: ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **Importante** Non modificare altre righe in questo file. Non utilizzare lo stesso ruolo IAM sia per i nodi Windows che per quelli Linux. 1. Applica la configurazione. L’esecuzione di questo comando potrebbe richiedere alcuni minuti. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. Guarda lo stato dei nodi e attendi che raggiungano lo stato `Ready`. ``` kubectl get nodes --watch ``` Inserisci `Ctrl`\$1`C` per tornare a un prompt dello shell (interprete di comandi). **Nota** Se ricevi qualsiasi altro errore di tipo di risorsa o autorizzazione, consulta la sezione [Accesso negato o non autorizzato (`kubectl`)](troubleshooting.md#unauthorized) nell’argomento relativo alla risoluzione dei problemi. Se i nodi di lavoro non riescono a unirsi al cluster, consulta [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) nel capitolo sulla risoluzione dei problemi. **Fase 3: Azioni aggiuntive** 1. (Opzionale) implementare [un’applicazione di esempio](sample-deployment.md) per testare il cluster e i nodi Windows. 1. (Facoltativo) Se la policy IAM gestita da **Amazoneks\$1CNI\$1Policy** (se hai `IPv4` un cluster) o la (che hai [creato tu stesso](cni-iam-role.md#cni-iam-role-create-ipv6-policy) se hai un `IPv6` cluster) è collegata al ruolo IAM *AmazonEKS\$1CNI\$1IPv6\$1Policy* del [nodo Amazon EKS, ti consigliamo invece di assegnarlo a un ruolo IAM](create-node-role.md) da associare all'account del 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. 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). # Creazione di nodi Ubuntu Linux autogestiti **Nota** I gruppi di nodi gestiti potrebbero offrire alcuni vantaggi per il tuo caso d’uso. Per ulteriori informazioni, consulta [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md). Questo argomento illustra l’avvio di gruppi Auto Scaling di [Ubuntu su nodi Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) o [Ubuntu Pro su nodi Amazon Elastic Kubernetes Service (EKS) che si registrano con il cluster Amazon EKS](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available). Ubuntu e Ubuntu Pro for EKS si basano sull'Ubuntu Minimal LTS ufficiale, includono il AWS kernel personalizzato sviluppato congiuntamente e sono stati creati appositamente per EKS. AWS Ubuntu Pro aggiunge una copertura di sicurezza aggiuntiva supportando i periodi di supporto estesi di EKS, kernel livepatch, la conformità FIPS e la capacità di eseguire un numero illimitato di container Pro. Dopo che i nodi sono aggiunti al cluster, è possibile implementare le applicazioni containerizzate per gli stessi. Per ulteriori informazioni, consulta la documentazione per [Ubuntu su AWS](https://documentation.ubuntu.com/aws/en/latest/) e il [supporto per le AMI personalizzate](https://eksctl.io/usage/custom-ami-support/) nella documentazione `eksctl`. **Importante** I nodi di lavoro Amazon EKS sono istanze Amazon EC2 standard e la loro fatturazione è basata sui normali prezzi dell’istanza Amazon EC2. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/). Puoi avviare nodi Ubuntu nei cluster estesi di Amazon EKS su AWS Outposts, ma non puoi avviarli in cluster AWS locali su Outposts. Per ulteriori informazioni, consulta [Implementazione di Amazon EKS on-premises con AWS Outposts](eks-outposts.md). È possibile eseguire l’implementazione su istanze Amazon EC2 con processori `x86` o Arm. Tuttavia, le istanze che dispongono di chip Inferentia potrebbero dover installare prima [l’SDK Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/). Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente: ``` eksctl version ``` Per istruzioni su come installare o aggiornare `eksctl`, consulta [Installazione](https://eksctl.io/installation) nella documentazione `eksctl`. Nota: questa procedura funziona solo per i cluster creati con `eksctl`. 1. Copia i seguenti contenuti sul dispositivo. Sostituisci `my-cluster` con il nome del cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfabetico e non può avere una lunghezza superiore a 100 caratteri. Sostituisci `ng-ubuntu` con un nome per il 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. Per implementare su istanze Arm, sostituire `m5.large` con un tipo di istanza Arm. Sostituisci `my-ec2-keypair-name` con il nome di una coppia di chiavi SSH Amazon EC2; che puoi utilizzare per connetterti utilizzando SSH nei nodi dopo l'avvio. Se non disponi già di una coppia di chiavi Amazon EC2, puoi crearla nella Console di gestione AWS. Per ulteriori informazioni, consulta [coppie di chiavi Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella Guida per l’utente di Amazon EC2. Sostituisci tutti i valori esemplificativi rimanenti con i valori in tuo possesso. Dopo aver effettuato le sostituzioni, esegui il comando modificato per creare il file `ubuntu.yaml`. **Importante** Per distribuire un gruppo di nodi nelle sottoreti AWS Outposts, AWS Wavelength AWS o Local Zone, non passare sottoreti AWS Outposts, AWS Wavelength o Local Zone quando crei il cluster. AWS È necessario specificare le sottoreti nell’esempio seguente. Per ulteriori informazioni, vedere [Creare un gruppo di nodi da un file di configurazione](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e lo [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione su `eksctl`. *region-code*Sostituiscilo con la regione in cui si trova il cluster. AWS ``` cat >ubuntu.yaml < 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).