**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à.
# Gestire le risorse di elaborazione utilizzando i nodi
Un nodo Kubernetes è una macchina che esegue applicazioni containerizzate. Ogni nodo include i seguenti componenti:
+ ** [Runtime del container:](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)** software responsabile dell’esecuzione dei container.
+ ** [kubelet:](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)** garantisce che i container siano integri e funzionanti nel proprio pod associato.
+ ** [kube-proxy:](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) ** gestisce le regole della rete che consentono la comunicazione con i pod.
Per ulteriori informazioni, consulta [Nodi](https://kubernetes.io/docs/concepts/architecture/nodes/) nella documentazione Kubernetes.
Il cluster Amazon EKS può pianificare pod su qualsiasi combinazione di [nodi gestiti dalla modalità automatica EKS](automode.md), [nodi autogestiti](worker.md), [gruppi di nodi gestiti da Amazon EKS](managed-node-groups.md), [AWS Fargate](fargate.md) e [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md). Per ulteriori informazioni sui nodi implementati nel cluster, consulta [Visualizza le risorse Kubernetes nel Console di gestione AWS](view-kubernetes-resources.md).
**Nota**
A eccezione dei nodi ibridi, i nodi devono trovarsi nello stesso VPC delle sottoreti selezionate al momento della creazione del cluster, ma non necessariamente nelle stesse sottoreti.
## Confronto delle opzioni di calcolo
Nella tabella seguente vengono forniti diversi criteri per valutare quali opzioni sono più adatte alle proprie esigenze. I nodi autogestiti sono un’opzione alternativa che supporta tutti i criteri elencati, ma che richiede molta più manutenzione manuale. Per ulteriori informazioni, consulta [Gestione autonoma dei nodi con nodi autogestiti](worker.md).
**Nota**
Bottlerocket presenta alcune differenze specifiche rispetto alle informazioni generali contenute in questa tabella. Per ulteriori informazioni, consultare la [documentazione](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) relativa a Bottlerocket su GitHub.
| Criteri | Gruppi di nodi gestiti EKS | Modalità automatica EKS | Amazon EKS Hybrid Nodes |
| --- | --- | --- | --- |
| Può essere implementato in [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | No | No | No |
| Può essere implementato nella [zona locali AWS](local-zones.md) | Sì | No | No |
| Può eseguire container che richiedono Windows | Sì | No | No |
| Può eseguire container che richiedono Linux | Sì | Sì | Sì |
| Può eseguire carichi di lavoro che richiedono il chip Inferentia | [Sì](inferentia-support.md) – Solo nodi Amazon Linux | Sì | No |
| Può eseguire carichi di lavoro che richiedono una GPU | [Sì](eks-optimized-ami.md#gpu-ami) – Solo nodi Amazon Linux | Sì | Sì |
| Può eseguire carichi di lavoro che richiedono processori Arm | [Sì](eks-optimized-ami.md#arm-ami) | Sì | Sì |
| Può eseguire AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Sì | Sì | No |
| I pod condividono risorse di CPU, memoria, archiviazione e rete con altri pod. | Sì | Sì | Sì |
| Deve implementare e gestire le istanze Amazon EC2 | Sì | No - Ulteriori informazioni sulle [istanze gestite di EC2](automode-learn-instances.md) | Sì - Le macchine fisiche on-premises o virtuali sono autogestite con strumenti a scelta. |
| È necessario proteggere, mantenere e applicare patch al sistema operativo delle istanze Amazon EC2 | Sì | No | Sì - Il sistema operativo in esecuzione sulle macchine fisiche o virtuali è autogestito con strumenti a scelta. |
| Può fornire argomenti di bootstrap all’implementazione di un nodo, come argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi. | Sì - Utilizzando `eksctl` o un [modello di avvio](launch-templates.md) con un’AMI personalizzata. | No - [Utilizzare `NodeClass` per configurare i nodi](create-node-class.md) | Sì - È possibile personalizzare gli argomenti di bootstrap con nodeadm. Consultare [Riferimento `nodeadm` dei nodi ibridi](hybrid-nodes-nodeadm.md). |
| Può assegnare indirizzi IP ai pod da un intervallo CIDR diverso rispetto all’indirizzo IP assegnato al nodo. | Sì: utilizzando un modello di avvio con un'AMI personalizzata. Per ulteriori informazioni, consulta [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md). | No | Sì - Consultare [Configurazione della CNI per nodi ibridi](hybrid-nodes-cni.md). |
| Puoi eseguire SSH nel nodo | Sì | No - [Informazioni su come risolvere i problemi dei nodi](auto-troubleshoot.md) | Sì |
| Puoi implementare un'AMI personalizzata nei nodi | Sì – Utilizzo di un [modello di avvio](launch-templates.md) | No | Sì |
| Può implementare un CNI personalizzato nei nodi | Sì – Utilizzando un [modello di avvio](launch-templates.md) con un'AMI personalizzata | No | Sì |
| É necessario aggiornare l'AMI del nodo per conto proprio | [Sì](update-managed-node-group.md) - Se è stata implementata un’AMI ottimizzata per Amazon EKS, sarà inviata una notifica nella console Amazon EKS quando gli aggiornamenti sono disponibili. È possibile eseguire l'aggiornamento con un clic nella console. Se è stata implementata un’AMI personalizzata, non sarà inviata una notifica nella console Amazon EKS quando gli aggiornamenti sono disponibili. È necessario eseguire l'aggiornamento per conto proprio. | No | Sì - Il sistema operativo eseguito sulle macchine fisiche o virtuali è autogestito con strumenti a scelta. Consultare [Preparazione del sistema operativo per i nodi ibridi](hybrid-nodes-os.md). |
| È necessario aggiornare la versione del nodo Kubernetes per conto proprio | [Sì](update-managed-node-group.md) - Se è stata implementata un’AMI ottimizzata per Amazon EKS, sarà inviata una notifica nella console Amazon EKS quando gli aggiornamenti sono disponibili. È possibile eseguire l'aggiornamento con un clic nella console. Se è stata implementata un’AMI personalizzata, non sarà inviata una notifica nella console Amazon EKS quando gli aggiornamenti sono disponibili. È necessario eseguire l'aggiornamento per conto proprio. | No | Sì - Gli aggiornamenti dei nodi ibridi vengono gestiti con strumenti a scelta o con `nodeadm`. Consultare [Aggiornamento dei nodi ibridi per il tuo cluster](hybrid-nodes-upgrade.md). |
| Può utilizzare lo spazio di archiviazione Amazon EBS con i pod | [Sì](ebs-csi.md) | Sì, come funzionalità integrata. Informazioni su come [creare una classe di archiviazione.](create-storage-class.md) | No |
| Può utilizzare lo spazio di archiviazione Amazon EFS con i pod | [Sì](efs-csi.md) | Sì | No |
| Può utilizzare lo spazio di archiviazione Amazon FSx per Lustre con i pod | [Sì](fsx-csi.md) | Sì | No |
| Può utilizzare Network Load Balancer per i servizi | [Sì](network-load-balancing.md) | Sì | Sì - È necessario utilizzare il tipo di destinazione `ip`. |
| I pod possono essere eseguiti in una sottorete pubblica | Sì | Sì | No - I pod vengono eseguiti in un ambiente on-premises. |
| Può assegnare diversi gruppi di sicurezza VPC a singoli pod | [Sì](security-groups-for-pods.md) – Solo nodi Linux | No | No |
| Può eseguire Kubernetes DaemonSets | Sì | Sì | Sì |
| Supporto per `HostPort` e `HostNetwork` nel manifesto pod | Sì | Sì | Sì |
| Disponibilità nelle regioni AWS | [Tutte le regioni supportate da Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Tutte le Regioni Amazon EKS supportate](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Tutte le Regioni supportate da Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html), a eccezione delle Regioni AWS GovCloud (Stati Uniti) e le Regioni della Cina. |
| Può eseguire container su host dedicati Amazon EC2 | Sì | No | No |
| Prezzi | Costo dell’istanza Amazon EC2 che esegue più pod. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/). | Quando la modalità automatica EKS è abilitata nel cluster, viene addebitata una tariffa separata per le istanze avviate utilizzando la funzionalità di calcolo della modalità automatica, in aggiunta ai costi standard delle istanze EC2. L’importo varia a seconda del tipo di istanza avviata e della Regione AWS in cui si trova il cluster. Per ulteriori informazioni, consultare [Prezzi di Amazon EKS](https://aws.amazon.com/eks/pricing/). | Costo dei nodi ibridi in vCPU all’ora. Per ulteriori informazioni, consultare [Prezzi di Amazon EKS](https://aws.amazon.com/eks/pricing/). |
# Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti
I gruppi di nodi gestiti di Amazon EKS automatizzano il provisioning e la gestione del ciclo di vita dei nodi ( EC2 istanze Amazon) per i cluster Amazon EKS Kubernetes.
Con i gruppi di nodi gestiti di Amazon EKS, non è necessario effettuare il provisioning o registrare separatamente EC2 le istanze Amazon che forniscono capacità di calcolo per eseguire le applicazioni Kubernetes. È possibile creare, aggiornare o terminare automaticamente i nodi per il cluster con una singola operazione. Gli aggiornamenti e le interruzioni dei nodi svuotano automaticamente i nodi per garantire che le applicazioni rimangano disponibili.
Ogni nodo gestito viene fornito come parte di un gruppo Amazon EC2 Auto Scaling gestito per te da Amazon EKS. Ogni risorsa, incluse le istanze e i gruppi Auto Scaling, viene eseguita all'interno AWS del tuo account. Ogni gruppo di nodi viene eseguito su più zone di disponibilità definite.
I gruppi di nodi gestiti possono anche sfruttare opzionalmente la riparazione automatica, che monitora continuamente lo stato di integrità dei nodi. In pratica, reagisce automaticamente ai problemi rilevati e sostituisce i nodi quando possibile. Ciò aiuta la disponibilità complessiva del cluster con un intervento manuale minimo. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).
Puoi aggiungere un gruppo di nodi gestiti a cluster nuovi o esistenti utilizzando la console Amazon EKS, la AWS CLI `eksctl` AWS , l'API o l'infrastruttura come strumenti di codice, tra cui. AWS CloudFormation I nodi avviati come parte di un gruppo di nodi gestiti vengono automaticamente taggati per l’individuazione automatica tramite [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes. É possibile utilizzare il gruppo di nodi per applicare le etichette Kubernetes ai nodi e aggiornarle in qualsiasi momento.
Non ci sono costi aggiuntivi per l'utilizzo dei gruppi di nodi gestiti di Amazon EKS, paghi solo per le AWS risorse fornite. Questi includono EC2 istanze Amazon, volumi Amazon EBS, orari dei cluster Amazon EKS e qualsiasi altra AWS infrastruttura. Non sono previste tariffe minime né impegni anticipati.
Per iniziare a utilizzare un nuovo cluster Amazon EKS e un gruppo di nodi gestiti, vedi [Inizia a usare Amazon EKS Console di gestione AWS e AWS CLI](getting-started-console.md).
Per aggiungere un gruppo di nodi gestiti a un cluster esistente, vedi [Creare un gruppo di nodi gestiti per il cluster](create-managed-node-group.md).
## Concetti sui gruppi di nodi gestiti
+ I gruppi di nodi gestiti di Amazon EKS creano e gestiscono EC2 istanze Amazon per te.
+ Ogni nodo gestito viene fornito come parte di un gruppo Amazon EC2 Auto Scaling gestito per te da Amazon EKS. Inoltre, tutte le risorse, incluse EC2 le istanze Amazon e i gruppi di Auto Scaling, vengono eseguite all'interno AWS del tuo account.
+ Il gruppo Auto Scaling di un gruppo di nodi gestiti si estende su ogni sottorete specificata al momento della creazione del gruppo.
+ Amazon EKS applica tag alle risorse del gruppo di nodi gestiti in modo che siano configurate per utilizzare [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes.
**Importante**
Se si esegue un’applicazione stateful in più zone di disponibilità supportate dai volumi Amazon EBS e che utilizza il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes, è necessario configurare più gruppi di nodi, ognuno dei quali definito per una singola zona di disponibilità. Inoltre, è necessario abilitare la funzionalità `--balance-similar-node-groups`.
+ È possibile utilizzare un modello di avvio personalizzato per un maggiore livello di flessibilità e personalizzazione durante l’implementazione dei nodi gestiti. Ad esempio, è possibile specificare argomenti `kubelet` aggiuntivi e utilizzare un’AMI personalizzata. Per ulteriori informazioni, consulta [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md). Se non si utilizza un modello di avvio personalizzato quando si crea per la prima volta un gruppo di nodi gestiti, è disponibile un modello di avvio generato automaticamente. Non modificare manualmente questo modello generato automaticamente o si verificheranno errori.
+ Amazon EKS segue il modello di responsabilità condivisa CVEs e le patch di sicurezza sui gruppi di nodi gestiti. Quando i nodi gestiti eseguono un’AMI ottimizzata per Amazon EKS, Amazon EKS è responsabile della creazione di versioni con patch dell’AMI quando vengono segnalati bug o problemi. A questo scopo vengono pubblicate delle correzioni. Sei invece responsabile della distribuzione di queste versioni AMI con patch ai gruppi di nodi gestiti. Quando i nodi gestiti eseguono un’AMI personalizzata, sei responsabile della creazione di versioni con patch dell’AMI quando vengono segnalati bug o problemi, oltre che della distribuzione dell’AMI. Per ulteriori informazioni, consulta [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md).
+ I gruppi di nodi gestiti Amazon EKS possono essere avviati in sottoreti pubbliche e private. Se si avvia un gruppo di nodi gestiti in una sottorete pubblica in data 22 aprile 2020 o successiva, sarà necessario che la sottorete abbia `MapPublicIpOnLaunch` impostato su vero affinché le istanze possano partecipare correttamente a un cluster. Se la sottorete pubblica è stata creata utilizzando `eksctl` o i [AWS CloudFormation modelli forniti da Amazon EKS](creating-a-vpc.md) a partire dal 26 marzo 2020, questa impostazione è già impostata su true. Se le sottoreti pubbliche sono state create prima del 26 marzo 2020 devi modificare manualmente l’impostazione. Per ulteriori informazioni, consulta [Modifica dell'attributo di IPv4 indirizzamento pubblico per la](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) sottorete.
+ Quando implementi un gruppo di nodi gestito in sottoreti private, devi assicurarti che possa accedere ad Amazon ECR per estrarre le immagini dei container. È possibile farlo collegando un gateway NAT alla tabella di routing della sottorete o aggiungendo i seguenti [endpoint VPC AWS PrivateLink ](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create):
+ Interfaccia endpoint dell'API di Amazon ECR: `com.amazonaws.region-code.ecr.api`
+ Interfaccia endpoint dell’API del registro Docker di Amazon ECR: `com.amazonaws.region-code.ecr.dkr`
+ Endpoint del gateway Amazon S3: `com.amazonaws.region-code.s3`
Per altri servizi ed endpoint di uso comune, consulta la sezione [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md).
+ I gruppi di nodi gestiti non possono essere distribuiti su [AWS Outposts](eks-outposts.md) o in [AWS Wavelength](https://docs.aws.amazon.com/wavelength/). È possibile creare gruppi di nodi gestiti in [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Per ulteriori informazioni, consulta [Avvia cluster EKS a bassa latenza con AWS Local Zones](local-zones.md).
+ È possibile creare più gruppi di nodi gestiti all’interno di un singolo cluster. Ad esempio, puoi creare un gruppo di nodi con l’AMI Linux standard ottimizzata per Amazon EKS per alcuni carichi di lavoro e un altro gruppo con la variante GPU per i carichi di lavoro che richiedono il supporto della GPU.
+ Se il tuo gruppo di nodi gestiti rileva un errore di [controllo dello stato delle EC2 istanze Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html), Amazon EKS restituisce un codice di errore per aiutarti a diagnosticare il problema. Per ulteriori informazioni, consulta [Codici di errore dei gruppi di nodi gestiti](troubleshooting.md#troubleshoot-managed-node-groups).
+ Amazon EKS aggiunge etichette Kubernetes alle istanze del gruppo di nodi gestiti. Queste etichette fornite da Amazon EKS hanno il prefisso `eks.amazonaws.com`.
+ Amazon EKS svuota automaticamente i nodi utilizzando l’API Kubernetes durante le interruzioni o gli aggiornamenti.
+ I budget di interruzione del pod non vengono rispettati quando si termina un nodo con `AZRebalance` o si riduce il numero di nodi desiderato. Queste operazioni cercano di espellere pod dal nodo. Tuttavia, se trascorrono più di 15 minuti, il nodo viene terminato a prescindere dal fatto che tutti i pod sul nodo siano stati terminati. Per prolungare il periodo fino alla terminazione del nodo, aggiungi un hook del ciclo di vita al gruppo con scalabilità automatica. Per ulteriori informazioni, consulta [Add lifecycle hook](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html) nella Amazon * EC2 Auto Scaling* User Guide.
+ Per eseguire correttamente il processo di scarico dopo aver ricevuto una notifica di interruzione spot o una notifica di ribilanciamento della capacità, `CapacityRebalance` deve essere impostato su `true`.
+ L’aggiornamento di gruppi di nodi gestiti rispettano i budget di interruzione dei pod impostati per i pod. Per ulteriori informazioni, consulta [Comprendi ogni fase degli aggiornamenti dei nodi](managed-node-update-behavior.md).
+ I gruppi di nodi gestiti Amazon EKS non prevedono costi aggiuntivi. Paghi solo per le AWS risorse che fornisci.
+ Se si desidera crittografare i volumi Amazon EBS per i nodi, è possibile implementare i nodi utilizzando un modello di avvio. Per implementare nodi gestiti con volumi Amazon EBS crittografati senza utilizzare un modello di avvio, crittografare tutti i nuovi volumi Amazon EBS creati nell’account. Per ulteriori informazioni, consulta [Encryption by default](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) nella *Amazon EC2 User Guide*.
## Tipi di capacità del gruppo di nodi gestiti
Quando si crea un gruppo di nodi gestito, è possibile scegliere il tipo di capacità su on demand o Spot. Amazon EKS implementa un gruppo di nodi gestiti con un gruppo Amazon EC2 Auto Scaling che contiene solo istanze On-Demand o solo istanze Amazon EC2 Spot. All’interno di un singolo cluster Kubernetes, è possibile pianificare i pod per le applicazioni tolleranti ai guasti sia per i gruppi di nodi gestiti Spot che per i gruppi di nodi on-demand. Per impostazione predefinita, un gruppo di nodi gestiti distribuisce istanze Amazon EC2 On-Demand.
### On demand
Con Istanze on demand, sono previsti costi per la capacità di calcolo entro la seconda ora senza impegni a lungo termine.
Per impostazione predefinita, se non specifichi un **Tipo capacità**, per il gruppo di nodi gestiti viene eseguito il provisioning con Istanze on demand. Un gruppo di nodi gestito configura un gruppo Amazon EC2 Auto Scaling per tuo conto con le seguenti impostazioni applicate:
+ La strategia di allocazione per il provisioning della capacità On-Demand è impostata su `prioritized`. Il gruppo di nodi gestiti utilizza l’ordine dei tipi di istanze approvata dall’API per determinare quale tipo di istanza utilizzare prima per soddisfare la capacità on demand. Ad esempio, è possibile specificare tre tipi di istanza nell’ordine seguente: `c5.large`, `c4.large`, e `c3.large`. Quando le istanze on demand vengono avviate, il gruppo di nodi gestiti soddisfa la capacità on demand a partire da `c5.large`, quindi `c4.large`, e infine `c3.large`. Per ulteriori informazioni, consulta il [gruppo Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) nella *Amazon Auto EC2 Scaling User Guide*.
+ Amazon EKS aggiunge la seguente etichetta Kubernetes a tutti i nodi del gruppo di nodi gestito che specifica il tipo di capacità: `eks.amazonaws.com/capacityType: ON_DEMAND`. È possibile utilizzare questa etichetta sui nodi on demand per pianificare applicazioni con stato o fault intolerant.
### Spot
Le istanze Amazon EC2 Spot sono una EC2 capacità Amazon inutilizzata che offre forti sconti sui prezzi On-Demand. Le istanze Amazon EC2 Spot possono essere interrotte con un avviso di interruzione di due minuti quando è EC2 necessario ripristinare la capacità. Per ulteriori informazioni, consulta le [istanze Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) nella *Amazon EC2 User Guide*. Puoi configurare un gruppo di nodi gestiti con Amazon EC2 Spot Instances per ottimizzare i costi per i nodi di calcolo in esecuzione nel tuo cluster Amazon EKS.
Per utilizzare istanze spot all’interno di un gruppo di nodi gestiti, creare un gruppo di nodi gestiti impostando il tipo di capacità come `spot`. Un gruppo di nodi gestito configura un gruppo Amazon EC2 Auto Scaling per tuo conto applicando le seguenti best practice Spot:
+ Per garantire che il provisioning dei nodi Spot venga eseguito nei pool di capacità Spot ottimali, la strategia di allocazione è impostata su uno dei seguenti valori:
+ `price-capacity-optimized` (PCO): quando si creano nuovi gruppi di nodi in un cluster con Kubernetes versione `1.28` o successive, la strategia di allocazione è impostata su `price-capacity-optimized`. Tuttavia, la strategia di allocazione non viene modificata per i gruppi di nodi già creati con `capacity-optimized` prima che i gruppi di nodi gestiti da Amazon EKS inizino a supportare PCO.
+ `capacity-optimized` (CO): quando si creano nuovi gruppi di nodi in un cluster con Kubernetes versione `1.27` o precedenti, la strategia di allocazione è impostata su `capacity-optimized`.
Per aumentare il numero di pool di capacità Spot disponibili da cui allocare le capacità, configurare un gruppo di nodi gestiti per l’utilizzo di più tipi di istanza.
+ Amazon EC2 Spot Capacity Rebalancing è abilitato in modo che Amazon EKS possa drenare e ribilanciare in modo corretto i nodi Spot per ridurre al minimo l'interruzione delle applicazioni quando un nodo Spot è a elevato rischio di interruzione. Per ulteriori informazioni, consulta [Amazon EC2 Auto Scaling Capacity Rebalancing nella](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) Amazon Auto *Scaling EC2 * User Guide.
+ Quando un nodo Spot riceve un consiglio di ribilanciamento, Amazon EKS tenta automaticamente di avviare un nuovo nodo Spot sostitutivo.
+ Se un avviso di interruzione Spot di due minuti arriva prima che il nodo Spot sostitutivo si trovi in uno stato `Ready`, Amazon EKS inizia a svuotare il nodo Spot che ha ricevuto il suggerimento di ribilanciamento. Amazon EKS svuota il nodo nel modo migliore possibile. Di conseguenza, non c’è alcuna garanzia che Amazon EKS attenda che il nodo sostitutivo si unisca al cluster prima di svuotare il nodo esistente.
+ Quando un nodo Spot sostitutivo viene avviato ed è allo stato `Ready` su Kubernetes, Amazon EKS isola e svuota il nodo Spot che ha ricevuto il suggerimento di ribilanciamento. L’isolamento del nodo Spot assicura che il controller di servizio non invii nuove richieste a questo nodo Spot. Il nodo viene rimosso anche dall’elenco di nodi Spot sani e attivi. Lo svuotamento del nodo Spot assicura che i pod in esecuzione vengano espulsi in modo corretto.
+ Amazon EKS aggiunge la seguente etichetta Kubernetes a tutti i nodi del gruppo di nodi gestito che specifica il tipo di capacità: `eks.amazonaws.com/capacityType: SPOT`. È possibile utilizzare questa etichetta per pianificare applicazioni fault tolerant sui nodi Spot.
**Importante**
EC2 emette un [avviso di interruzione Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) due minuti prima della chiusura dell'istanza Spot. Tuttavia, i Pod sui nodi Spot potrebbero non ricevere l'intera finestra di 2 minuti necessaria per uno spegnimento regolare. Quando EC2 emette l'avviso, c'è un ritardo prima che Amazon EKS inizi a sfrattare i Pods. Gli sfratti avvengono in sequenza per proteggere il server dell'API Kubernetes, quindi durante più reclami Spot simultanei, alcuni Pod potrebbero ricevere avvisi di sfratto ritardato. I Pod possono essere chiusi forzatamente senza ricevere segnali di terminazione, in particolare su nodi ad alta densità di Pod, durante reclami simultanei o quando si utilizzano periodi di tolleranza di terminazione prolungati. Per i carichi di lavoro Spot, consigliamo di progettare le applicazioni in modo da tollerare le interruzioni, utilizzando periodi di tolleranza di terminazione pari o inferiori a 30 secondi, evitando agganci PreStop di lunga durata e monitorando le metriche di sfratto dei Pod per comprendere i periodi di tolleranza effettivi nei cluster. Per i carichi di lavoro che richiedono una terminazione corretta e garantita, consigliamo invece di utilizzare la capacità On-Demand.
Quando si decide se implementare un gruppo di nodi con capacità On-Demand o Spot, è necessario considerare le seguenti condizioni:
+ Le istanze Spot sono consigliate per applicazioni senza stato, fault tolerant e flessibili. Questi includono carichi di lavoro di formazione in batch e machine learning, big data ETLs come Apache Spark, applicazioni di elaborazione delle code ed endpoint API stateless. Poiché Spot è una EC2 capacità Amazon inutilizzata, che può cambiare nel tempo, ti consigliamo di utilizzare la capacità Spot per carichi di lavoro tolleranti alle interruzioni. Più specificamente, la capacità Spot è adatta per carichi di lavoro in grado di tollerare periodi in cui la capacità richiesta non è disponibile.
+ Consigliamo di utilizzare On-demand per le applicazioni che sono fault intolerant. Ciò include strumenti di gestione dei cluster come strumenti di monitoraggio e operativi, implementazioni che richiedono `StatefulSets` e applicazioni con stato, come database.
+ Per ottimizzare la disponibilità delle applicazioni durante l’utilizzo di istanze Spot, è consigliabile configurare un gruppo di nodi gestiti Spot per l’utilizzo di più tipi di istanza. Quando si utilizzano più tipi di istanza, si consiglia di applicare le seguenti regole:
+ All’interno di un gruppo di nodi gestiti, se utilizzi [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), ti consigliamo di utilizzare un set flessibile di tipi di istanza con la stessa quantità di vCPU e risorse di memoria. Questo per garantire che i nodi del cluster vengano dimensionati come previsto. Ad esempio, se hai bisogno di quattro v CPUs e otto GiB di memoria,,`c3.xlarge`,`c4.xlarge`, `c5.xlarge` `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, o altri tipi di istanza simili.
+ Per migliorare la disponibilità delle applicazioni, si consiglia di implementare più gruppi di nodi gestiti Spot. Per questo, ogni gruppo dovrebbe utilizzare un set flessibile di tipi di istanza con le stesse risorse vCPU e memoria. Ad esempio, se hai bisogno di memoria 4 v CPUs e 8 GiB, ti consigliamo di creare un gruppo di nodi gestiti con`c3.xlarge`,,,`c4.xlarge`, `c5.xlarge` `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, o altri tipi di istanze simili e un secondo gruppo di nodi gestiti con`m3.xlarge`,,, `m4.xlarge` `m5.xlarge` `m5d.xlarge``m5a.xlarge`, `m5n.xlarge` o altri tipi di istanze simili.
+ Quando si implementa il gruppo di nodi con il tipo di capacità Spot che utilizza un modello di avvio personalizzato, utilizza l’API per passare più tipi di istanza. Non passare un singolo tipo di istanza tramite il modello di avvio. Per ulteriori informazioni sull’implementazione di un gruppo di nodi tramite un modello di avvio, vedere [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md).
# Creare un gruppo di nodi gestiti per il cluster
In questo argomento viene descritto come avviare gruppi di nodi gestiti Amazon EKS per nodi che si registrano con il cluster Amazon EKS. Dopo che i nodi vengono aggiunti al cluster, puoi implementare applicazioni Kubernetes per gli stessi.
Se si avvia un gruppo di nodi gestiti Amazon EKS per la prima volta, consigliamo invece di seguire una delle nostre guide in [Nozioni di base su Amazon EKS](getting-started.md). Queste guide forniscono procedure dettagliate per la creazione di un cluster Amazon EKS con nodi.
**Importante**
I nodi Amazon EKS sono istanze Amazon EC2 standard. La fatturazione viene effettuata in base ai normali prezzi Amazon EC2. Per ulteriori informazioni, consulta [Prezzi di Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Non puoi creare nodi gestiti in una AWS regione in cui AWS Outposts o Wavelength AWS sono abilitati. È possibile, invece creare nodi autogestiti. Per ulteriori informazioni, consultare [Crea nodi Amazon Linux autogestiti](launch-workers.md), [Crea nodi Microsoft Windows autogestiti](launch-windows-workers.md) e [Crea nodi autogestiti Bottlerocket](launch-node-bottlerocket.md). Puoi anche creare un gruppo di nodi Amazon Linux autogestito su un Outpost. Per ulteriori informazioni, consulta [Crea nodi Amazon Linux su AWS Outposts](eks-outposts-self-managed-nodes.md).
Se non si [specifica un ID AMI](launch-templates.md#launch-template-custom-ami) per il file `bootstrap.sh` incluso in Linux o Bottlerocket ottimizzato per Amazon EKS, i gruppi di nodi gestiti impongono un numero massimo sul valore di `maxPods`. Per le istanze con meno di 30 vCPUs, il numero massimo è. `110` Per le istanze con più di 30 vCPUs, il numero massimo salta a. `250` Questa applicazione ha la precedenza su altre `maxPods` configurazioni, tra cui. `maxPodsExpression` Per ulteriori informazioni su come `maxPods` viene determinato e su come personalizzarlo, vedere. [Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence)
+ Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Crea un cluster Amazon EKS.](create-cluster.md).
+ Un ruolo IAM esistente per i nodi da utilizzare. Per crearne uno, consulta [Ruolo IAM del nodo Amazon EKS](create-node-role.md). Se questo ruolo non prevede nessuna delle policy per VPC CNI, per i pod VPC CNI è necessario il ruolo separato riportato di seguito.
+ (Facoltativo, ma consigliato) Il componente aggiuntivo plug-in CNI di Amazon VPC per Kubernetes configurato con il proprio ruolo IAM a cui è allegata la policy IAM necessaria. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
+ Familiarità con le considerazioni presenti alla pagina [Choose an optimal Amazon EC2 node instance type](choosing-instance-type.md). A seconda del tipo di istanza scelto, potrebbero esserci ulteriori prerequisiti per il cluster e il VPC.
+ Per aggiungere un gruppo di nodi gestiti da Windows, è prima necessario abilitare il supporto Windows per il cluster. Per ulteriori informazioni, consulta [Implementazione dei nodi Windows su cluster EKS](windows-support.md).
È possibile creare un gruppo di nodi gestito con uno di questi due strumenti:
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [Console di gestione AWS](#console_create_managed_nodegroup)
## `eksctl`
**Creare un gruppo di nodi gestito con eksctl**
Questa procedura richiede `eksctl` versione `0.215.0` o successiva. È possibile verificare la versione con il comando seguente:
```
eksctl version
```
Per istruzioni sull’installazione o sull’aggiornamento di `eksctl`, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
1. (Facoltativo) Se la policy IAM gestita **AmazonEKS\$1CNI\$1Policy** è collegata al [ruolo IAM del nodo Amazon EKS](create-node-role.md), si consiglia, invece, di assegnarla a un ruolo IAM associato all’account di servizio Kubernetes `aws-node`. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
1. Creare un gruppo di nodi gestiti con o senza utilizzare un modello di avvio personalizzato. La specifica manuale di un modello di avvio consente una maggiore personalizzazione di un gruppo di nodi. Ad esempio, può consentire l'implementazione di un'AMI personalizzata o la presenza di argomenti sullo script `boostrap.sh` in un'AMI ottimizzata per Amazon EKS. Per avere un elenco completo di tutte le opzioni e le impostazioni predefinite disponibili, inserisci il comando seguente.
```
eksctl create nodegroup --help
```
Nel comando seguente, sostituisci *my-cluster* con il nome del tuo cluster e sostituisci *my-mng* con il nome del gruppo di nodi. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.
**Importante**
Se non si utilizza un modello di avvio personalizzato durante la prima creazione di un gruppo di nodi gestiti, non utilizzarne uno per il gruppo di nodi in un secondo momento. Se non è stato specificato un modello di avvio personalizzato, il sistema genera automaticamente un modello di avvio che non è consigliabile modificare manualmente. La modifica manuale di questo modello di avvio generato in automatico potrebbe causare errori.
**Senza un modello di avvio**
`eksctl` crea un modello di avvio Amazon EC2 predefinito nell'account e implementa il gruppo di nodi utilizzando un modello di avvio creato in base alle opzioni specificate. Prima di specificare un valore per `--node-type`, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md).
Sostituisci *ami-family* con una parola chiave consentita. Per ulteriori informazioni, consulta [Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) (Impostazione della famiglia AMI dei nodi) nella documentazione di `eksctl`. Sostituisci *my-key* con il nome della coppia di chiavi Amazon EC2 o della chiave pubblica. Questa chiave viene utilizzata per eseguire il SSH nei nodi dopo il loro avvio.
**Nota**
Per Windows, questo comando non abilita SSH. Associa, invece, la coppia di chiavi Amazon EC2 all'istanza e ti consente di eseguire il protocollo RDP nell'istanza.
Se non si dispone di una coppia di chiavi Amazon EC2, è possibile crearla nella Console di gestione AWS. Per informazioni su Linux, consultare [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Per informazioni su Windows, consultare [Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*.
Consigliamo di bloccare l’accesso dei pod a IMDS se si verificano le seguenti condizioni:
+ Prevedi di assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie.
+ Nessun pod nel cluster richiede l'accesso al servizio di metadati dell'istanza Amazon EC2 (IMDS) per altri motivi, come il recupero della regione corrente. AWS
Per ulteriori informazioni, consulta [Limita l'accesso al profilo dell'istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
Se si desidera bloccare l’accesso del pod a IMDS, aggiungere l’opzione `--disable-pod-imds` al seguente comando.
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
Le istanze possono opzionalmente assegnare un numero di indirizzi IP significativamente superiore ai pod, assegnare indirizzi IP ai pod da un intervallo CIDR diverso da quello dell’istanza ed essere distribuite in un cluster senza accesso a Internet. Per ulteriori informazioni, consultare [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md), [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md), e [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md) per ulteriori opzioni da aggiungere al comando precedente.
I gruppi di nodi gestiti calcolano e applicano un singolo valore per il numero massimo di pod che possono essere eseguiti su ogni nodo del gruppo in base al tipo di istanza. Se si crea un gruppo di nodi con tipi di istanza diversi, il valore più piccolo calcolato in tutti i tipi di istanza viene applicato come numero massimo di pod che possono essere eseguiti su ogni tipo di istanza nel gruppo di nodi. I gruppi di nodi gestiti calcolano il valore utilizzando lo script a cui si fa riferimento nella pagina .
**Con un modello di lancio**
Il modello di avvio deve esistere già e deve soddisfare i requisiti specificati nella pagina [Launch template configuration basics](launch-templates.md#launch-template-basics). Consigliamo di bloccare l’accesso dei pod a IMDS se si verificano le seguenti condizioni:
+ Prevedi di assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie.
+ Nessun pod nel cluster richiede l'accesso al servizio di metadati dell'istanza Amazon EC2 (IMDS) per altri motivi, come il recupero della regione corrente. AWS
Per ulteriori informazioni, consulta [Limita l'accesso al profilo dell'istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
Se si desidera bloccare l’accesso del pod a IMDS, specificare le impostazioni necessarie nel modello di avvio.
1. Copia i seguenti contenuti sul dispositivo. Sostituisci i valori di esempio e quindi esegui il comando modificato per creare il file. `eks-nodegroup.yaml` Diverse impostazioni specificate durante l'implementazione senza un modello di avvio vengono spostate nel modello di avvio. Se non si specifica una `version`, viene utilizzata la versione predefinita del modello.
```
cat >eks-nodegroup.yaml <
**Creare un gruppo di nodi gestiti utilizzando la Console di gestione AWS **
1. Attendi che lo stato del cluster risulti `ACTIVE`. Non è possibile creare un gruppo di nodi gestiti per un cluster non ancora `ACTIVE`.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il nome del cluster in cui desideri creare un gruppo di nodi gestiti.
1. Seleziona la scheda **Compute** (Calcolo).
1. Scegli **Add node group** (Aggiungi gruppo di nodi).
1. Nella pagina **Configura il gruppo di nodi**, compila i parametri di conseguenza e quindi scegli **Successivo**.
+ **Nome**: inserisci un nome univoco per il gruppo di nodi gestiti. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.
+ **Ruolo IAM del nodo**: scegli il ruolo dell'istanza del nodo da utilizzare con il gruppo di nodi. Per ulteriori informazioni, consulta [Ruolo IAM del nodo Amazon EKS](create-node-role.md).
**Importante**
Non è possibile usare lo stesso ruolo utilizzato per creare i cluster.
Consigliamo di utilizzare un ruolo che non è attualmente in uso da alcun gruppo di nodi autogestiti. In caso contrario, prevedi l'utilizzo di un nuovo gruppo di nodi autogestiti. Per ulteriori informazioni, consulta [Eliminare un gruppo di nodi gestito dal cluster](delete-managed-node-group.md).
+ **Usa modello di avvio** (Facoltativo): scegli se desideri utilizzare un modello di avvio esistente. Seleziona un **Launch Template Name** (Nome del modello di avvio). Quindi, seleziona una **Launch template version** (Versione del modello di avvio). Se non si seleziona una versione, Amazon EKS utilizza la versione predefinita del modello. I modelli di avvio permettono una maggiore personalizzazione del gruppo di nodi, ad esempio consentendo di implementare un’AMI personalizzata, assegnare un numero significativamente superiore di indirizzi IP ai pod, assegnare indirizzi IP ai pod da un intervallo CIDR diverso da quello dell’istanza e implementare i nodi in un cluster senza accesso a Internet in uscita. Per ulteriori informazioni, consultare [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md), [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md) e [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md).
Il modello di avvio deve soddisfare i requisiti descritti nella pagina [Customize managed nodes with launch templates](launch-templates.md). Se non si utilizza il proprio modello, l’API di Amazon EKS crea un modello di avvio Amazon EC2 predefinito nell’account e implementa il gruppo di nodi utilizzando il modello di avvio predefinito.
Se implementate [i ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md), assegnate le autorizzazioni necessarie direttamente a ogni Pod che richiede l'accesso ai AWS servizi e nessun Pod del cluster richiede l'accesso a IMDS per altri motivi, come il recupero della AWS regione corrente, allora potete anche disabilitare l'accesso a IMDS per i Pod che non utilizzano la rete host in un modello di lancio. Per ulteriori informazioni, consulta [Limita l'accesso al profilo dell'istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ **Etichette Kubernetes** – (Facoltativo) È possibile scegliere di applicare etichette Kubernetes ai nodi del gruppo di nodi gestiti.
+ **Taint Kubernetes**: (facoltativo) è possibile scegliere di applicare i taint Kubernetes ai nodi del gruppo di nodi gestiti. Nel menu **Effetto** sono disponibili le opzioni ` NoSchedule `, ` NoExecute ` e ` PreferNoSchedule `. Per ulteriori informazioni, consulta [Ricetta: impedire che i pod siano programmati su nodi specifici](node-taints-managed-node-groups.md).
+ **Tag**: (facoltativo) è possibile scegliere di aggiungere tag al gruppo di nodi gestiti Amazon EKS. Questi tag non si propagano ad altre risorse del gruppo di nodi, ad esempio gruppi Auto Scaling o istanze. Per ulteriori informazioni, consulta [Organizzazione delle risorse Amazon EKS con tag](eks-using-tags.md).
1. Nella pagina **Imposta configurazione di calcolo e dimensionamento**, compila i parametri di conseguenza e quindi scegli **Successivo**.
+ **Tipo di AMI:** selezionare un tipo di AMI. Se stai distribuendo istanze Arm, assicurati di rivedere le considerazioni in [Arm Amazon Linux AMIs ottimizzato per Amazon EKS prima](eks-optimized-ami.md#arm-ami) della distribuzione.
Se nella pagina precedente sono stati specificati un modello di avvio e un’AMI nel modello, non è possibile selezionare un valore. Viene visualizzato il valore del modello. L’AMI specificata nel modello deve soddisfare i requisiti indicati alla pagina [Specifying an AMI](launch-templates.md#launch-template-custom-ami).
+ **Tipo di capacità**: seleziona un tipo di capacità. Per ulteriori informazioni sulla scelta di un tipo di capacità, consulta [Tipi di capacità del gruppo di nodi gestiti](managed-node-groups.md#managed-node-group-capacity-types). Non è possibile combinare diversi tipi di capacità all’interno dello stesso gruppo di nodi. Se desideri utilizzare entrambi i tipi di capacità, crea gruppi di nodi separati, ognuno con i propri tipi di capacità e istanza. [ GPUs Per informazioni sul provisioning e la scalabilità dei nodi di lavoro accelerati da GPU, consulta Reserve for managed node groups](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html).
+ **Tipi di istanza**: per impostazione predefinita, viene specificato uno o più tipi di istanza. Per rimuovere un tipo di istanza predefinito, seleziona il `X` sul lato destro del tipo di istanza. Scegli il tipo di istanza da utilizzare nel gruppo di nodi gestiti. Per ulteriori informazioni, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md).
Nella console viene visualizzato un insieme di tipi di istanza di uso comune. Se devi creare un gruppo di nodi gestito con un tipo di istanza che non viene visualizzato`eksctl`, usa la AWS CLI o un SDK per creare il gruppo di nodi. AWS CloudFormation Se nella pagina precedente è stato specificato un modello di avvio, non è possibile selezionare un valore perché il tipo di istanza deve essere specificato nel modello di avvio. Viene visualizzato il valore del modello di avvio. Se è stato selezionato **Spot** per **Tipo capacità**, al fine di migliorare la disponibilità è consigliabile specificare più tipi di istanza.
+ **Dimensioni disco**: inserire le dimensioni del disco (in GiB) da utilizzare per il volume root del nodo.
Se nella pagina precedente è stato specificato un modello di avvio, non è possibile selezionare un valore perché deve essere specificato nel modello di avvio.
+ **Dimensione desiderata**: specifica il numero corrente di nodi che il gruppo di nodi gestiti deve mantenere all'avvio.
**Nota**
Amazon EKS non aumenta o riduce orizzontalmente in automatico il gruppo di nodi. Tuttavia, è possibile configurare il Cluster Autoscaler di Kubernetes per eseguire questa operazione. Per ulteriori informazioni, consulta [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) on. AWS
+ **Dimensione minima**: specifica il numero minimo di nodi a cui il gruppo di nodi gestiti può essere ridotto.
+ **Dimensione massima**: specifica il numero massimo di nodi a cui il gruppo di nodi gestiti può essere aumentato.
+ **Configurazione dell'aggiornamento dei gruppi di nodi**: (facoltativo) puoi selezionare il numero o la percentuale di nodi da aggiornare in parallelo. Questi nodi non saranno disponibili durante l'aggiornamento. Per **Numero massimo non disponibile**, seleziona una delle seguenti opzioni e specifica un **Valore**:
+ **Numero**: seleziona e specifica il numero di nodi nel gruppo nodi che possono essere aggiornati in parallelo.
+ **Percentuale**: seleziona e specifica la percentuale di nodi nel gruppo di nodi che possono essere aggiornati in parallelo. Questa funzione è utile se disponi di un numero elevato di nodi nel gruppo di nodi.
+ **Configurazione di riparazione automatica del nodo**: (facoltativo) se viene attivata la casella di controllo **Abilita la riparazione automatica del nodo**, Amazon EKS sostituirà automaticamente i nodi quando si verificano i problemi rilevati. Per ulteriori informazioni, consulta [Rileva i problemi di integrità dei nodi e abilita la riparazione automatica dei nodi](node-health.md).
1. Nella pagina **Specifica reti**, compila i parametri opportunamente, quindi scegli **Successivo**.
+ **Sottoreti**: sceglii le sottoreti in cui avviare i nodi gestiti.
**Importante**
Se si esegue un’applicazione stateful in più zone di disponibilità supportate dai volumi Amazon EBS e che utilizza il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes, è necessario configurare più gruppi di nodi, ognuno dei quali definito per una singola zona di disponibilità. Inoltre, è necessario abilitare la funzionalità `--balance-similar-node-groups`.
**Importante**
Se si sceglie una sottorete pubblica e nel cluster è abilitato solo l'endpoint del server API pubblico, è necessario che la sottorete disponga di `MapPublicIPOnLaunch` impostato su `true` per consentire alle istanze di unirsi correttamente a un cluster. Se la sottorete è stata creata utilizzando `eksctl` o i [AWS CloudFormation modelli forniti da Amazon EKS](creating-a-vpc.md) a partire dal 26 marzo 2020, allora questa impostazione è già impostata su. `true` Se le sottoreti sono state create con `eksctl` o i AWS CloudFormation modelli prima del 26 marzo 2020, devi modificare l'impostazione manualmente. Per ulteriori informazioni, vedere [Modifica dell'attributo di IPv4 indirizzamento pubblico per la](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) sottorete.
Se si utilizza un modello di avvio e si specificano più interfacce di rete, Amazon EC2 non assegnerà automaticamente un indirizzo `IPv4` pubblico, anche se `MapPublicIpOnLaunch` è impostato su `true`. Affinché i nodi possano unirsi al cluster in questo scenario, è necessario abilitare l’endpoint del server API privato del cluster, oppure avviare i nodi in una sottorete privata con accesso Internet in uscita fornito attraverso un metodo alternativo, ad esempio un gateway NAT. Per ulteriori informazioni, consultare la pagina [Amazon EC2 instance IP addressing](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) della *Guida per l’utente di Amazon EC2*.
+ **Configurazione dell'accesso SSH ai nodi** (facoltativo). L'abilitazione di SSH consente di connettersi alle istanze e raccogliere informazioni diagnostiche in caso di problemi. Consigliamo vivamente di abilitare l'accesso remoto quando crei un gruppo di nodi. Non è possibile abilitare l’accesso remoto dopo la creazione del gruppo di nodi.
Se si sceglie di utilizzare un modello di avvio, questa opzione non viene visualizzata. Per abilitare l'accesso remoto ai nodi, specifica una coppia di chiavi nel modello di avvio e assicurati che la porta appropriata sia aperta ai nodi nei gruppi di sicurezza specificati nel modello di avvio. Per ulteriori informazioni, consulta [Utilizzo di gruppi di sicurezza personalizzati](launch-templates.md#launch-template-security-groups).
**Nota**
Per Windows, questo comando non abilita SSH. Associa, invece, la coppia di chiavi Amazon EC2 all'istanza e ti consente di eseguire il protocollo RDP nell'istanza.
+ Per **Coppia di chiavi SSH** (facoltativo), scegli una chiave SSH Amazon EC2 da utilizzare. Per informazioni su Linux, consultare [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Per informazioni su Windows, consultare [Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) nella *Guida per l’utente di Amazon EC2*. Se si sceglie di utilizzare un modello di avvio, non è possibile selezionarne una. Quando viene fornita una chiave SSH Amazon EC2 per i gruppi di nodi che utilizzano Bottlerocket AMIs, viene abilitato anche il contenitore amministrativo. Per ulteriori informazioni, consulta [Container amministratore](https://github.com/bottlerocket-os/bottlerocket#admin-container) su GitHub.
+ Per **Autorizzazione di accesso remoto SSH da**, se desideri limitare l'accesso a istanze specifiche, seleziona i gruppi di sicurezza associati a tali istanze. Se non si selezionano gruppi di sicurezza specifici, l’accesso SSH è consentito da qualsiasi indirizzo di Internet (`0.0.0.0/0`).
1. Nella pagina **Rivedi e crea**, controlla la configurazione del gruppo di nodi gestiti e scegli **Crea**.
Se i nodi di lavoro non riescono a unirsi al cluster, consultare [Impossibile aggiungere i nodi al cluster](troubleshooting.md#worker-node-fail) nel capitolo dedicato alla risoluzione dei problemi.
1. Guarda lo stato dei nodi e attendi che raggiungano lo stato `Ready`.
```
kubectl get nodes --watch
```
1. (Solo nodi GPU) Se hai scelto un tipo di istanza GPU e un'AMI accelerata ottimizzata per Amazon EKS, devi applicare [il plug-in del dispositivo NVIDIA per](https://github.com/NVIDIA/k8s-device-plugin) Kubernetes sul tuo cluster. DaemonSet Sostituiscilo *vX.X.X* con la versione di [s-device-pluginNVIDIA/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) desiderata prima di eseguire il comando seguente.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
## Installare i componenti aggiuntivi Kubernetes
Ora che si dispone di un cluster Amazon EKS funzionante con nodi, è possibile avviare l’installazione dei componenti aggiuntivi Kubernetes e l’implementazione di applicazioni al cluster. I seguenti argomenti della documentazione consentono di estendere la funzionalità del cluster.
+ Il [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) in grado di creare il cluster è l’unico principale che può effettuare chiamate al server API Kubernetes tramite `kubectl` o la Console di gestione AWS. Se si desidera che altri principali IAM abbiano accesso al cluster, è necessario aggiungerli. Per ulteriori informazioni, consultare [Concedi agli utenti e ai ruoli IAM l'accesso a Kubernetes APIs](grant-k8s-access.md) e [Autorizzazioni richieste](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Consigliamo di bloccare l’accesso dei pod a IMDS se si verificano le seguenti condizioni:
+ Prevedi di assegnare ruoli IAM a tutti gli account del servizio Kubernetes in modo che i pod dispongano solo delle autorizzazioni minime necessarie.
+ Nessun pod nel cluster richiede l'accesso al servizio di metadati dell'istanza Amazon EC2 (IMDS) per altri motivi, come il recupero della regione corrente. AWS
Per ulteriori informazioni, consulta [Limita l’accesso al profilo dell’istanza assegnato al nodo (worker)](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ Configurare il [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di Kubernetes per regolare automaticamente il numero di nodi nei gruppi di nodi.
+ Implementare [un’applicazione di esempio](sample-deployment.md) al cluster.
+ [Organizzare e monitorare le risorse del cluster](eks-managing.md) con strumenti importanti per la gestione.
# Aggiornamento del gruppo di nodi gestito per il cluster
Quando si avvia un aggiornamento di un gruppo di nodi gestiti, Amazon EKS aggiorna automaticamente i nodi, completando i passaggi elencati in [Understand each phase of node updates](managed-node-update-behavior.md). Se si utilizza un’AMI ottimizzata per Amazon EKS, Amazon EKS applica automaticamente le patch di sicurezza più recenti e gli aggiornamenti del sistema operativo ai nodi come parte dell’ultima versione di AMI.
Esistono diversi scenari in cui è utile aggiornare la versione o la configurazione del gruppo di nodi gestiti Amazon EKS:
+ Hai aggiornato la versione di Kubernetes per il cluster Amazon EKS e vuoi aggiornare i nodi per utilizzare la stessa versione di Kubernetes.
+ Una nuova versione dell'AMI è disponibile per il gruppo di nodi gestiti. Per ulteriori informazioni sulle versioni AMI, consultare le seguenti sezioni:
+ [Recupero delle informazioni sulla versione dell’AMI Amazon Linux](eks-linux-ami-versions.md)
+ [Crea nodi con Bottlerocket ottimizzato AMIs](eks-optimized-ami-bottlerocket.md)
+ [Recupero delle informazioni sulla versione delle AMI Windows](eks-ami-versions-windows.md)
+ Per regolare il conteggio minimo, massimo o desiderato delle istanze nel gruppo di nodi gestiti.
+ Per aggiungere o rimuovere le etichette Kubernetes dalle istanze del gruppo di nodi gestiti.
+ Vuoi aggiungere o rimuovere AWS tag dal tuo gruppo di nodi gestito.
+ È necessario implementare una nuova versione di un modello di avvio con modifiche alla configurazione, ad esempio un'AMI personalizzata aggiornata.
+ Hai distribuito una versione `1.9.0` o successiva del componente aggiuntivo Amazon VPC CNI, abilitato il componente aggiuntivo per la delega dei prefissi e desideri che AWS nuove istanze Nitro System in un gruppo di nodi supportino un numero significativamente maggiore di Pod. Per ulteriori informazioni, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md).
+ Hai abilitato la delega del prefisso IP per i nodi Windows e desideri che nuove istanze di AWS Nitro System in un gruppo di nodi supportino un numero significativamente maggiore di Pod. Per ulteriori informazioni, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md).
Se esiste una versione dell’AMI più recente per la versione Kubernetes del gruppo di nodi gestiti rispetto a quella in esecuzione nel gruppo di nodi, è possibile aggiornare quest’ultima per utilizzare la nuova versione dell’AMI. Analogamente, se nel cluster è in esecuzione una versione di Kubernetes più recente rispetto al gruppo di nodi, è possibile aggiornare il gruppo di nodi per utilizzare la versione più recente dell’AMI che corrisponde alla versione di Kubernetes del cluster.
Quando un nodo in un gruppo di nodi gestiti è terminato a causa di un’operazione di dimensionamento o di un aggiornamento, i pod nel nodo sono svuotati per primi. Per ulteriori informazioni, consulta [Comprendi ogni fase degli aggiornamenti dei nodi](managed-node-update-behavior.md).
## Aggiornare la versione di un gruppo di nodi
È possibile aggiornare la versione di un gruppo di nodi con uno dei seguenti:
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [Console di gestione AWS](#console_update_managed_nodegroup)
La versione a cui si aggiorna non può essere successiva alla versione del piano di controllo.
## `eksctl`
**Aggiornare un gruppo di nodi gestito utilizzando `eksctl`**
Aggiorna un gruppo di nodi gestiti alla stessa versione AMI più recente di Kubernetes attualmente implementata nei nodi con il comando seguente. Sostituisci ogni *example value* con i valori in tuo possesso.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**Nota**
Se stai aggiornando un gruppo di nodi implementato con un modello di avvio a una nuova versione del modello di avvio, aggiungi `--launch-template-version version-number ` al precedente comando. Il modello di avvio deve soddisfare i requisiti descritti in [Customize managed nodes with launch templates](launch-templates.md). Se il modello di avvio include un’AMI personalizzata, l’AMI deve soddisfare i requisiti in [Specificare un’AMI](launch-templates.md#launch-template-custom-ami). Quando si aggiorna il gruppo di nodi a una versione più recente del modello di avvio, tutti i nodi sono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata.
Non è possibile aggiornare direttamente un gruppo di nodi implementato senza un modello di avvio a una nuova versione del modello di avvio. È invece necessario implementare un nuovo gruppo di nodi utilizzando il modello di avvio per aggiornare il gruppo di nodi a una nuova versione del modello di avvio.
È possibile aggiornare un gruppo di nodi alla stessa versione della versione Kubernetes del piano di controllo. Ad esempio, se hai un cluster che esegue Kubernetes `1.35`, puoi aggiornare i nodi che attualmente eseguono Kubernetes `1.34` alla versione `1.35` con il comando seguente.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## Console di gestione AWS
**Aggiornare un gruppo di nodi gestito utilizzando Console di gestione AWS **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegliere il cluster che contiene il gruppo di nodi da aggiornare.
1. Se almeno un gruppo di nodi dispone di un aggiornamento disponibile, nella parte superiore della pagina viene visualizzata una casella di notifica dell'aggiornamento disponibile. Se selezioni la scheda **Calcolo**, visualizzerai **Aggiorna ora** nella colonna **Versione rilascio AMI** nella tabella **Gruppi di nodi** per il gruppo di nodi per cui è disponibile un aggiornamento. Per aggiornare il gruppo di nodi, scegli **Update now** (Aggiorna ora).
Non verrà visualizzata una notifica per i gruppi di nodi implementati con un’AMI personalizzata. Se i nodi vengono implementati con un'AMI personalizzata, completare la procedura seguente per implementare una nuova AMI personalizzata aggiornata.
1. Crea una nuova versione dell'AMI.
1. Creare una nuova versione del modello di avvio con il nuovo ID AMI.
1. Aggiornamento dei i nodi alla nuova versione del modello di avvio.
1. Nella finestra di dialogo **Update node group version** (Aggiorna la versione del gruppo di nodi), attiva o disattiva le seguenti opzioni:
+ **Update node group version** (Aggiorna la versione del gruppo di nodi): questa opzione non è disponibile se hai implementato un'AMI personalizzata o se l'AMI ottimizzata per Amazon EKS attualmente è disponibile nella versione più recente del cluster.
+ **Change launch template version** (Modifica la versione del modello di avvio): questa opzione non è disponibile se il gruppo di nodi è implementato senza un modello di avvio personalizzato. È possibile aggiornare la versione del modello di avvio solo per un gruppo di nodi implementato con un modello di avvio personalizzato. Seleziona la **Launch template version** (Versione del modello di avvio) a cui eseguire l'aggiornamento del gruppo di nodi. Se il gruppo di nodi è configurato con un'AMI personalizzata, anche la versione selezionata deve specificare un'AMI. Quando si esegue l'aggiornamento a una versione più recente del modello di avvio, tutti i nodi vengono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata.
1. Per **Update strategy** (Strategia aggiornamento), seleziona una delle seguenti opzioni:
+ **Aggiornamento in sequenza**: questa opzione rispetta i budget di interruzione del pod per il cluster. Gli aggiornamenti non riescono se c’è un problema di budget che interrompe il pod, che fa sì che Amazon EKS non riesca a svuotare correttamente i pod in esecuzione su questo gruppo di nodi.
+ **Forza aggiornamento**: questa opzione non rispetta i budget per le interruzioni dei pod. Gli aggiornamenti sono eseguiti indipendentemente dai problemi di budget di interruzione del pod forzando il riavvio dei nodi.
1. Scegliere **Aggiorna**.
## Modificare la configurazione di un gruppo di nodi
È possibile modificare parte della configurazione di un gruppo di nodi gestiti.
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegliere il cluster che contiene il gruppo di nodi da modificare.
1. Seleziona la scheda **Compute** (Calcolo).
1. Seleziona il gruppo di nodi da modificare, e scegli **Edit** (Modifica).
1. (Facoltativo) Nella pagina **Edit node group** (Modifica gruppo di nodi), effettua le seguenti operazioni:
1. Modifica la **configurazione di scalabilità del gruppo di nodi**.
+ **Dimensione desiderata**: specifica il numero corrente di nodi che il gruppo di nodi gestiti deve mantenere.
+ **Dimensione minima**: specifica il numero minimo di nodi a cui il gruppo di nodi gestiti può essere ridotto.
+ **Dimensione massima**: specifica il numero massimo di nodi a cui il gruppo di nodi gestiti può essere aumentato orizzontalmente. Per il numero massimo di nodi supportati in un gruppo di nodi, vedere [Visualizzazione e gestione di quote di servizio di Amazon EKS e Fargate](service-quotas.md).
1. (Facoltativo) Aggiungi o rimuovi **etichette Kubernetes** ai nodi nel gruppo di nodi. Le etichette mostrate qui sono solo le etichette applicate con Amazon EKS. Altre etichette, non mostrate qui, possono essere presenti sui nodi.
1. (Facoltativo) Aggiungi o rimuovi **taint Kubernetes** ai nodi nel gruppo di nodi. I taint aggiunti possono avere l'effetto di ` NoSchedule `, ` NoExecute `, oppure ` PreferNoSchedule `. Per ulteriori informazioni, consulta [Ricetta: impedire che i pod siano programmati su nodi specifici](node-taints-managed-node-groups.md).
1. (Facoltativo) Aggiungi o rimuovi **Tag** dalla risorsa del gruppo di nodi. Questi tag vengono applicati solo al gruppo di nodi Amazon EKS. I tag dei gruppi di nodi non si propagano ad altre risorse come istanze o le sottoreti di Amazon EC2 nel gruppo di nodi.
1. (Facoltativo) Modifica la **Configurazione dell'aggiornamento del gruppo di nodi**. Seleziona un'opzione tra **Numero** o **Percentuale**.
+ **Numero**: seleziona e specifica il numero di nodi nel gruppo nodi che possono essere aggiornati in parallelo. Questi nodi non saranno disponibili durante l'aggiornamento.
+ **Percentuale**: selezionare e specificare la percentuale di nodi nel gruppo di nodi che possono essere aggiornati in parallelo. Questi nodi non saranno disponibili durante l'aggiornamento. Questa funzione è utile se si dispone di diversi nodi nel gruppo di nodi.
1. Al termine della modifica, scegli **Salva modifiche**.
**Importante**
Quando si aggiorna la configurazione del gruppo di nodi, la modifica di Pod [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)non rispetta i budget di interruzione delle attività dei Pod (). PDBs A differenza del processo di [aggiornamento del gruppo di nodi](managed-node-update-behavior.md) (che prosciuga i nodi e li rispetta PDBs durante la fase di aggiornamento), l'aggiornamento della configurazione di scalabilità causa la chiusura immediata dei nodi tramite una chiamata di scale-down di Auto Scaling Group (ASG). Ciò avviene senza considerarlo PDBs, indipendentemente dalla dimensione target a cui si sta effettuando la scalabilità. Ciò significa che quando riduci il numero `desiredSize` di un gruppo di nodi gestiti da Amazon EKS, i Pod vengono eliminati non appena i nodi vengono terminati, senza onorarne nessuno. PDBs
# Comprendi ogni fase degli aggiornamenti dei nodi
La strategia di aggiornamento del nodo (worker) gestito di Amazon EKS ha quattro fasi diverse descritte nelle sezioni seguenti.
## Fase di configurazione
La fase di configurazione prevede i seguenti passaggi:
1. Crea una nuova versione del modello di avvio Amazon EC2 per il gruppo Auto Scaling associato al gruppo di nodi. La nuova versione del modello di avvio utilizza l’AMI di destinazione o una versione del modello di avvio personalizzata per l’aggiornamento.
1. Il gruppo Auto Scaling viene aggiornato per utilizzare la versione più recente del modello di avvio.
1. Determina la quantità massima di nodi da aggiornare in parallelo utilizzando la proprietà `updateConfig` per il gruppo di nodi. Il massimo non disponibile ha una quota di 100 nodi. Il valore di default è un nodo. Per ulteriori informazioni, consulta la proprietà [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) nella *Documentazione di riferimento delle API di Amazon EKS*.
## Fase di scalabilità
Quando si aggiornano i nodi in un gruppo di nodi gestiti, i nodi aggiornati vengono avviati nella stessa zona di disponibilità di quelli in fase di aggiornamento. Per garantire questo posizionamento, utilizziamo il ribilanciamento della zona di disponibilità di Amazon EC2. Per ulteriori informazioni, consulta [Availability Zone Rebalancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) nella *Guida per l’utente di Amazon EC2 Auto Scaling*. Per soddisfare questo requisito, è possibile avviare fino a due istanze per zona di disponibilità nel gruppo di nodi gestiti.
La fase di scalabilità prevede i seguenti passaggi:
1. Incrementa la dimensione massima e la dimensione desiderata del gruppo Auto Scaling in base alla scelta maggiore tra:
+ Fino a due volte il numero di zone di disponibilità in cui è stato implementato il gruppo Auto Scaling.
+ Il massimo non disponibile per l’aggiornamento.
Ad esempio, se il gruppo di nodi ha cinque zone di disponibilità e `maxUnavailable` è uno, il processo di aggiornamento può avviare al massimo 10 nodi. Tuttavia, quando `maxUnavailable` è 20 (o comunque superiore a 10), il processo avvia 20 nuovi nodi.
1. Dopo aver dimensionato il gruppo Auto Scaling, verifica se i nodi che utilizzano la configurazione più recente sono presenti nel gruppo di nodi. Questo passaggio ha esito positivo solo quando soddisfa i seguenti criteri:
+ Almeno un nuovo nodo viene avviato in ogni zona di disponibilità in cui esiste il nodo.
+ Ogni nuovo nodo deve essere nello stato `Ready`.
+ I nuovi nodi devono avere etichette applicate da Amazon EKS.
Queste sono le etichette applicate da Amazon EKS sui nodi (worker) di un normale gruppo di nodi:
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
Queste sono le etichette applicate da Amazon EKS sui nodi (worker) in un modello di avvio personalizzato o un gruppo di nodi AMI:
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
1. Contrassegna i nodi come non programmabili per evitare di programmare nuovi pod. Inoltre, etichetta i nodi con `node.kubernetes.io/exclude-from-external-load-balancers=true` per rimuovere i vecchi nodi dai sistemi di bilanciatore del carico prima di terminare i nodi.
Di seguito sono riportati i motivi noti che portano a un errore `NodeCreationFailure` in questa fase:
**Capacità insufficiente nella zona di disponibilità**
Esiste la possibilità che la zona di disponibilità non abbia capacità disponibile per i tipi di istanza richiesti. Si consiglia di configurare più tipi di istanze durante la creazione di un gruppo di nodi gestiti.
**Limiti delle istanze EC2 dell’account**
Potrebbe essere necessario aumentare il numero di istanze Amazon EC2 che il l’account può eseguire contemporaneamente utilizzando Service Quotas. Per ulteriori informazioni, consulta [Service Quotas di EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) nella *Guida per l’utente di Amazon Elastic Compute Cloud per le istanze Linux*.
**Dati utente personalizzati**
I dati utente personalizzati possono talvolta interrompere il processo di bootstrap. Questo scenario può portare al mancato avvio di `kubelet` sul nodo o sui nodi che non ricevono le etichette Amazon EKS previste. Per ulteriori informazioni, consulta [Specifica di un'AMI](launch-templates.md#launch-template-custom-ami).
**Qualsiasi modifica che renda un nodo non integro o non pronto**
La pressione del disco del nodo, la pressione della memoria e condizioni simili possono far sì che un nodo non assuma lo stato `Ready`.
**Ogni nodo si avvia al massimo entro 15 minuti**
Se un nodo impiega più di 15 minuti per avviarsi e unirsi al cluster, si verificherà il timeout dell’aggiornamento. Questo è il runtime totale per il bootstrap di un nuovo nodo misurato dal momento in cui è necessario un nuovo nodo al momento in cui si unisce al cluster. Quando si aggiorna un gruppo di nodi gestito, il contatore temporale si avvia non appena la dimensione del gruppo Auto Scaling aumenta.
## Fase di aggiornamento
La fase di aggiornamento si comporta in due modi diversi, a seconda della *strategia di aggiornamento*. Esistono due strategie di aggiornamento: **predefinita** e **minimale**.
Consigliamo una strategia predefinita nella maggior parte degli scenari. Infatti, questa crea nuovi nodi prima di terminare quelli vecchi, in modo da mantenere la capacità disponibile durante la fase di aggiornamento. La strategia minimale è utile in scenari in cui si è limitati per quanto riguarda risorse o costi, ad esempio con acceleratori hardware come le GPU. Infatti, termina i vecchi nodi prima di creare quelli nuovi, in modo che la capacità totale non aumenti mai oltre la quantità configurata.
La strategia di aggiornamento *predefinita* prevede i seguenti passaggi:
1. Aumenta la quantità di nodi (numero desiderato) nel gruppo Auto Scaling, facendo sì che il gruppo di nodi crei nodi aggiuntivi.
1. Seleziona casualmente un nodo che deve essere aggiornato, fino al massimo non disponibile configurato per il gruppo di nodi.
1. Svuota i pod dal nodo. Se i pod non lasciano il nodo entro 15 minuti e non c’è un flag di forzatura, la fase di aggiornamento non riesce con errore `PodEvictionFailure`. Per questo scenario, è possibile applicare il flag di forzatura con la richiesta `update-nodegroup-version` di eliminare i pod.
1. Isola il nodo dopo che ogni pod è stato espulso e aspetta 60 secondi. Ciò consente al controller di servizio di non inviare nuove richieste a questo nodo, e lo rimuove dall’elenco di nodi attivi.
1. Invia una richiesta di interruzione al gruppo con scalabilità automatica per il nodo isolato.
1. Ripete i passaggi di aggiornamento precedenti fino a quando non vi sono nodi nel gruppo implementato con la versione precedente del modello di avvio.
La strategia di aggiornamento *minimale* prevede i seguenti passaggi:
1. All’inizio isola tutti i nodi del gruppo di nodi, in modo che il controller di servizio non invii nuove richieste a questi nodi.
1. Seleziona casualmente un nodo che deve essere aggiornato, fino al massimo non disponibile configurato per il gruppo di nodi.
1. Drena i Pod dai nodi selezionati. Se i pod non lasciano il nodo entro 15 minuti e non c’è un flag di forzatura, la fase di aggiornamento non riesce con errore `PodEvictionFailure`. Per questo scenario, puoi applicare il flag di forzatura con la richiesta `update-nodegroup-version` di eliminare i pod.
1. Dopo che ogni pod è stato rimosso e ha atteso 60 secondi, invia una richiesta di interruzione al gruppo Auto Scaling per i nodi selezionati. Il gruppo Auto Scaling crea nuovi nodi (lo stesso numero di nodi selezionati) per sostituire la capacità mancante.
1. Ripete i passaggi di aggiornamento precedenti fino a quando non vi sono nodi nel gruppo implementato con la versione precedente del modello di avvio.
### Errori `PodEvictionFailure` durante la fase di aggiornamento
Di seguito sono riportati i motivi noti che portano a un errore `PodEvictionFailure` in questa fase:
**PDB aggressivo**
Sul pod è definito un PDB aggressivo oppure sono presenti più PDB che puntano allo stesso pod.
**Implementazione che tollera tutti i taint**
Una volta espulso ogni pod, il nodo dovrebbe essere vuoto in quanto [oggetto di taint](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nei passaggi precedenti. Tuttavia, se l’implementazione tollera ogni taint, è più probabile che il nodo non sia vuoto, causando un errore di espulsione dal pod.
## Fase di dimensionamento
La fase di dimensionamento diminuisce di uno la dimensione massima del gruppo Auto Scaling e la dimensione desiderata per tornare ai valori prima dell’avvio dell’aggiornamento.
Se il flusso di lavoro di aggiornamento determina che il Cluster Autoscaler stia dimensionando il gruppo di nodi durante la fase di dimensionamento del flusso di lavoro, esce immediatamente senza riportare il gruppo di nodi alle dimensioni originali.
# Personalizzazione dei nodi gestiti con modelli di avvio
Per il massimo livello di personalizzazione, puoi distribuire nodi gestiti con il tuo modello di lancio in base ai passaggi di questa pagina. L'utilizzo di un modello di avvio consente funzionalità come fornire argomenti di bootstrap durante la distribuzione di un nodo (ad esempio, argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi), assegnare indirizzi IP ai Pod da un blocco CIDR diverso dall'indirizzo IP assegnato al nodo, distribuire la propria AMI personalizzata ai nodi o distribuire il proprio CNI personalizzato sui nodi.
Quando fornisci il tuo modello di avvio alla prima creazione di un gruppo di nodi gestito, in seguito avrai anche una maggiore flessibilità. Dopo aver implementato un gruppo di nodi gestiti con un modello di avvio personalizzato, potrai aggiornarlo in maniera iterativa con una versione diversa dello stesso modello. Quando si aggiorna il gruppo di nodi a una versione diversa del modello di avvio, tutti i nodi del gruppo vengono riciclati in modo da corrispondere alla nuova configurazione della versione del modello di avvio specificata.
I gruppi di nodi gestiti vengono sempre implementati con un modello di avvio da utilizzare con gruppo di Amazon EC2 Auto Scaling. Quando non è fornito un modello di avvio, l’API Amazon EKS ne crea automaticamente uno con i valori predefiniti nel tuo account. Tuttavia, consigliamo di non modificare i modelli di avvio generati automaticamente. Inoltre, i gruppi di nodi esistenti che non utilizzano un modello di avvio personalizzato non possono essere aggiornati direttamente. A tale scopo, sarà invece necessario creare un nuovo gruppo di nodi con un modello di avvio personalizzato.
## Informazioni di base sulla configurazione del modello di avvio
Puoi creare un modello di lancio di Amazon EC2 Auto Scaling con la Console di gestione AWS CLI AWS o un SDK. AWS Per ulteriori informazioni, consulta [Creazione di un modello di avvio per un gruppo con scalabilità automatica](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*. Alcune impostazioni di un modello di avvio sono simili a quelle utilizzate per la configurazione dei nodi gestiti. Quando si implementa o si aggiorna un gruppo di nodi con un modello di avvio, è necessario specificare alcune impostazioni nella configurazione del gruppo di nodi o nel modello di avvio. Non specificare un’impostazione in entrambe le posizioni. Se un’impostazione è impostata dove non dovrebbe, operazioni come la creazione o l’aggiornamento di un gruppo di nodi non hanno esito positivo.
Nella tabella seguente sono elencate le impostazioni vietate in un modello di avvio. Elenca inoltre impostazioni simili, se disponibili, che sono necessarie per la configurazione del gruppo di nodi gestiti. Le impostazioni elencate sono quelle visualizzate nella console. Potrebbero avere nomi simili ma diversi nella AWS CLI e nell'SDK.
| Modello di avvio – Vietato | Configurazione del gruppo di nodi Amazon EKS |
| --- | --- |
| **Sottorete** in **Interfacce di rete** (**Aggiungi interfaccia di rete**) | **Sottoreti** in **Configurazione di rete del gruppo di nodi** nella pagina **Specifica reti** |
| **Profilo dell'istanza IAM** in **Dettagli avanzati** | **Ruolo IAM del nodo** in **Configurazione del gruppo di nodi** nella pagina **Configura gruppo di nodi** |
| **Comportamento di arresto** e **Interrompi - Iberna comportamento** in **Dettagli avanzati**. Mantieni default **Non includere nell’impostazione del modello di avvio** nel modello di avvio per entrambe le impostazioni. | Nessun equivalente. Amazon EKS deve controllare il ciclo di vita dell'istanza, non il gruppo Auto Scaling. |
Nella tabella seguente sono elencate le impostazioni vietate nella configurazione di un gruppo di nodi gestiti. Elenca inoltre impostazioni simili, se disponibili, richieste in un modello di avvio. Le impostazioni elencate sono quelle visualizzate nella console. Potrebbero avere nomi simili nella AWS CLI e nell'SDK.
| Configurazione del gruppo di nodi Amazon EKS – Vietata | Modello di avvio |
| --- | --- |
| (Solo se è stata specificata un'AMI personalizzata in un modello di avvio) **Tipo di AMI** in **Configurazione di calcolo del gruppo di nodi** sulla pagina **Imposta configurazione di calcolo e dimensionamento**: la console mostra il messaggio **Specificato nel modello di lancio** e l'ID AMI specificato. Se nel modello di avvio non è stato specificato **Applicazione e immagini OS (Amazon Machine Image)**, è possibile selezionare un’AMI nella configurazione del gruppo di nodi. | **Applicazione e immagini OS (Amazon Machine Image)** in **Contenuti del modello di avvio**: è necessario specificare un ID se soddisfi uno dei seguenti requisiti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/launch-templates.html) |
| **Dimensioni del disco** in **Configurazione di calcolo del gruppo di nodi** nella pagina **Imposta configurazione di calcolo e dimensionamento**: la console mostra il messaggio **Specificato nel modello di lancio**. | **Dimensioni** in **Archiviazione (volumi)** (**Aggiungi nuovo volume**). È necessario specificarlo nel modello di avvio. |
| **Coppia di chiavi SSH** in **Configurazione del gruppo di nodi** nella pagina **Specifica reti**: la console mostra la chiave specificata nel modello di avvio o mostra il messaggio **Non specificato nel modello di lancio**. | **Nome della coppia di chiavi** in **Coppia di chiavi (login)**. |
| Non è possibile specificare gruppi di sicurezza di origine a cui è consentito l’accesso remoto quando si utilizza un modello di avvio. | **Gruppi di sicurezza** in **Impostazioni di rete** per l'istanza o **Gruppi di sicurezza** in **Interfacce di rete** (**Aggiungi interfaccia di rete**), ma non entrambi. Per ulteriori informazioni, consulta [Utilizzo di gruppi di sicurezza personalizzati](#launch-template-security-groups). |
**Nota**
Se si esegue l'implementazione di un gruppo di nodi utilizzando un modello di avvio, specificare uno o nessun **Tipo di istanza** in **Contenuti del modello di avvio** in un modello di avvio. In alternativa, è possibile specificare 0-20 tipi di istanza per **Tipi di istanza** nella pagina **Impostare la configurazione di calcolo e dimensionamento** della console. In alternativa, è possibile farlo utilizzando altri strumenti che utilizzano l'API Amazon EKS. Se specifichi un tipo di istanza in un modello di avvio e si utilizza tale modello di avvio per implementare il gruppo di nodi, non è possibile specificare alcun tipo di istanza nella console o utilizzare altri strumenti che sfruttino l’API Amazon EKS. Se non specifichi un tipo di istanza in un modello di avvio nella console o in altri strumenti che utilizzano l’API Amazon EKS, il tipo di istanza `t3.medium` sarà utilizzato. Se il gruppo di nodi utilizza il tipo di capacità Spot, è consigliabile specificare più tipi di istanza utilizzando la console. Per ulteriori informazioni, consulta [Tipi di capacità del gruppo di nodi gestiti](managed-node-groups.md#managed-node-group-capacity-types).
Se i container che si implementano nel gruppo di nodi utilizzano Instance Metadata Service versione 2, assicurarsi di impostare il **Limite hop di risposta metadati** a `2` nel modello di avvio. Per ulteriori informazioni, consulta [Metadati e dati dell'utente delle istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) nella *Guida per l'utente di Amazon EC2*.
I modelli di avvio non supportano la funzionalità `InstanceRequirements` che consente la selezione flessibile del tipo di istanza.
## Assegnazione di tag a istanze Amazon EC2
É possibile utilizzare il parametro `TagSpecification` di un modello di avvio per specificare quali tag applicare alle istanze Amazon EC2 nel gruppo di nodi. L'entità IAM che chiama `CreateNodegroup` o `UpdateNodegroupVersion` APIs deve disporre delle autorizzazioni per `ec2:RunInstances` and `ec2:CreateTags` e i tag devono essere aggiunti al modello di lancio.
## Utilizzo di gruppi di sicurezza personalizzati
É possibile utilizzare un modello di avvio per specificare i [gruppi di sicurezza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) Amazon EC2 da applicare alle istanze del gruppo di nodi. Questo può essere nel parametro gruppi di sicurezza a livello di istanza o come parte dei parametri di configurazione dell'interfaccia di rete. Non è possibile avviare un’istanza da un modello di avvio che specifica sia il livello di istanza sia l’interfaccia di rete dei gruppi di sicurezza. Considerare le seguenti condizioni che si applicano all'utilizzo di gruppi di sicurezza personalizzati con gruppi di nodi gestiti:
+ Quando si utilizza Console di gestione AWS, Amazon EKS consente solo modelli di avvio con una singola specifica di interfaccia di rete.
+ Per impostazione predefinita, Amazon EKS applica il [Gruppo di sicurezza del cluster](sec-group-reqs.md) alle istanze nel gruppo di nodi, per facilitare la comunicazione tra i nodi e il piano di controllo. Se specifichi gruppi di sicurezza personalizzati nel modello di avvio utilizzando entrambe le opzioni menzionate in precedenza, Amazon EKS non aggiunge il gruppo di sicurezza del cluster. Pertanto, è necessario assicurarsi che le regole in entrata e in uscita dei gruppi di sicurezza abilitino la comunicazione con l'endpoint del cluster. Se le regole del gruppo di sicurezza non sono corrette, i nodi (worker) non possono aggiungersi al cluster. Per ulteriori informazioni sulle regole del gruppo di sicurezza, consultare [Visualizzazione dei requisiti relativi al gruppo di sicurezza Amazon EKS per cluster](sec-group-reqs.md).
+ Se è necessario l'accesso SSH alle istanze nel gruppo di nodi, includere un gruppo di sicurezza che consenta tale accesso.
## Dati utente Amazon EC2
Il modello di avvio include una sezione per i dati utente personalizzati. Puoi specificare le impostazioni di configurazione per il tuo gruppo di nodi in questa sezione senza creare manualmente singole impostazioni personalizzate AMIs. Per ulteriori informazioni sulle impostazioni disponibili per Bottlerocket, consulta [Using user data on](https://github.com/bottlerocket-os/bottlerocket#using-user-data). GitHub
É possibile fornire i dati utente Amazon EC2 nel tuo modello di avvio utilizzando `cloud-init` durante l'avvio delle istanze. Per ulteriori informazioni, consultare la documentazione [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). I dati utente possono essere utilizzati per eseguire operazioni di configurazione comuni. Sono comprese le seguenti opzioni:
+ [Inclusione di utenti o gruppi.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [Installazione di pacchetti](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
I dati utente di Amazon EC2 nei modelli di avvio utilizzati con gruppi di nodi gestiti devono essere nel formato di archivio [multiparte MIME per Amazon Linux AMIs e nel formato](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) TOML per Bottlerocket. AMIs Questo perché i dati utente vengono uniti con i dati utente Amazon EKS necessari ai nodi per aderire al cluster. Non specificare alcun comando nei dati utente che avviano o modificano `kubelet`. Questa operazione viene eseguita come parte dei dati utente uniti da Amazon EKS. Certi parametri `kubelet`, come l'impostazione delle etichette sui nodi, possono essere configurati direttamente tramite l'API dei gruppi di nodi gestiti.
**Nota**
Per ulteriori informazioni sulle personalizzazioni `kubelet` avanzate, tra cui l'avvio manuale o il passaggio a parametri di configurazione personalizzati, vedere [Specifica di un'AMI](#launch-template-custom-ami). Amazon EKS non unisce i dati utente se un ID AMI viene specificato in un modello di avvio.
I seguenti dettagli forniscono ulteriori informazioni sulla sezione dei dati utente.
**Dati utente di Amazon Linux 2**
È possibile unire più blocchi di dati utente in un unico blocco, detto file MIME in più parti. Ad esempio, è possibile combinare un hook di avvio del cloud per la configurazione del daemon Docker con uno script di shell dei dati utente che installa un pacchetto personalizzato. Un file MIME in più parti è composto dai seguenti elementi:
+ Il tipo di contenuto e la dichiarazione di delimitazione della parte: `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ La dichiarazione della versione MIME: `MIME-Version: 1.0`
+ Uno o più blocchi di dati utente, che contengono i seguenti elementi:
+ La delimitazione di apertura, che indica l'inizio di un blocco di dati utente: `--==MYBOUNDARY==`
+ La dichiarazione del tipo di contenuto per il blocco: `Content-Type: text/cloud-config; charset="us-ascii"`. Per ulteriori informazioni sui tipi di contenuto, consultare la documentazione di [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
+ Il contenuto dei dati utente, ad esempio un elenco di comandi shell o direttive `cloud-init`.
+ La delimitazione di chiusura, che indica la fine del file MIME in più parti: `--==MYBOUNDARY==--`
Di seguito è riportato un esempio di un file in più parti MIME che è possibile utilizzare per crearne uno.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**Dati utente di Amazon Linux 2023**
Amazon Linux 2023 (AL2023) introduce un nuovo processo di inizializzazione dei nodi `nodeadm` che utilizza uno schema di configurazione YAML. Se utilizzi gruppi di nodi autogestiti o un’AMI con un modello di avvio, ora dovrai fornire esplicitamente metadati del cluster aggiuntivi quando si crea un nuovo gruppo di nodi. Un [esempio](https://awslabs.github.io/amazon-eks-ami/nodeadm/) dei parametri minimi richiesti è come segue, dove ora `apiServerEndpoint`, `certificateAuthority` e il servizio `cidr` sono richiesti:
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
In genere questa configurazione è impostata nei dati utente, così com’è o incorporata in un documento MIME composto da più parti:
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
Nel AL2, i metadati di questi parametri sono stati scoperti dalla chiamata `DescribeCluster` API di Amazon EKS. Nel frattempo AL2023, questo comportamento è cambiato poiché la chiamata API aggiuntiva rischia di rallentare durante l'up-up di nodi su larga scala. Questa modifica non ha effetto su di te se utilizzi gruppi di nodi gestiti senza un modello di avvio o se utilizzi Karpenter. Per ulteriori informazioni su `certificateAuthority` e sul servizio `cidr`, consulta [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) nel *Riferimento di API Amazon EKS*.
Ecco un esempio completo di dati AL2023 utente che combina uno script di shell per personalizzare il nodo (come l'installazione di pacchetti o la prememorizzazione nella cache delle immagini dei contenitori) con la configurazione richiesta. `nodeadm` Questo esempio mostra personalizzazioni comuni tra cui: \$1 Installazione di pacchetti di sistema aggiuntivi \$1 Pre-memorizzazione nella cache delle immagini dei container per migliorare il tempo di avvio del pod \$1 Impostazione della configurazione del proxy HTTP \$1 Configurazione dei flag `kubelet` per l’etichettatura dei nodi
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Dati utente Bottlerocket**
I dati utente delle strutture Bottlerocket nel formato TOML. È possibile fornire i dati utente da unire con i dati utente forniti da Amazon EKS. Ad esempio, è possibile fornire ulteriori impostazioni `kubelet`.
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Per ulteriori informazioni sulle impostazioni supportate, consultare la [documentazione Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). È possibile configurare etichette di nodi e [taint](node-taints-managed-node-groups.md) nei dati utente. Consigliamo, tuttavia, di configurarle all'interno del gruppo di nodi. In questo caso, Amazon EKS applica queste configurazioni.
Quando i dati utente sono uniti, la formattazione non è mantenuta, ma il contenuto rimane invariato. La configurazione fornita nei dati utente sostituisce tutte le impostazioni configurate da Amazon EKS. Quindi, se imposti `settings.kubernetes.max-pods` o `settings.kubernetes.cluster-dns-ip`, questi valori nei dati utente sono applicati ai nodi.
Amazon EKS non supporta tutti i TOML validi. Di seguito è riportato un elenco di formati noti non supportati:
+ Quote all'interno delle chiavi stimate: `'quoted "value"' = "value"`
+ Quote evase nei valori: `str = "I’m a string. \"You can quote me\""`
+ Galleggianti e numeri interi misti: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ Tipi misti nelle matrici: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ Intestazioni tra parentesi con chiavi stimate: `[foo."bar.baz"]`
**Dati utente Windows**
I dati utente di Windows utilizzano i comandi. PowerShell Quando crei un gruppo di nodi gestiti, i dati utente personalizzati si combinano con i dati utente gestiti da Amazon EKS. PowerShell I tuoi comandi vengono prima, seguiti dai comandi gestiti per i dati utente, il tutto all'interno di un unico `` tag.
Durante la creazione di gruppi di nodi Windows, Amazon EKS aggiorna il file `aws-auth` `ConfigMap` per consentire ai nodi basati su Linux di unirsi al cluster. Il servizio non configura automaticamente le autorizzazioni per Windows AMIs. Se utilizzi i nodi Windows, dovrai gestire l’accesso tramite l’API della voce di accesso o aggiornando direttamente `aws-auth` `ConfigMap`. Per ulteriori informazioni, consulta [Implementazione dei nodi Windows su cluster EKS](windows-support.md).
Quando non è specificato alcun ID AMI nel modello di avvio, nei dati utente non utilizzare lo script bootstrap di Amazon EKS per Windows per configurare Amazon EKS.
Di seguito sono riportati dati utente di esempio.
```
Write-Host "Running custom user data script"
```
## Specifica di un'AMI
Se si dispone di uno dei seguenti requisiti, specificare un ID AMI nel campo `ImageId` del modello di avvio. Selezionare il requisito di cui si dispone per ulteriori informazioni.
### Fornisci i dati utente per passare argomenti al `bootstrap.sh` file incluso in un' Linux/Bottlerocket AMI ottimizzata per Amazon EKS
Il termine "bootstrapping" indica l'aggiunta di comandi che possono essere eseguiti all'avvio di un'istanza. Ad esempio, il bootstrap consente di utilizzare argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi. È possibile passare gli argomenti allo script `bootstrap.sh` utilizzando `eksctl` senza specificare un modello di avvio. Oppure è possibile farlo specificando le informazioni nella sezione dati utente di un modello di avvio.
**eksctl senza specificare un modello di avvio**
Crea un file denominato *my-nodegroup.yaml* con i seguenti contenuti. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` sono facoltativi, ma grazie alla loro definizione lo script `bootstrap.sh` può evitare di effettuare una chiamata a `describeCluster`. Ciò è utile nelle configurazioni di cluster privati o nei cluster in cui si effettuano dimensionamenti frequenti dei nodi. Per ulteriori informazioni sullo `bootstrap.sh` script, consulta il file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) su GitHub.
+ L'unico argomento richiesto è il nome del cluster (*my-cluster*).
+ Per recuperare l’ID di un’AMI ottimizzata per `ami-1234567890abcdef0 `, consulta le sezioni seguenti:
+ [Recupera le AMI Amazon Linux consigliate IDs](retrieve-ami-id.md)
+ [Recupera l'AMI Bottlerocket consigliata IDs](retrieve-ami-id-bottlerocket.md)
+ [Recupera l'AMI Microsoft Windows consigliata IDs](retrieve-windows-ami-id.md)
+ Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Questo esempio fornisce un argomento `kubelet` per impostare un valore `max-pods` personalizzato utilizzando lo script `bootstrap.sh` incluso nell'AMI ottimizzata per Amazon EKS. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura. Per assistenza nella scelta di *my-max-pods-value*, consulta . Per ulteriori informazioni su come `maxPods` viene determinato quando si utilizzano i gruppi di nodi gestiti, vedere[Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence).
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
Per ogni opzione disponibile per il file `eksctl` `config`, consulta [Schema del file config](https://eksctl.io/usage/schema/) nella documentazione su `eksctl`. L'utility `eksctl` crea autonomamente un modello di avvio e popola i dati utente con i dati forniti nel file `config`.
Crea un gruppo di nodi con il comando seguente.
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**Dati utente in un modello di avvio**
Specifica le seguenti informazioni nella sezione dati utente del modello di avvio. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` sono facoltativi, ma grazie alla loro definizione lo script `bootstrap.sh` può evitare di effettuare una chiamata a `describeCluster`. Ciò è utile nelle configurazioni di cluster privati o nei cluster in cui si effettuano dimensionamenti frequenti dei nodi. Per ulteriori informazioni sullo `bootstrap.sh` script, vedere il file [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) su GitHub.
+ L'unico argomento richiesto è il nome del cluster (*my-cluster*).
+ Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Questo esempio fornisce un argomento `kubelet` per impostare un valore `max-pods` personalizzato utilizzando lo script `bootstrap.sh` incluso nell'AMI ottimizzata per Amazon EKS. Per assistenza nella scelta di *my-max-pods-value*, consulta . Per ulteriori informazioni su come `maxPods` viene determinato quando si utilizzano i gruppi di nodi gestiti, vedere[Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### Fornire i dati dell’utente per passare gli argomenti al file `Start-EKSBootstrap.ps1` incluso nell’AMI Windows ottimizzata per Amazon EKS
Il termine "bootstrapping" indica l'aggiunta di comandi che possono essere eseguiti all'avvio di un'istanza. È possibile passare gli argomenti allo script `Start-EKSBootstrap.ps1` utilizzando `eksctl` senza specificare un modello di avvio. Oppure è possibile farlo specificando le informazioni nella sezione dati utente di un modello di avvio.
Per specificare un ID AMI Windows personalizzato, fai le seguenti considerazioni:
+ Devi utilizzare un modello di avvio e fornire i comandi bootstrap richiesti nella sezione dei dati utente. Per recuperare l'ID Windows desiderato, puoi utilizzare la tabella in [Crea nodi con Windows AMIs ottimizzato](eks-optimized-windows-ami.md).
+ Esistono vari limiti e condizioni. Ad esempio, è necessario aggiungere `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Per ulteriori informazioni, consulta [Limiti e condizioni quando si specifica un ID AMI](#mng-ami-id-conditions).
Specifica le seguenti informazioni nella sezione dati utente del modello di avvio. Sostituisci ogni *example value* con i valori in tuo possesso. Gli argomenti `-APIServerEndpoint`, `-Base64ClusterCA` e `-DNSClusterIP` sono facoltativi, ma grazie alla loro definizione lo script `Start-EKSBootstrap.ps1` può evitare di effettuare una chiamata a `describeCluster`.
+ L'unico argomento richiesto è il nome del cluster (*my-cluster*).
+ Per recuperare il valore *certificate-authority* per il cluster, esegui il comando seguente.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Per recuperare il valore *api-server-endpoint* per il cluster, esegui il comando seguente.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ Il valore per `--dns-cluster-ip` è il tuo servizio CIDR con `.10` alla fine. Per recuperare il valore *service-cidr* per il cluster, esegui il comando seguente. Ad esempio, se il valore restituito è `ipv4 10.100.0.0/16`, il tuo valore è *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Per ulteriori argomenti, consulta.[Parametri di configurazione dello script di bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**Nota**
Se utilizzi il servizio personalizzato CIDR, devi specificarlo utilizzando il parametro `-ServiceCIDR`. In caso contrario, la risoluzione DNS per i pod nel cluster avrà esito negativo.
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### Eseguire un'AMI personalizzata a causa di specifici requisiti di sicurezza, conformità o policy interne
Per ulteriori informazioni, consulta [Amazon Machine Image (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) nella *Guida per l’utente di Amazon EC2*. La specifica di compilazione AMI Amazon EKS contiene risorse e script di configurazione per la creazione di un’AMI Amazon EKS personalizzata basata su Amazon Linux. Per ulteriori informazioni, consulta [Specifica della build AMI di Amazon EKS](https://github.com/awslabs/amazon-eks-ami/) su GitHub. Per creare AMIs installazioni personalizzate con altri sistemi operativi, consulta [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) on GitHub.
Non è possibile utilizzare riferimenti dinamici ai parametri per AMI IDs nei modelli di avvio utilizzati con gruppi di nodi gestiti.
**Importante**
Quando si specifica un'AMI, Amazon EKS non convalida la versione di Kubernetes incorporata nell'AMI rispetto alla versione del piano di controllo del cluster. Sei responsabile di garantire che la versione Kubernetes della tua AMI personalizzata sia conforme alla politica di modifica della versione di [Kubernetes](https://kubernetes.io/releases/version-skew-policy):
La `kubelet` versione sui tuoi nodi non deve essere più recente della versione del cluster
La `kubelet` versione sui tuoi nodi deve essere uguale o superiore a 3 versioni secondarie rispetto alla versione del cluster (per la versione Kubernetes `1.28` o successiva) o fino a 2 versioni minori rispetto alla versione del cluster (per la versione Kubernetes o precedente) `1.27`
La creazione di gruppi di nodi gestiti con violazioni dell'asimmetria delle versioni può comportare:
I nodi non riescono a unirsi al cluster
Comportamento indefinito o incompatibilità delle API
Instabilità del cluster o errori del carico di lavoro
Quando si specifica una AMI, Amazon EKS non unisce alcun dato utente. È l’utente, piuttosto, ad essere responsabile della fornitura dei comandi `bootstrap` richiesti per unire i nodi al cluster. Se i nodi non riescono a unirsi al cluster, le operazioni `CreateNodegroup` e `UpdateNodegroupVersion` di Amazon EKS non vengono eseguite con successo.
## Limiti e condizioni quando si specifica un ID AMI
Di seguito sono riportati i limiti e le condizioni per la specifica di un ID AMI con gruppi di nodi gestiti:
+ È necessario creare un nuovo gruppo di nodi per passare dalla specifica o meno di un ID AMI in un modello di avvio.
+ Non riceverai una notifica nella console quando è disponibile una versione AMI più recente. Per aggiornare il gruppo di nodi a una versione AMI più recente, devi creare una nuova versione del modello di avvio con un ID AMI aggiornato. Quindi, è necessario aggiornare il gruppo di nodi con la nuova versione del modello di avvio.
+ I seguenti campi non possono essere impostati nell’API se si specifica un ID AMI:
+ `amiType`
+ `releaseVersion`
+ `version`
+ Se si specifica un ID AMI, qualsiasi set di `taints` nell'API viene applicato in modo asincrono. Per applicare i taint prima che un nodo si unisca al cluster, è necessario passare i taint a `kubelet` utilizzando il flag della riga di comando `--register-with-taints`. Per ulteriori informazioni, consulta [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) nella documentazione Kubernetes.
+ Quando specifichi un ID AMI personalizzato per i gruppi di nodi gestiti da Windows, aggiungilo `eks:kube-proxy-windows` alla mappa di configurazione di AWS IAM Authenticator. Questa API è necessaria per il funzionamento di DNS.
1. Apri la mappa di configurazione di AWS IAM Authenticator per modificarla.
```
kubectl edit -n kube-system cm aws-auth
```
1. Aggiungi questa voce all’elenco `groups` sotto ogni `rolearn` associato ai nodi Windows. [La tua mappa di configurazione dovrebbe essere simile a aws-auth-cm-windows .yaml.](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)
```
- eks:kube-proxy-windows
```
1. Salva il file ed esci dall’editor di testo.
+ Per ogni AMI che utilizza un modello di avvio personalizzato, l’impostazione predefinita `HttpPutResponseHopLimit` per i gruppi di nodi gestiti è impostata su `2`.
# Eliminare un gruppo di nodi gestito dal cluster
In questo argomento viene descritto come eliminare un gruppo di nodi gestiti Amazon EKS. Quando elimini un gruppo di nodi gestiti, Amazon EKS imposterà su zero la dimensione minima, massima e desiderata del tuo gruppo Auto Scaling. Questo fa sì che il gruppo di nodi venga dimensionato.
Prima che ogni istanza venga terminata, Amazon EKS invia un segnale per drenare quel nodo. Durante il processo di drenaggio, Kubernetes esegue le seguenti operazioni per ogni pod sul nodo: esegue tutti gli hook del `preStop` ciclo di vita configurati, invia `SIGTERM` segnali ai contenitori, quindi attende il corretto spegnimento. `terminationGracePeriodSeconds` Se il nodo non è stato svuotato dopo 5 minuti, Amazon EKS consente ad Auto Scaling di continuare la chiusura forzata dell'istanza. Dopo che tutte le istanze sono state terminate, il gruppo Auto Scaling viene eliminato.
**Importante**
Se si elimina un gruppo di nodi gestiti che utilizza un ruolo IAM del nodo non impiegato da nessun altro gruppo di nodi gestiti nel cluster, il ruolo viene rimosso dalla `ConfigMap` `aws-auth`. Se i gruppi di nodi autogestiti nel cluster utilizzano lo stesso ruolo IAM del nodo, i nodi autogestiti passeranno allo stato `NotReady`. Inoltre, anche l’operazione del cluster viene interrotta. Per aggiungere una mappatura per il ruolo da utilizzare solo per i gruppi di nodi autogestiti, consultare la pagina [Creare voci di accesso](creating-access-entries.md), se la versione della piattaforma del cluster corrisponde almeno alla versione minima elencata nella sezione dei prerequisiti della pagina [Grant IAM users access to Kubernetes with EKS access entries](access-entries.md). Se la versione della piattaforma è precedente alla versione minima richiesta per le voci di accesso, è possibile aggiungere nuovamente la voce alla `ConfigMap` `aws-auth`. Per ulteriori informazioni, digita `eksctl create iamidentitymapping --help` nel terminale.
È possibile creare un gruppo di nodi gestiti con i seguenti strumenti:
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [Console di gestione AWS](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**Eliminare un gruppo di nodi gestiti con `eksctl`**
Inserire il seguente comando. Sostituisci ogni `` con i valori in tuo possesso.
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
Per ulteriori opzioni, consulta [Eliminazione e svuotamento dei gruppi di nodi](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) nella documentazione di `eksctl`.
## Console di gestione AWS
**Eliminare un gruppo di nodi gestiti con Console di gestione AWS **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nella pagina **Cluster**, scegli il cluster che contiene il gruppo di nodi da eliminare.
1. Nella pagina del cluster selezionata, scegli la scheda **Calcolo**.
1. Nella sezione **Gruppi di nodi**, scegliere il gruppo di nodi da eliminare. Scegli **Elimina**.
1. Nella finestra di dialogo di conferma di **Eliminazione del gruppo di nodi**, inserisci il nome del gruppo di nodi. Scegli **Elimina**.
## AWS CLI
**Eliminare un gruppo di nodi gestito con AWS CLI**
1. Inserire il seguente comando. Sostituisci ogni `` con i valori in tuo possesso.
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. Se `cli_pager=` è impostato nella configurazione CLI, usa i tasti freccia sulla tastiera per scorrere l'output della risposta. Premere il tasto `q` al termine.
Per ulteriori opzioni, consultate il ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` comando nella * AWS CLI Command* Reference.
# 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).
# Semplifica la gestione dell’elaborazione con AWS Fargate
In questo argomento viene illustrato l’utilizzo di Amazon EKS per eseguire i pod Kubernetes su AWS Fargate. Fargate è una tecnologia che fornisce capacità di calcolo on demand e di dimensioni adeguate per i [container](https://aws.amazon.com/what-are-containers). Con Fargate, non devi effettuare personalmente il provisioning, la configurazione o il dimensionamento dei gruppi di macchine virtuali per eseguire i container. Non devi inoltre scegliere i tipi di server, decidere quando dimensionare i gruppi di nodi oppure ottimizzare l’impacchettamento dei cluster.
Puoi controllare quali pod sono avviati su Fargate e come vengono eseguiti con [profili Fargate](fargate-profile.md). I profili Fargate sono definiti come parte del cluster Amazon EKS. Amazon EKS integra Kubernetes con Fargate tramite l’utilizzo di controller creati da AWS utilizzando il modello upstream ed estensibile fornito da Kubernetes. Questi controller vengono eseguiti come parte del piano di controllo di Kubernetes gestito da Amazon EKS e sono responsabili della pianificazione dei pod Kubernetes nativo su Fargate. I controller Fargate includono un nuovo pianificazione che viene eseguito insieme al pianificatore di default di Kubernetes, oltre a diversi controller di ammissione mutanti e convalidanti. Quando avvii un pod che soddisfa i criteri per l’esecuzione su Fargate, i controller Fargate in esecuzione nel cluster riconoscono, aggiornano e pianificano il pod su Fargate.
Questo argomento descrive i diversi componenti di pod in esecuzione su Fargate, e illustra considerazioni speciali per l’utilizzo di Fargate con Amazon EKS.
## Considerazioni su AWS Fargate
Di seguito sono elencati alcuni punti da considerare sull’uso di Fargate in Amazon EKS.
+ Ogni pod in esecuzione su Fargate ha un proprio limite di calcolo. Non condividono il kernel sottostante, le risorse CPU, le risorse di memoria o l’interfaccia di rete elastica con un altro pod.
+ I Network Load Balancer e gli Application Load Balancer (ALB) possono essere utilizzati solo con Fargate con destinazioni IP. Per ulteriori informazioni, consulta [Creazione di un Network Load Balancer](network-load-balancing.md#network-load-balancer) e [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md).
+ I servizi esposti Fargate vengono eseguiti solo in modalità IP di tipo destinazione e non in modalità IP del nodo. Il modo consigliato per verificare la connettività da un servizio in esecuzione su un nodo gestito e da un servizio in esecuzione su Fargate è quello di connettersi tramite il nome del servizio.
+ Nel momento in cui sono programmati per l’esecuzione su Fargate, i pod devono corrispondere a un profilo Fargate. I pod che non corrispondono a un profilo Fargate potrebbero rimanere bloccati nello stato `Pending`. Se esiste un profilo Fargate corrispondente, puoi eliminare i pod in sospeso creati per riprogrammarli su Fargate.
+ I Daemonset non sono supportati su Fargate. Se l’applicazione richiede un daemon, riconfigura quel daemon per essere eseguito nei pod come container sidecar.
+ I container privilegiati non sono supportati su Fargate.
+ I pod in esecuzione su Fargate non possono specificare `HostPort` o `HostNetwork` nel manifesto del pod.
+ Per i pod Fargate, il valore di default per il limite soft `nofile` e `nproc` è 1.024, mentre per il limite hard è 65.535.
+ Le GPU non sono attualmente disponibili su Fargate.
+ I pod in esecuzione su Fargate sono supportati solo su sottoreti private (con un accesso NAT gateway ai servizi AWS, ma senza routing diretto a un Gateway Internet), pertanto il VPC del cluster deve disporre di sottoreti private disponibili. Per i cluster senza accesso Internet in uscita, consulta [Implementazione di cluster privati con accesso limitato a Internet](private-clusters.md).
+ Puoi utilizzare [Adjust pod resources with Vertical Pod Autoscaler](vertical-pod-autoscaler.md) per impostare la dimensione corretta iniziale della CPU e la memoria per i Pod Fargate, quindi utilizza [Scale pod deployments with Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) per scalare quei Pod. Se desideri che il Vertical Pod Autoscaler ridistribuisca automaticamente i pod su Fargate con combinazioni di CPU e memoria più grandi, imposta la modalità per il Vertical Pod Autoscaler su `Auto` o `Recreate` r per garantire la corretta funzionalità. Per ulteriori informazioni, consulta la documentazione [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) su GitHub.
+ La risoluzione DNS e i nomi host DNS devono essere abilitati per il VPC. Per ulteriori informazioni, consulta [Visualizzazione e aggiornamento del supporto DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
+ Amazon EKS Fargate aggiunge una difesa approfondita per le applicazioni Kubernetes isolando ogni pod all’interno di una macchina virtuale (VM). Questo limite VM impedisce l’accesso alle risorse basate su host utilizzate da altri pod in caso di evasione da un container, un metodo comune per attaccare le applicazioni containerizzate e ottenere l’accesso a risorse esterne al container.
L’utilizzo di Amazon EKS non modifica le tue responsabilità ai sensi del [modello di responsabilità condivisa](security.md). È necessario considerare attentamente la configurazione dei controlli di sicurezza e gestione del cluster. Il modo più sicuro per isolare un’applicazione è sempre quello di eseguirla in un cluster separato.
+ I profili Fargate supportano la specificazione di sottoreti da blocchi CIDR secondari del VPC. È possibile specificare un blocco CIDR secondario. Ciò è necessario perché in una sottorete è disponibile un numero limitato di indirizzi IP. Di conseguenza, nel cluster puoi creare un numero limitato di pod. L’uso di sottoreti diverse per i pod ti consente di aumentare il numero di indirizzi IP disponibili. Per ulteriori informazioni, consulta [Aggiunta di blocchi CIDR IPv4 a un VPC.](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize)
+ Il servizio di metadati di istanza (IMDS) Amazon EC2 non è disponibile per i pod distribuiti ai nodi Fargate. Se disponi di pod distribuiti in Fargate che necessitano di credenziali IAM, assegnali ai pod utilizzando i [ruoli IAM per gli account di servizio](iam-roles-for-service-accounts.md). Se i pod hanno bisogno di accedere ad altre informazioni disponibili tramite IMDS, devi eseguire la codifica fissa di queste informazioni nelle specifiche del pod. Ciò include la Regione AWS o la zona di disponibilità in cui viene implementato un pod.
+ Non puoi implementare i pod Fargate in AWS Outposts, AWS Wavelength o AWS nelle zone locali.
+ Periodicamente, Amazon EKS deve applicare patch ai Pod Fargate per garantire che siano sicuri. Gli aggiornamenti vengono effettuati in modo da avere il minor impatto possibile. Tuttavia, se i pod non vengono espulsi con successo, a volte è necessario eliminarli. Di seguito sono riportate le azioni che è possibile intraprendere per ridurre al minimo le interruzioni. Per ulteriori informazioni, consulta [Imposta azioni per gli eventi relativi all’applicazione di patch del sistema operativo AWS Fargate](fargate-pod-patching.md).
+ Il [plug-in CNI di Amazon VPC per Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) è installato sui nodi Fargate. Non puoi utilizzare [Alternate CNI plugins for Amazon EKS clusters](alternate-cni-plugins.md) con i nodi Fargate.
+ Un pod in esecuzione su Fargate monta automaticamente un file system Amazon EFS senza bisogno della procedura di installazione manuale del driver. Non puoi utilizzare il provisioning dinamico dei volumi persistenti con nodi Fargate, ma puoi usare quello statico.
+ Amazon EKS non supporta Fargate Spot.
+ Non puoi montare volumi Amazon EBS sui pod Fargate.
+ Puoi eseguire il controller Amazon EBS CSI sui nodi Fargate, ma sul nodo Amazon EBS CSI DaemonSet può essere eseguito solo su istanze Amazon EC2.
+ Dopo che un [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) è stato contrassegnato `Completed` o `Failed`, i pod creati normalmente continuano a esistere. Questo comportamento ti consente di visualizzare i tuoi log e risultati, ma con Fargate dovrai sostenere dei costi se non ripulisci il processo in seguito.
Per eliminare automaticamente i pod correlati dopo il completamento o un errore di un processo, puoi specificare un periodo di tempo utilizzando il controller time-to-live (TTL). L’esempio seguente mostra la specifica di `.spec.ttlSecondsAfterFinished` nel manifesto del processo.
```
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "sleep 10"]
restartPolicy: Never
ttlSecondsAfterFinished: 60 # <-- TTL controller
```
## Tabella di confronto Fargate
| Criteri | AWS Fargate |
| --- | --- |
| Si può implementare in [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) | No |
| Si può implementare in una [Zona locale AWS](local-zones.md) | No |
| Può eseguire container che richiedono Windows | No |
| Può eseguire container che richiedono Linux | Sì |
| Può eseguire carichi di lavoro che richiedono il chip Inferentia | No |
| Può eseguire carichi di lavoro che richiedono una GPU | No |
| Può eseguire carichi di lavoro che richiedono processori Arm | No |
| Può eseguire AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | No |
| I pod condividono un ambiente di runtime del kernel con altri pod | No: ogni pod ha un kernel dedicato |
| I pod condividono risorse di CPU, memoria, archiviazione e rete con altri pod. | No: ogni pod dispone di risorse dedicate e può essere ridimensionato in modo indipendente per massimizzare l’utilizzo delle risorse. |
| I pod possono utilizzare più hardware e memoria rispetto alle specifiche dei pod | No: il pod può essere comunque reimplementato utilizzando una vCPU e una configurazione di memoria più grandi. |
| È necessario implementare e gestire le istanze Amazon EC2 | No |
| È necessario proteggere, mantenere e applicare patch al sistema operativo delle istanze Amazon EC2 | No |
| Può fornire argomenti di bootstrap all’implementazione di un nodo, come argomenti [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) aggiuntivi. | No |
| Può assegnare indirizzi IP ai pod da un intervallo CIDR diverso rispetto all’indirizzo IP assegnato al nodo. | No |
| Puoi eseguire SSH nel nodo | No: non esiste un sistema operativo host del nodo su cui eseguire il SSH. |
| Puoi implementare un’AMI personalizzata nei nodi | No |
| Può implementare una CNI personalizzata nei nodi | No |
| É necessario aggiornare l’AMI del nodo per conto proprio | No |
| È necessario aggiornare la versione del nodo Kubernetes per conto proprio | No: non sei tu a gestire i nodi. |
| Può utilizzare lo spazio di archiviazione Amazon EBS con i pod | No |
| Può utilizzare lo spazio di archiviazione di Amazon EFS con i pod | [Sì](efs-csi.md) |
| Può utilizzare lo spazio di archiviazione Amazon FSx per Lustre con i pod | No |
| Può utilizzare Network Load Balancer per i servizi | Sì, quando si utilizza [Create a network load balancer](network-load-balancing.md#network-load-balancer) |
| I pod possono essere eseguiti in una sottorete pubblica | No |
| Può assegnare diversi gruppi di sicurezza VPC a singoli pod | Sì |
| Può eseguire Kubernetes DaemonSets | No |
| Supporto `HostPort` e `HostNetwork` nel manifesto pod | No |
| Disponibilità nelle regioni AWS | [Alcune regioni supportate da Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) |
| Può eseguire container su host dedicati Amazon EC2 | No |
| Prezzi | Costo di una singola configurazione di memoria Fargate e CPU. Ogni pod ha il rispettivo costo. Per ulteriori informazioni, consulta [Prezzi di Fargate AWS](https://aws.amazon.com/fargate/pricing/). |
# Inizia a usare AWS Fargate per il tuo cluster
Questo argomento descrive come iniziare a eseguire Pods su AWS Fargate con il tuo cluster Amazon EKS.
Se limiti l'accesso all'endpoint pubblico del cluster utilizzando blocchi CIDR, consigliamo di abilitare anche l'accesso agli endpoint privati. In questo modo i pod Fargate 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).
**Prerequisito**
Un cluster esistente. Se si dispone già di un cluster Amazon EKS, consultare la pagina [Nozioni di base su Amazon EKS](getting-started.md).
## Fase 1: assicurarsi che i nodi esistenti possano comunicare con i pod Fargate
Se si utilizza un nuovo cluster senza nodi o un cluster con solo gruppi di nodi gestiti (consultare [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md)), è possibile passare a [Fase 2: creare un ruolo di esecuzione del pod Fargate](#fargate-sg-pod-execution-role).
Supponiamo di lavorare con un cluster esistente che dispone già di nodi associati. Assicurarsi che i pod su questi nodi possano comunicare liberamente con i pod in esecuzione su Fargate. I pod in esecuzione su Fargate vengono configurati automaticamente per utilizzare il gruppo di sicurezza del cluster per il cluster a cui sono associati. È necessario assicurarsi che eventuali i nodi esistenti nel cluster possano inviare e ricevere traffico da e verso il gruppo di sicurezza del cluster. I gruppi di nodi gestiti vengono configurati automaticamente per utilizzare anche il gruppo di sicurezza del cluster, quindi non è necessario modificarli o verificare questa compatibilità (consultare [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md)).
Per i gruppi di nodi esistenti che sono stati creati con `eksctl` o i AWS CloudFormation modelli gestiti di Amazon EKS, puoi aggiungere manualmente il gruppo di sicurezza del cluster ai nodi. In alternativa, è possibile modificare il modello di avvio del gruppo Auto Scaling per il gruppo di nodi per collegare il gruppo di sicurezza cluster alle istanze. Per ulteriori informazioni, consultare [Changing an instance’s security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) nella *Guida per l’utente di Amazon VPC*.
Puoi verificare la presenza di un gruppo di sicurezza per il Console di gestione AWS tuo cluster nella sezione **Rete** relativa al cluster. In alternativa, è possibile eseguire questa operazione utilizzando il seguente AWS comando CLI. Se utilizzi questo comando, sostituisci `` con il nome del cluster.
```
aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```
## Fase 2: creare un ruolo di esecuzione del pod Fargate
Quando il cluster crea Pod su AWS Fargate, i componenti che girano sull'infrastruttura Fargate devono effettuare chiamate AWS APIs per conto dell'utente. Il ruolo di esecuzione del pod Amazon EKS fornisce le autorizzazioni IAM per eseguire questa operazione. Per creare un ruolo di esecuzione di AWS Fargate Pod, vedere. [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md)
**Nota**
Se il cluster è stato creato con `eksctl` utilizzando l’opzione `--fargate`, dispone già di un ruolo di esecuzione del pod disponibile nella console IAM con il modello `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL`. Allo stesso modo, se si utilizza `eksctl` per creare i profili Fargate, `eksctl` crea il ruolo di esecuzione del pod se non ne esiste già uno.
## Fase 3: creare un profilo Fargate per il cluster
Prima di poter pianificare i pod in esecuzione su Fargate nel cluster, sarà necessario definire un profilo Fargate che specifichi i pod che utilizzano Fargate al momento dell’avvio. Per ulteriori informazioni, consulta [Definisci quali pod utilizzano AWS Fargate durante l’avvio](fargate-profile.md).
**Nota**
Se il cluster è stato creato con `eksctl` utilizzando l’opzione `--fargate`, allora un profilo Fargate è già stato creato per il cluster con selettori per tutti i pod nei namespace `kube-system` e `default`. Utilizza la procedura seguente per creare profili Fargate per gli altri namespace con cui desideri utilizzare Fargate.
È possibile creare un profilo Fargate utilizzando uno di questi due strumenti:
+ [`eksctl`](#eksctl_fargate_profile_create)
+ [Console di gestione AWS](#console_fargate_profile_create)
### `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`.
**Per creare un profilo Fargate con `eksctl`**
Crea il tuo profilo Fargate con il seguente comando `eksctl`, sostituendo ogni `` con i valori in tuo possesso. È necessario specificare un namespace. Tuttavia, l’opzione `--labels` non è obbligatoria.
```
eksctl create fargateprofile \
--cluster \
--name \
--namespace \
--labels
```
È possibile utilizzare determinati caratteri jolly per `` e etichette ``. Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](fargate-profile.md#fargate-profile-wildcards).
### Console di gestione AWS
**Creazione di un profilo Fargate con Console di gestione AWS **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il cluster per cui creare un profilo Fargate.
1. Scegli la scheda **Calcolo**.
1. Nella sezione **Profili Fargate**, scegli **Aggiungi profilo Fargate**.
1. Nella pagina **Configura il profilo Fargate**, procedi come segue:
1. In **Nome**, inserisci un nome per il profilo Fargate. Il nome deve essere univoco.
1. Come **Ruolo di esecuzione pod**, scegliere il ruolo di esecuzione del pod da utilizzare con il profilo Fargate. Vengono visualizzati solo i ruoli IAM con il principale del servizio `eks-fargate-pods.amazonaws.com`. Se non vedi alcun ruolo nell’elenco, è necessario crearne uno. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md).
1. Modifica le **sottoreti** selezionate in base alle esigenze.
**Nota**
Solo le sottoreti private sono supportate per i pod in esecuzione su Fargate.
1. In **Tag**, puoi facoltativamente aggiungere tag al tuo profilo Fargate. Questi tag non si propagano ad altre risorse associate al profilo come i pod.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Configura selezione pod**, procedi come segue:
1. In **Namespace**, inserisci un namespace che corrisponda ai pod.
+ È possibile utilizzare namespace specifici da abbinare, ad esempio `kube-system` o `default`.
+ È possibile utilizzare determinati caratteri jolly (ad esempio, `prod-*`) per abbinare più namespace (ad esempio, `prod-deployment` e `prod-test`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](fargate-profile.md#fargate-profile-wildcards).
1. (Facoltativo) Aggiungere etichette Kubernetes al selettore. In particolare, aggiungerle al selettore con cui i pod nel namespace specificato devono corrispondere.
+ È possibile aggiungere l’etichetta `infrastructure: fargate` al selettore in modo che solo i pod nel namespace specificato che hanno anche l’etichetta Kubernetes `infrastructure: fargate` corrispondano al selettore.
+ È possibile utilizzare determinati caratteri jolly (ad esempio, `key?: value?`) per abbinare più namespace (ad esempio, `keya: valuea` e `keyb: valueb`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](fargate-profile.md#fargate-profile-wildcards).
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e crea**, controlla le informazioni relative al profilo Fargate e scegli **Crea**.
## Fase 4: aggiornare CoreDNS
Per impostazione predefinita, CoredNS è configurato per l'esecuzione sull' EC2 infrastruttura Amazon su cluster Amazon EKS. Se si desidera *solo* eseguire i pod su Fargate nel cluster, seguire la procedura riportata di seguito.
**Nota**
Se è stato creato il cluster `eksctl` utilizzando l'opzione `--fargate` è possibile passare a [Fasi successive](#fargate-gs-next-steps).
1. Creare un profilo Fargate per CoreDNS con il seguente comando. Sostituiscilo `` con il nome del cluster, `<111122223333>` con l'ID dell'account, `` con il nome del ruolo di esecuzione del Pod e `<000000000000000a>` `<000000000000000c>` con le sottoreti IDs private. `<000000000000000b>` Se non si dispone di un ruolo di esecuzione del pod, è necessario prima crearne uno (consultare [Fase 2: creare un ruolo di esecuzione del pod Fargate](#fargate-sg-pod-execution-role)).
**Importante**
L’ARN del ruolo non può includere un [percorso](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) diverso da `/`. Ad esempio, se il nome del ruolo è `development/apps/AmazonEKSFargatePodExecutionRole`, è necessario modificarlo in `AmazonEKSFargatePodExecutionRole` quando si specifica l'ARN per tale ruolo. Il formato dell'ARN del ruolo deve essere ` arn:aws: iam::<111122223333>:role/`.
```
aws eks create-fargate-profile \
--fargate-profile-name coredns \
--cluster-name \
--pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \
--selectors namespace=kube-system,labels={k8s-app=kube-dns} \
--subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c>
```
1. Attivare un rollout dell’implementazione `coredns`.
```
kubectl rollout restart -n kube-system deployment coredns
```
## Fasi successive
+ Puoi avviare la migrazione delle applicazioni esistenti per l'esecuzione su Fargate con il seguente flusso di lavoro.
1. [Creazione di un profilo Fargate](fargate-profile.md#create-fargate-profile) che corrisponda al namespace Kubernetes e alle etichette Kubernetes dell’applicazione.
1. Eliminare e creare nuovamente tutti i pod esistenti in modo che siano programmati su Fargate. Modificare `` e `` per aggiornare i pod specifici.
```
kubectl rollout restart -n deployment
```
+ Implementare [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md) per permettere l’esecuzione di oggetti Ingress per i pod in esecuzione su Fargate.
+ È possibile utilizzare [Regolazione delle risorse del pod con Vertical Pod Autoscaler](vertical-pod-autoscaler.md) per impostare la dimensione corretta iniziale della CPU e la memoria per i pod Fargate, quindi utilizzare il comando [Scalare le implementazioni dei pod con Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) per scalare tali pod. Se si desidera che il Vertical Pod Autoscaler implementi di nuovo automaticamente i pod su Fargate con combinazioni di CPU e memoria più grandi, impostare la modalità del Vertical Pod Autoscaler su `Auto` o `Recreate`. Ciò garantisce una corretta funzionalità. Per ulteriori informazioni, consulta la documentazione di [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) su GitHub.
+ Ora puoi impostare il collector [AWS Distro per OpenTelemetry](https://aws.amazon.com/otel) (ADOT) per il monitoraggio delle applicazioni seguendo [queste istruzioni](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html).
# Definisci quali pod utilizzano AWS Fargate durante l’avvio
Prima di programmare i pod su Fargate nel cluster, devi definire almeno un profilo Fargate che specifichi i pod utilizzati da Fargate al momento dell’avvio.
Come amministratore, puoi utilizzare il profilo Fargate per dichiarare quali pod vengono eseguiti su Fargate. Puoi farlo attraverso i selettori del profilo. Puoi aggiungere fino a cinque selettori a ogni profilo. Ogni selettore deve contenere uno spazio dei nomi. Il selettore può includere anche etichette. Il campo etichetta è costituito da più coppie chiave-valore facoltative. I pod che corrispondono ai selettori sono programmati su Fargate. I pod vengono abbinati utilizzando uno spazio dei nomi e le etichette specificate nel selettore. Se un selettore di namespace è definito senza etichette, Amazon EKS tenterà di pianificare tutti i pod che vengono eseguiti in tale namespace su Fargate utilizzando il profilo. Se un pod da programmare corrisponde a uno dei selettori nel profilo Fargate, allora quel pod viene programmato su Fargate.
Se un pod corrisponde a più profili Fargate, puoi specificare quale profilo viene utilizzato dal pod aggiungendo la seguente etichetta Kubernetes alla specifica del pod: `eks.amazonaws.com/fargate-profile: my-fargate-profile`. Il pod deve corrispondere a un selettore in quel profilo per essere pianificato su Fargate. Le regole di affinità/anti-affinità Kubernetes non si applicano e non sono necessarie con i pod Fargate di Amazon EKS.
Quando crei un profilo Fargate, devi specificare il ruolo di esecuzione di un pod. Questo ruolo di esecuzione è per i componenti Amazon EKS che vengono eseguiti su infrastruttura Fargate utilizzando il profilo. Viene aggiunto al [controllo di accesso basato sul ruolo](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) del cluster di Kubernetes per l’autorizzazione. Ciò consente a `kubelet` in esecuzione sull’infrastruttura Fargate di registrarsi con il cluster Amazon EKS in modo che possa essere visualizzato nel cluster come nodo. Il ruolo di esecuzione del pod fornisce anche le autorizzazioni IAM per l’infrastruttura Fargate per consentire l’accesso in lettura ai repository di immagini di Amazon ECR. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md).
I profili Fargate non possono essere modificati. Tuttavia, è possibile creare un nuovo profilo aggiornato per sostituire un profilo esistente e quindi eliminare l’originale.
**Nota**
Qualsiasi pod in esecuzione utilizzando un profilo Fargate viene arrestato e messo in sospeso quando il profilo viene eliminato.
Se tutti i profili in un cluster sono nello stato `DELETING`, è necessario attendere che tale profilo Fargate finisca l’eliminazione prima di poter creare altri profili in tale cluster.
**Nota**
Attualmente, Fargate non supporta [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) di Kubernetes.
Amazon EKS e Fargate cercano di implementare i pod su ciascuna delle sottoreti definite nel profilo Fargate. Tuttavia, potresti ritrovarti con una diffusione irregolare. Se devi avere una diffusione uniforme, usa due profili Fargate. Anche la diffusione è importante in scenari in cui desideri implementare due repliche e non vuoi tempi di inattività. È consigliabile che ogni profilo abbia una sola sottorete.
## Componenti del profilo Fargate
Un profilo Fargate contiene i componenti elencati di seguito.
**Ruolo di esecuzione del pod**
Quando il cluster crea pod su AWS Fargate, il `kubelet` in esecuzione sull’infrastruttura di Fargate deve effettuare chiamate ad API AWS per tuo conto. Ad esempio, deve effettuare chiamate per estrarre le immagini del container da Amazon ECR. Il ruolo di esecuzione del pod Amazon EKS fornisce le autorizzazioni IAM per eseguire questa operazione.
Quando crei un profilo Fargate, devi specificare il ruolo di esecuzione di un pod da utilizzare col tuo pod. Questo ruolo viene aggiunto al [controllo di accesso basato sul ruolo](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) del cluster di Kubernetes per l’autorizzazione. Ciò consente a `kubelet` in esecuzione sull’infrastruttura Fargate di registrarsi con il cluster Amazon EKS in modo che possa essere visualizzato nel cluster come nodo. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md).
**Sottoreti**
Gli ID delle sottoreti per avviare i pod che utilizzano questo profilo. A questo momento, ai pod in esecuzione su Fargate non vengono assegnati indirizzi IP pubblici. Di conseguenza, in virtù di questo parametro, sono accettate solo le sottoreti private senza routing diretto a un gateway Internet.
**Selettori**
I selettori da abbinare ai pod per utilizzare questo profilo Fargate. È possibile specificare fino a cinque selettori in un profilo Fargate. I selettori hanno le seguenti componenti:
+ **Spazio dei nomi**: specifica uno spazio dei nomi per un selettore. Il selettore corrisponde solo ai pod che vengono creati in questo namespace. Tuttavia, è possibile creare più selettori per rivolgersi a più spazi dei nomi.
+ **Etichette**: è possibile specificare facoltativamente le etichette Kubernetes che corrispondono al selettore. Il selettore corrisponde solo ai pod che hanno tutte le etichette specificate nel selettore.
## Wildcard del profilo di Fargate
Oltre ai caratteri consentiti da Kubernetes, puoi utilizzare `*` e `?` nei criteri di selezione per namespace, chiavi di etichette e valori di etichette:
+ `*` rappresenta nessuno, uno o più caratteri. Ad esempio, `prod*` può rappresentare `prod` e `prod-metrics`.
+ `?` rappresenta un singolo carattere (ad esempio, `value?` può rappresentare `valuea`). Tuttavia, non può rappresentare `value` e `value-a`, perché `?` può rappresentare solo un carattere.
Questi caratteri jolly possono essere usati in qualsiasi posizione e in combinazione (ad esempio, `prod*`, `*dev`, e `frontend*?`). Altri caratteri jolly e forme di corrispondenza del modello, come le espressioni regolari, non sono supportati.
Se sono presenti più profili corrispondenti per il namespace e le etichette nelle specifiche del pod, Fargate seleziona il profilo in base all’ordinamento alfanumerico e al nome del profilo. Ad esempio, se entrambi i profili A (con il nome `beta-workload`) e il profilo B (con il nome `prod-workload`) hanno dei selettori corrispondenti per i pod da avviare, Fargate sceglie il profilo A (`beta-workload`) per i pod. I pod hanno etichette con il profilo A sui pod (ad esempio, `eks.amazonaws.com/fargate-profile=beta-workload`).
Se desideri eseguire la migrazione dei pod Fargate esistenti su nuovi profili che utilizzano caratteri jolly, puoi farlo in due modi:
+ Crea un nuovo profilo con i selettori corrispondenti, quindi elimina i vecchi profili. I pod etichettati con vecchi profili vengono riprogrammati con nuovi profili corrispondenti.
+ Se desideri eseguire la migrazione dei carichi di lavoro ma non hai la certezza di quali siano le etichette Fargate su ogni pod Fargate, puoi utilizzare il seguente metodo. Crea un nuovo profilo con un nome che ordina in ordine alfanumerico per primo tra i profili dello stesso cluster. Quindi, ricicla i pod Fargate che devono essere migrati a nuovi profili.
## Creazione di un profilo Fargate
Questa sezione descrive come creare un profilo Fargate. Devi inoltre aver creato un ruolo di esecuzione del pod da utilizzare per il profilo Fargate. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md). I pod in esecuzione su Fargate sono supportati solo su sottoreti private con un accesso [NAT gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) ai servizi AWS, ma senza una route diretta a un gateway Internet. In questo modo il VPC del cluster deve avere sottoreti private disponibili.
Puoi creare un profilo con ciò che segue:
+ [`eksctl`](#eksctl_create_a_fargate_profile)
+ [Console di gestione AWS](#console_create_a_fargate_profile)
## `eksctl`
**Creazione di un profilo Fargate con `eksctl` **
Crea il tuo profilo Fargate con il seguente comando `eksctl`, sostituendo ogni valore di esempio con i valori in tuo possesso. Devi specificare un namespace. Tuttavia, l’opzione `--labels` non è obbligatoria.
```
eksctl create fargateprofile \
--cluster my-cluster \
--name my-fargate-profile \
--namespace my-kubernetes-namespace \
--labels key=value
```
È possibile utilizzare determinati caratteri jolly per `my-kubernetes-namespace` e etichette `key=value`. Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](#fargate-profile-wildcards).
## Console di gestione AWS
**Creazione di un profilo Fargate con Console di gestione AWS **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Scegli il cluster per cui creare un profilo Fargate.
1. Scegli la scheda **Calcolo**.
1. Nella sezione **Profili Fargate**, scegli **Aggiungi profilo Fargate**.
1. Nella pagina **Configure Fargate profile** (Configura profilo Fargate), procedere come segue:
1. In **Nome**, inserisci un nome univoco per il profilo Fargate, ad esempio `my-profile`.
1. Per il **ruolo di esecuzione del pod**, scegli il ruolo di esecuzione del pod da utilizzare con il profilo Fargate. Vengono visualizzati solo i ruoli IAM con il principale del servizio `eks-fargate-pods.amazonaws.com`. Se non vedi alcun ruolo nell’elenco, è necessario crearne uno. Per ulteriori informazioni, consulta [Ruolo IAM di esecuzione del pod di Amazon EKS](pod-execution-role.md).
1. Modifica le **sottoreti** selezionate in base alle esigenze.
**Nota**
Solo le sottoreti private sono supportate per i pod in esecuzione su Fargate.
1. In **Tag**, puoi facoltativamente aggiungere tag al tuo profilo Fargate. Questi tag non si propagano ad altre risorse associate al profilo, ad esempio i suoi pod.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Configura selezione pod**, procedi come segue:
1. In **Namespace**, inserisci uno spazio dei nomi che corrisponda ai pod.
+ È possibile utilizzare spazi dei nomi specifici da abbinare, ad esempio `kube-system` o `default`.
+ È possibile utilizzare determinati caratteri jolly (ad esempio, `prod-*`) per abbinare più spazi dei nomi (ad esempio, `prod-deployment` e `prod-test`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](#fargate-profile-wildcards).
1. (Facoltativo) Aggiungere etichette Kubernetes al selettore. In particolare, aggiungile al selettore a cui devono corrispondere i pod nel namespace specificato.
+ Puoi aggiungere l’etichetta `infrastructure: fargate` al selettore in modo che solo i pod nel namespace specificato che hanno anche l’etichetta Kubernetes `infrastructure: fargate` corrispondano al selettore.
+ È possibile utilizzare determinati caratteri jolly (ad esempio, `key?: value?`) per abbinare più spazi dei nomi (ad esempio, `keya: valuea` e `keyb: valueb`). Per ulteriori informazioni, consulta [Wildcard del profilo di Fargate](#fargate-profile-wildcards).
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e crea**, controlla le informazioni relative al profilo Fargate e scegli **Crea**.
# Eliminare un profilo Fargate
Questo argomento descrive come eliminare un profilo Fargate. Quando si elimina un profilo Fargate, eventuali pod pianificati su Fargate con tale profilo vengono eliminati. Se tali pod corrispondono a un altro profilo Fargate, vengono pianificati su Fargate con quel profilo. Se non corrispondono più a nessun profilo Fargate, non saranno pianificati su Fargate e potrebbero rimanere in sospeso.
Solo un profilo Fargate in un cluster alla volta può essere nello stato `DELETING`. Devi attendere il completamento dell'eliminazione di un profilo Fargate prima di poter eliminare altri profili nel cluster.
Ѐ possibile eliminare un profilo con uno qualsiasi dei seguenti strumenti:
+ [`eksctl`](#eksctl_delete_a_fargate_profile)
+ [Console di gestione AWS](#console_delete_a_fargate_profile)
+ [CLI AWS](#awscli_delete_a_fargate_profile)
## `eksctl`
**Eliminare un profilo Fargate con `eksctl`**
Utilizza il comando seguente per eliminare un profilo da un cluster. Sostituire ogni *valore di esempio* con i propri valori.
```
eksctl delete fargateprofile --name my-profile --cluster my-cluster
```
## Console di gestione AWS
**Eliminare un profilo Fargate con Console di gestione AWS**
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel pannello di navigazione a sinistra, seleziona **Cluster**. Nell'elenco dei cluster, scegli il cluster da cui desideri eliminare il profilo Fargate.
1. Scegli la scheda **Calcolo**.
1. Scegli il profilo Fargate da eliminare e quindi **Elimina**.
1. Nella pagina **Elimina profilo Fargate**, digita il nome del profilo e scegli **Elimina**.
## CLI AWS
**Eliminare un profilo Fargate con AWS CLI**
Utilizza il comando seguente per eliminare un profilo da un cluster. Sostituire ogni *valore di esempio* con i propri valori.
```
aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster
```
# Comprendere i dettagli di configurazione dei pod di Fargate
Questa sezione descrive alcuni dei dettagli di configurazione dei pod unici per l’esecuzione dei pod Kubernetes su AWS Fargate.
## Memoria e CPU del pod
Kubernetes ti consente di definire le richieste, una quantità minima di risorse vCPU e di memoria allocate a ciascun container in un pod. I pod sono programmati da Kubernetes per garantire che almeno le risorse richieste per ciascun pod siano disponibili nella risorsa di calcolo. Per ulteriori informazioni, consulta [Gestione risorse di calcolo per container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) nella documentazione su Kubernetes.
**Nota**
Poiché Amazon EKS Fargate esegue solo un pod per nodo, lo scenario di espulsione dei pod in caso di meno risorse non si verifica. Tutti i pod Amazon EKS Fargate funzionano con priorità garantita, quindi la CPU e la memoria richieste devono essere uguali al limite per tutti i container. Per ulteriori informazioni, consulta [Gestire la qualità di servizio per i pod](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) nella documentazione di Kubernetes.
Quando i pod sono programmati su Fargate, le prenotazioni di vCPU e memoria all’interno della specifica del pod determinano la quantità di CPU e memoria per effettuare il provisioning per il pod.
+ La richiesta massima di qualsiasi container Init viene utilizzata per determinare i requisiti di memoria e vCPU della richiesta Init.
+ Le richieste per tutti i container con esecuzione prolungata vengono aggiunte per determinare i requisiti di memoria e vCPU della richiesta con esecuzione prolungata.
+ Il valore maggiore tra i due valori sopra indicati viene scelto per la richiesta di vCPU e memoria da utilizzare per il pod.
+ Fargate aggiunge 256 MB alla prenotazione di memoria di ogni pod per i componenti Kubernetes richiesti (`kubelet`, `kube-proxy` e `containerd`).
Fargate arrotonda alla configurazione di calcolo mostrata di seguito che corrisponde più strettamente alla somma delle richieste di vCPU e di memoria, al fine di garantire che i pod abbiano sempre le risorse necessarie per la loro esecuzione.
Se non specifichi una combinazione di vCPU e memoria, viene utilizzata la combinazione più piccola disponibile (.25 vCPU e 0,5 GB di memoria).
La tabella seguente mostra le combinazioni di vCPU e memoria disponibili per i pod in esecuzione su Fargate.
| Valore vCPU | Valore memoria |
| --- | --- |
| .25 vCPU | 0,5 GB, 1 GB, 2 GB |
| .5 vCPU | 1 GB, 2 GB, 3 GB, 4 GB |
| 1 vCPU | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB |
| 2 vCPU | Tra 4 GB e 16 GB in incrementi di 1 GB |
| 4 vCPU | Tra 8 GB e 30 GB in incrementi di 1 GB |
| 8 vCPU | Tra 16 GB e 60 GB in incrementi di 4 GB |
| 16 vCPU | Tra 32 GB e 120 GB in incrementi di 8 GB |
La memoria aggiuntiva riservata ai componenti Kubernetes può causare un’attività Fargate con più vCPUs di quelle richieste per il provisioning. Ad esempio, una richiesta per 1 vCPU e 8 GB di memoria avrà 256 MB aggiunti alla richiesta di memoria e fornirà un’attività Fargate di 2 vCPU e 9 GB di memoria, poiché non è disponibile alcuna attività con 1 vCPU e 9 GB di memoria.
Non vi è alcuna correlazione tra la dimensione del pod in esecuzione su Fargate e quella del nodo riportata da Kubernetes con `kubectl get nodes`. La dimensione del nodo riportata è spesso maggiore della capacità del pod. Puoi verificare la capacità del pod utilizzando il comando seguente. Sostituisci *default* con il namespace del pod e *pod-name* con il nome dello stesso.
```
kubectl describe pod --namespace default pod-name
```
Di seguito viene riportato un output di esempio:
```
[...]
annotations:
CapacityProvisioned: 0.25vCPU 0.5GB
[...]
```
L’annotazione `CapacityProvisioned` rappresenta la capacità del pod applicata e determina il costo del pod in esecuzione su Fargate. Per informazioni sui prezzi di queste configurazioni di calcolo, vedi [Prezzi Fargate AWS](https://aws.amazon.com/fargate/pricing/).
## Archiviazione in Fargate
Un pod in esecuzione su Fargate monta automaticamente un file system Amazon EFS senza bisogno della procedura di installazione manuale del driver. Non puoi utilizzare il provisioning dinamico dei volumi persistenti con nodi Fargate, ma puoi usare quello statico. Per ulteriori informazioni, consulta [Driver CSI per Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) su GitHub.
Una volta fornito, ciascun pod in esecuzione su Fargate riceve uno storage temporaneo predefinito di 20 GiB. Questo tipo di archiviazione viene eliminato dopo che un pod si ferma. Per i nuovi pod avviati su Fargate, la crittografia del volume di archiviazione temporanea è abilitata per impostazione predefinita. L’archiviazione del pod effimero viene crittografata con un algoritmo di crittografia AES-256 utilizzando chiavi gestite da Fargate AWS.
**Nota**
Lo storage utilizzabile predefinito per i pod Amazon EKS che funzionano su Fargate sono inferiori a 20 GiB. Questo perché parte dello spazio viene utilizzato da `kubelet` e altri moduli Kubernetes che vengono caricati all’interno del pod.
Puoi aumentare la quantità totale di storage temporaneo fino a un massimo di 175 GiB. Per configurare la dimensione con Kubernetes, specifica le richieste della risorsa `ephemeral-storage` per ogni container in un pod. Quando Kubernetes pianifica i pod, garantisce che la somma delle richieste di risorse per ciascun pod sia inferiore alla capacità dell’attività Fargate. Per ulteriori informazioni, consulta [Gestione delle risorse per pod e container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) nella documentazione di Kubernetes.
Amazon EKS Fargate fornisce un maggiore spazio di archiviazione temporaneo di quello richiesto ai fini dell’utilizzo del sistema. Ad esempio, una richiesta di 100 GiB fornirà un’attività Fargate con 115 GiB di storage temporaneo.
# Imposta azioni per gli eventi relativi all’applicazione di patch del sistema operativo AWS Fargate
Amazon EKS applica periodicamente delle patch al sistema operativo per i nodi AWS Fargate al fine di garantirne la sicurezza. Come parte del processo di applicazione delle patch, ricicliamo i nodi per installare le patch del sistema operativo. Gli aggiornamenti vengono effettuati in modo da avere il minore impatto possibile sui servizi. Tuttavia, se i pod non vengono espulsi con successo, a volte è necessario eliminarli. Di seguito sono riportate le azioni che è possibile intraprendere per ridurre al minimo le potenziali interruzioni:
+ Imposta i budget di interruzione dei pod (PDB) appropriati per limitare il numero di pod inattivi.
+ Crea regole di Amazon EventBridge per gestire le espulsioni non riuscite prima che i pod vengano eliminati.
+ Riavvia manualmente i pod interessati prima della data di espulsione indicata nella notifica ricevuta.
+ Crea una configurazione di notifica in Notifiche utente di AWS.
Amazon EKS lavora a stretto contatto con la community di Kubernetes per rendere disponibili le correzioni dei bug e le patch di sicurezza il più rapidamente possibile. L’avvio di tutti i pod Fargate avviene con la versione più recente della patch di Kubernetes, disponibile da Amazon EKS per la versione di Kubernetes del cluster. Se disponi di un pod con una patch di una versione precedente, Amazon EKS potrebbe riciclarlo per aggiornarlo alla versione più recente. Ciò consente di applicare ai pod gli aggiornamenti per la sicurezza più recenti, in modo da ridurre i rischi nel caso in cui si verifichi una problematica di tipo [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVE).
Quando il sistema operativo AWS Fargate viene aggiornato, Amazon EKS ti invia una notifica che include le risorse interessate e la data delle prossime espulsioni dei pod. Se la data di espulsione fornita è scomoda, hai la possibilità di riavviare manualmente i pod interessati prima della data di espulsione indicata nella notifica. Tutti i pod creati prima della data di ricezione della notifica sono soggetti a espulsione. Per ulteriori istruzioni su come riavviare manualmente i pod, consulta [Kubernetes Documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart).
Per limitare il numero di pod inattivi durante il riciclo degli stessi, puoi impostare i budget di interruzione dei pod (PDB). Con questa opzione è possibile specificare la disponibilità minima in base ai requisiti di ciascuna applicazione e consentire, allo stesso tempo, l’esecuzione di aggiornamenti. La disponibilità minima del PDB deve essere inferiore al 100%. Per ulteriori informazioni, consulta [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) nella documentazione di Kubernetes.
Amazon EKS utilizza l’[API di espulsione](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) per interrompere in modo sicuro il pod rispettando i budget di interruzione dei pod impostati per l’applicazione. I pod vengono espulsi dalla zona di disponibilità per ridurre al minimo l’impatto. Se l’espulsione ha esito positivo, il nuovo pod riceve la patch più recente e non sono richieste ulteriori operazioni.
Se l’espulsione di un pod ha esito negativo, Amazon EKS invia al tuo account un evento con dettagli relativi al pod in cui si è verificato l’errore. È possibile intraprendere alcune azioni in merito al messaggio prima del periodo di interruzione programmato, che varia in base all’urgenza della patch. Quando è il momento, Amazon EKS proverà a espellere nuovamente i pod. Questa volta, tuttavia, se l’espulsione ha esito negativo non viene inviato un nuovo evento Se l’espulsione continua a non riuscire, i pod esistenti verranno eliminati periodicamente in modo che i nuovi pod possano disporre della patch più recente.
L’esempio seguente mostra un evento ricevuto in caso di espulsione del pod che non riesce. Il messaggio contiene dettagli sul cluster, il nome del pod, il namespace del pod, il profilo Fargate e il periodo di interruzione pianificato.
```
{
"version": "0",
"id": "12345678-90ab-cdef-0123-4567890abcde",
"detail-type": "EKS Fargate Pod Scheduled Termination",
"source": "aws.eks",
"account": "111122223333",
"time": "2021-06-27T12:52:44Z",
"region": "region-code",
"resources": [
"default/my-database-deployment"
],
"detail": {
"clusterName": "my-cluster",
"fargateProfileName": "my-fargate-profile",
"podName": "my-pod-name",
"podNamespace": "default",
"evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget",
"scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]"
}
}
```
L’associazione di molteplici PDB a un singolo pod può causare un evento di errore di espulsione. Questo evento restituisce il messaggio di errore seguente.
```
"evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support",
```
È possibile creare un’azione desiderata in base a questo evento. Ad esempio, puoi modificare il budget di interruzione dei pod (PDB) per controllare il modo in cui i pod vengono espulsi. Più specificamente, supponi di iniziare con un PDB che specifica la percentuale di destinazione dei pod disponibili. Prima che i pod vengano terminati in modo forzato durante un aggiornamento, puoi regolare il PDB su una percentuale di pod differente. Per ricevere questo evento, devi creare una regola di Amazon EventBridge nell’account AWS e nella Regione AWS a cui appartiene il cluster. La regola deve utilizzare il **modello personalizzato** seguente. Per ulteriori informazioni, consulta la sezione [Creazione di regole Amazon EventBridge che reagiscono agli eventi](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) nella *Guida per l’utente di Amazon EventBridge*.
```
{
"source": ["aws.eks"],
"detail-type": ["EKS Fargate Pod Scheduled Termination"]
}
```
L’evento può essere configurato per acquisire un obiettivo adeguato impostato dall’utente. Per un elenco completo delle destinazioni disponibili, consulta [Destinazioni di Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) nella *Guida per l’utente di Amazon EventBridge*. Inoltre puoi creare una configurazione di notifica in Notifiche utente AWS. Quando usi Console di gestione AWS per creare la notifica, sotto la voce **Regole degli eventi** scegli **Elastic Kubernetes Service (EKS)** per il **Nome di servizio AWS** e **Arresto programmato di EKS Fargate pod** per il **Tipo di evento**. Per ulteriori informazioni, consulta [Guida introduttiva alle Notifiche utente AWS](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) nella Guida per l’utente delle Notifiche utente AWS.
Consulta [Domande frequenti: Avviso di espulsione di un Fargate Pod](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) in *AWS re:Post* per le domande frequenti riguardo alle espulsioni dei pod EKS.
# Raccogli le AWS metriche dell'app Fargate e dell'utilizzo
Puoi raccogliere metriche di sistema e metriche di CloudWatch utilizzo per AWS Fargate.
## Parametri di applicazione
Per le applicazioni in esecuzione su Amazon EKS e AWS Fargate, puoi utilizzare AWS Distro for OpenTelemetry (ADOT). ADOT ti consente di raccogliere i parametri di sistema e inviarli ai dashboard di Container Insights. CloudWatch Per iniziare a usare ADOT per le applicazioni in esecuzione su Fargate, [consultate CloudWatch Using Container Insights AWS with Distro OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) for nella documentazione ADOT.
## Parametri di utilizzo
Puoi utilizzare le metriche di CloudWatch utilizzo per fornire visibilità sull'utilizzo delle risorse da parte del tuo account. Utilizza queste metriche per visualizzare l'utilizzo corrente del servizio su CloudWatch grafici e dashboard.
AWS Le metriche di utilizzo di Fargate corrispondono alle AWS quote di servizio. È possibile configurare gli allarmi che avvisano quando l'uso si avvicina a una quota di servizio. Per ulteriori informazioni sulle quote di servizio per Fargate, consulta [Visualizzazione e gestione di quote di servizio di Amazon EKS e Fargate](service-quotas.md).
AWS Fargate pubblica le seguenti metriche nel namespace. ` AWS/Usage`
| Metrica | Description |
| --- | --- |
| `ResourceCount` | Il numero totale delle risorse specificate in esecuzione nell'account. La risorsa è definita dalle dimensioni associate attraverso il parametro. |
Le seguenti dimensioni vengono utilizzate per perfezionare le metriche di utilizzo pubblicate da AWS Fargate.
| Dimensione | Description |
| --- | --- |
| `Service` | Il nome del AWS servizio che contiene la risorsa. Per le metriche di utilizzo di AWS Fargate, il valore per questa dimensione è. `Fargate` |
| `Type` | Il tipo di entità che viene segnalato. Attualmente, l'unico valore valido per le metriche di utilizzo di AWS Fargate è. `Resource` |
| `Resource` | Il tipo di risorsa in esecuzione. Attualmente, AWS Fargate restituisce informazioni sull'utilizzo di Fargate On-Demand. Il valore della risorsa per l'utilizzo on demand di Fargate è `OnDemand`. [NOTA] ==== L’utilizzo di Fargate On-Demand combina i pod Amazon EKS utilizzando Fargate, le attività Amazon ECS che utilizzano il tipo di avvio di Fargate e le attività Amazon ECS che usano il provider di capacità `FARGATE`. ==== |
| `Class` | La classe della risorsa monitorata. Attualmente, AWS Fargate non utilizza la dimensione classe. |
### Creazione di un CloudWatch allarme per monitorare le metriche di utilizzo delle risorse di Fargate
AWS Fargate fornisce metriche di CloudWatch utilizzo che corrispondono alle quote di AWS servizio per l'utilizzo delle risorse Fargate On-Demand. Nella console Service Quotas (Quote di Servizio) è possibile visualizzare l'utilizzo in un grafico. È inoltre possibile configurare gli allarmi che avvisano quando l'uso si avvicina a una quota di servizio. Per ulteriori informazioni, consulta [Raccogli le AWS metriche dell'app Fargate e dell'utilizzo](#monitoring-fargate-usage).
Utilizzate i seguenti passaggi per creare un CloudWatch allarme basato sulle metriche di utilizzo delle risorse di Fargate.
1. Apri la console Service Quotas all'indirizzo. https://console.aws.amazon.com/servicequotas/
1. Nel riquadro di navigazione a sinistra, scegli ** AWS servizi**.
1. Dall'elenco dei ** AWS servizi**, cerca e seleziona ** AWS Fargate**.
1. Nell'elenco **Service Quotas**, seleziona la quota di utilizzo Fargate per cui desideri creare un allarme.
1. Nella sezione CloudWatch Allarmi Amazon, scegli **Crea**.
1. Per **Soglia di allarme**, scegli la percentuale del valore della quota applicata che desideri impostare come valore per l'allarme.
1. Per **Nome allarme**, immetti un nome per l'allarme e quindi scegli **Crea**.
# Avviare la registrazione di log AWS Fargate per il cluster
Amazon EKS su Fargate offre un router di registro integrato basato su Fluent Bit. Ciò significa che non viene eseguito esplicitamente un container Fluent Bit come sidecar, ma è Amazon a eseguirlo. Tutto quello che devi fare è configurare il router di log. La configurazione avviene attraverso un `ConfigMap` dedicato che deve soddisfare i seguenti criteri:
+ Deve essere denominato `aws-logging`
+ Creato in uno spazio dei nomi dedicato denominato `aws-observability`
+ Non può contenere più di 5.300 caratteri.
Una volta creato `ConfigMap`, Amazon EKS su Fargate lo rileva in automatico e lo utilizza per configurare il router di log. Fargate utilizza una versione di AWS per Fluent Bit, una distribuzione upstream conforme di Fluent Bit gestita da AWS. Per ulteriori informazioni, consultare [AWS per Fluent Bit](https://github.com/aws/aws-for-fluent-bit) su GitHub.
Il router di log consente di utilizzare la vasta gamma di servizi AWS per l'analisi e per l'archiviazione dei log. È possibile trasmettere i registri da Fargate direttamente ad Amazon CloudWatch, un servizio OpenSearch di Amazon. È possibile trasmettere i log anche a destinazioni come [Amazon S3](https://aws.amazon.com/s3/) e [flusso di dati Amazon Kinesis](https://aws.amazon.com/kinesis/data-streams/), così come a strumenti partner tramite [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/).
+ Un profilo Fargate esistente che specifichi un namespace Kubernetes esistente in cui si implementano i pod Fargate. Per ulteriori informazioni, consulta [Fase 3: creare un profilo Fargate per il cluster](fargate-getting-started.md#fargate-gs-create-profile).
+ Un ruolo di esecuzione del pod Fargate esistente. Per ulteriori informazioni, consulta [Fase 2: creare un ruolo di esecuzione del pod Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role).
## Configurazione del router di log
**Importante**
Affinché i log vengano pubblicati correttamente, deve essere possibile accedere alla rete dal VPC in cui si trova il cluster alla destinazione dei log. Ciò riguarda principalmente gli utenti che personalizzano le regole di uscita per il VPC. Per ulteriori informazioni sull’utilizzo di CloudWatch, consultare la pagina [Using CloudWatch Logs with interface VPC endpoints](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) della *Guida per l’utente di Amazon CloudWatch Logs*.
Nelle fasi seguenti, sostituire ogni *valore di esempio* con i propri valori.
1. Creare uno spazio dei nomi Kubernetes dedicato denominato `aws-observability`.
1. Salva nel tuo computer i seguenti contenuti in un file denominato `aws-observability-namespace.yaml`. Il valore per `name` deve essere `aws-observability` e l'etichetta `aws-observability: enabled` è obbligatoria.
```
kind: Namespace
apiVersion: v1
metadata:
name: aws-observability
labels:
aws-observability: enabled
```
1. Crea lo spazio dei nomi.
```
kubectl apply -f aws-observability-namespace.yaml
```
1. Crea una `ConfigMap` con valore dei dati `Fluent Conf` per spedire i log del container verso una destinazione. Fluent Conf è Fluent Bit, un linguaggio di configurazione del processore di log veloce e leggero che viene utilizzato per instradare i log del container verso una destinazione di log selezionata. Per ulteriori informazioni, consultare [File di configurazione](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) nella documentazione di Fluent Bit.
**Importante**
In una `Fluent Conf` tipica, le sezioni principali incluse sono `Service`, `Input`, `Filter` e `Output`. Tuttavia, il router di log di Fargate accetta solo:
Le sezioni `Filter` e `Output`.
Una sezione `Parser`.
Se fornisci altre sezioni, queste verranno rifiutate.
Il router di log Fargate gestisce le sezioni `Service` e `Input`. Ha la sezione `Input` seguente, che non può essere modificata e non è necessaria in `ConfigMap`. Tuttavia, è possibile ricavarne informazioni, ad esempio il limite del buffer di memoria e il tag applicato per i log.
```
[INPUT]
Name tail
Buffer_Max_Size 66KB
DB /var/log/flb_kube.db
Mem_Buf_Limit 45MB
Path /var/log/containers/*.log
Read_From_Head On
Refresh_Interval 10
Rotate_Wait 30
Skip_Long_Lines On
Tag kube.*
```
Quando crei la `ConfigMap`, ricorda le seguenti regole utilizzate da Fargate per convalidare i campi:
+ `[FILTER]`, `[OUTPUT]`, e `[PARSER]` dovrebbero essere specificati sotto ogni chiave corrispondente. Ad esempio: `[FILTER]` deve essere in `filters.conf`. È possibile avere uno o più `[FILTER]` in `filters.conf`. Anche le sezioni `[OUTPUT]` e `[PARSER]` dovrebbero essere specificate sotto le chiavi corrispondenti. Specificando più sezioni `[OUTPUT]`, è possibile instradare i registritha a destinazioni diverse contemporaneamente.
+ Fargate convalida le chiavi richieste per ogni sezione. `Name` e `match` sono necessari per ogni `[FILTER]` e `[OUTPUT]`. `Name` e `format` sono necessari per ogni `[PARSER]`. Le chiavi non fanno distinzione tra maiuscole e minuscole.
+ Variabili di ambiente come `${ENV_VAR}` non sono ammesse in `ConfigMap`.
+ La rientranza deve essere la stessa sia per la direttiva che per la coppia chiave-valore all'interno di ogni `filters.conf`, `output.conf` e `parsers.conf`. Le coppie chiave-valore devono essere rientranti piuttosto che direttive.
+ Fargate effettua la convalida in base ai seguenti filtri supportati: `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify` e `kubernetes`.
+ Fargate effettua la convalida in base al seguente output supportato: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs`, e `kinesis`.
+ In `ConfigMap` deve essere fornito almeno un plugin `Output` supportato per abilitare la registrazione di log. `Filter` e `Parser` non sono necessari per abilitarla.
È possibile anche eseguire Fluent Bit su Amazon EC2 utilizzando la configurazione desiderata per risolvere eventuali problemi derivanti dalla convalida. Crea il `ConfigMap` utilizzando uno degli esempi seguenti.
**Importante**
La registrazione di log Fargate di Amazon EKS non supporta la configurazione dinamica di `ConfigMap`. Eventuali modifiche a `ConfigMap` vengono applicate solo ai nuovi pod. Le modifiche non vengono applicate ai pod esistenti.
Crea un `ConfigMap` utilizzando l'esempio per la destinazione di log desiderata.
**Nota**
Puoi anche utilizzare Flusso di dati Amazon Kinesis come destinazione dei log. Se utilizzi Flusso di dati Kinesis, assicurati che al ruolo di esecuzione del pod sia stata concessa l'autorizzazione `kinesis:PutRecords`. Per ulteriori informazioni, consulta la sezione [Permissions](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) relativa a flusso di dati Amazon Kinesis in *Fluent Bit: Official Manual*.
**Example**
------
#### [ CloudWatch ]
Quando utilizzi CloudWatch, hai a disposizione due opzioni di output:
+ [Un plug-in di output scritto in C](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch)
+ [Un plug-in di output scritto in Golang](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit)
Nell'esempio seguente viene illustrato come utilizzare il plug-in `cloudwatch_logs` per inviare i log a CloudWatch.
1. Salva i contenuti seguenti in un file denominato `aws-logging-cloudwatch-configmap.yaml`. Sostituire *region-code* con la Regione AWS in cui si trova il cluster. I parametri in `[OUTPUT]` sono obbligatori.
```
kind: ConfigMap
apiVersion: v1
metadata:
name: aws-logging
namespace: aws-observability
data:
flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch.
filters.conf: |
[FILTER]
Name parser
Match *
Key_name log
Parser crio
[FILTER]
Name kubernetes
Match kube.*
Merge_Log On
Keep_Log Off
Buffer_Size 0
Kube_Meta_Cache_TTL 300s
output.conf: |
[OUTPUT]
Name cloudwatch_logs
Match kube.*
region region-code
log_group_name my-logs
log_stream_prefix from-fluent-bit-
log_retention_days 60
auto_create_group true
parsers.conf: |
[PARSER]
Name crio
Format Regex
Regex ^(?