**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 su che si trova nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Aggiornamento da Amazon Linux 2 ad Amazon Linux 2023 **avvertimento** Amazon EKS ha interrotto la pubblicazione delle AMI EKS-optimized Amazon Linux 2 (AL2) il 26 novembre 2025. Le AMI basate su AL2023 e Bottlerocket per Amazon EKS sono disponibili per tutte le versioni di Kubernetes supportate, inclusa la 1.33 e successive. AL2023 è un sistema Linux-based operativo progettato per fornire un ambiente sicuro, stabile e ad alte prestazioni per le tue applicazioni cloud. È la nuova generazione di Amazon Linux offerta da Amazon Web Services ed è disponibile in tutte le versioni di Amazon EKS supportate. AL2023 offre diversi miglioramenti rispetto ad AL2. Per un confronto completo, consulta [Comparing AL2 and Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) nella *Guida per l’utente di Amazon Linux 2023*. Diversi pacchetti sono stati aggiunti, aggiornati e rimossi da AL2. Si consiglia vivamente di testare le applicazioni con AL2023 prima dell’aggiornamento. Per un elenco di tutte le modifiche ai pacchetti in AL2023, consulta [Package changes in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) nelle *Note di rilascio di Amazon Linux 2023*. Oltre a queste modifiche, devi tenere presente quanto riportato di seguito: + 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 modello di avvio che specifica un ID AMI personalizzato, ora devi fornire esplicitamente metadati aggiuntivi del cluster. È necessario fornire questi metadati quando si crea un nuovo gruppo di nodi. Di seguito [ è riportato un esempio dei parametri minimi richiesti da ](https://awslabs.github.io/amazon-eks-ami/nodeadm/) nodeadm `apiServerEndpoint``certificateAuthority`, dove e il servizio `cidr` sono ora obbligatori: ``` --- 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 AL2, i metadati di questi parametri sono stati rilevati dalla chiamata `DescribeCluster` API di Amazon EKS. Con AL2023, questo comportamento è cambiato poiché la chiamata API aggiuntiva rischia una limitazione (della larghezza di banda della rete) durante gli aumenti verticali su larga scala dei nodi. 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 [`DescribeCluster`](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) nel *Riferimento di API Amazon EKS*. + Per AL2023, `nodeadm` modifica anche il formato per applicare i parametri a `kubelet` per ogni nodo che utilizza [`NodeConfigSpec`](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec). In AL2, ciò è stato fatto con il parametro `--kubelet-extra-args`. Questo è usato comunemente per aggiungere etichette e taint ai nodi. L’esempio seguente mostra l’applicazione di `maxPods` e `--node-labels` al nodo. ``` --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: test-cluster apiServerEndpoint: https://example.com certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk= cidr: 10.100.0.0/16 kubelet: config: maxPods: 110 flags: - --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test ``` + Per AL2023 è richiesta la versione del CNI di Amazon VPC `1.16.2` o superiore. + AL2023 richiede `IMDSv2` per impostazione predefinita. `IMDSv2` presenta diversi vantaggi che aiutano a migliorare il livello di sicurezza. Usa un metodo di autenticazione orientato alla sessione che prevede la creazione di un token segreto in una semplice richiesta HTTP PUT per avviare la sessione. Il token di una sessione può avere una validità compresa tra 1 secondo e 6 ore. Per ulteriori informazioni su come passare da a`IMDSv2`, consulta [ Transition `IMDSv1` to using Instance Metadata Service Version 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) e [ Ottieni tutti i vantaggi di IMDSv2 e disabilita IMDSv1 nella tua infrastruttura. AWS](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure) Se desideri usare `IMDSv1`, puoi farlo comunque sovrascrivendo manualmente le impostazioni usando le proprietà di avvio dell’opzione dei metadati di istanza. **Nota** Per `IMDSv2` con AL2023, il numero di hop predefinito per i gruppi di nodi gestiti può variare: Quando non si utilizza un modello di avvio, il valore predefinito è impostato su `1`. Ciò significa che i container non avranno accesso alle credenziali del nodo che usano IMDS. Se necessiti dell’accesso del container alle credenziali del nodo, puoi comunque farlo utilizzando un [modello di lancio Amazon EC2 personalizzato](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html). Quando si utilizza un’AMI personalizzata in un modello di avvio, il valore predefinito `HttpPutResponseHopLimit` è impostato su `2`. Puoi sostituire manualmente `HttpPutResponseHopLimit` nel modello di avvio. In alternativa, puoi utilizzare [Amazon EKS Pod Identity](pod-identities.md) per fornire credenziali anziché `IMDSv2`. + AL2023 presenta la nuova generazione di gerarchia unificata dei gruppi di controllo (`cgroupv2`). `cgroupv2` viene utilizzato per implementare un runtime di container e da parte di `systemd`. Sebbene AL2023 contenga ancora codice che consentirebbe il funzionamento del sistema con `cgroupv1`, si tratta di una configurazione sconsigliata o non supportata. Questa configurazione verrà completamente rimossa in una delle future release principali di Amazon Linux. + `eksctl` versione `0.176.0` o successiva è richiesta affinché `eksctl` supporti AL2023. Per i gruppi di nodi gestiti precedentemente esistenti, puoi eseguire un aggiornamento sul posto o un aggiornamento a seconda di come stai utilizzando un modello di blue/green avvio: + Se utilizzi un’AMI personalizzata con un gruppo di nodi gestito, puoi eseguire un aggiornamento sul posto scambiando l’ID AMI nel modello di avvio. Devi assicurarti che le applicazioni e tutti i dati utente vengano trasferiti ad AL2023 prima di eseguire questa strategia di aggiornamento. + Se utilizzi gruppi di nodi gestiti con il modello di avvio standard o con un modello di avvio personalizzato che non specifica l'ID AMI, devi eseguire l'aggiornamento utilizzando una blue/green strategia. Un blue/green aggiornamento è in genere più complesso e comporta la creazione di un gruppo di nodi completamente nuovo in cui è necessario specificare AL2023 come tipo di AMI. Il nuovo gruppo di nodi dovrà quindi essere configurato con cura per garantire che tutti i dati personalizzati del gruppo di nodi AL2 siano compatibili con il nuovo sistema operativo. Una volta che il nuovo gruppo di nodi è stato testato e convalidato con le applicazioni, i Pod possono essere migrati dal vecchio gruppo di nodi al nuovo gruppo di nodi. Una volta completata la migrazione, puoi eliminare il vecchio gruppo di nodi. Se utilizzi Karpenter e desideri utilizzare AL2023, dovrai modificare il campo `EC2NodeClass` `amiFamily` con AL2023. Per impostazione predefinita, Drift è abilitato in Karpenter. Ciò significa che una volta modificato il campo `amiFamily`, Karpenter aggiornerà automaticamente i nodi worker all’AMI più recente, quando disponibile. ## Informazioni aggiuntive su nodeadm Quando utilizzi un'AMI EKS-optimized Amazon Linux 2023 o crei un'AMI Amazon Linux 2023 personalizzata con gli script Packer forniti nel GitHub repository ufficiale amazon-eks-ami, dovresti evitare di eseguire esplicitamente nodeadm init all'interno dei dati utente di EC2 o come parte della tua AMI personalizzata. Se desideri generare una dinamica NodeConfig nei tuoi dati utente, puoi scrivere tale configurazione in un file yaml o json drop-in. `/etc/eks/nodeadm.d` Questi file di configurazione verranno uniti e applicati al nodo quando nodeadm init viene avviato automaticamente più avanti nel processo di avvio. Ad esempio: ``` cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: kubelet: flags: - --node-labels=foo=bar EOF ``` Le AMI di EKS-optimized Amazon Linux 2023 eseguono automaticamente nodeadm init in due fasi tramite servizi systemd separati: nodeadm-config viene eseguito prima dell'esecuzione dei dati utente, mentre nodeadm-run viene eseguito successivamente. Il servizio nodeadm-config stabilisce le configurazioni di base per containerd e kubelet prima dell'esecuzione dei dati utente. Il servizio nodeadm-run esegue alcuni demoni di sistema e completa tutte le configurazioni finali dopo l'esecuzione dei dati utente. Se il comando nodeadm init viene eseguito un'altra volta, tramite dati utente o un'AMI personalizzata, può infrangere le ipotesi sull'ordine di esecuzione, portando a risultati imprevisti, tra cui ENI non configurati correttamente.