**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à.
# Comprendere il ciclo di vita delle versioni di Kubernetes su EKS
**Suggerimento**
[Registrati](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) ai prossimi workshop Amazon EKS.
Kubernetes è in rapida evoluzione, con nuovi aggiornamenti di progettazione, funzionalità e correzioni di bug. La community rilascia nuove versioni di Kubernetes secondarie (ad esempio, `1.35`) in media una volta ogni quattro mesi. Amazon EKS segue il ciclo di rilascio e deprecazione originario per le versioni secondarie. Man mano che nuove versioni di Kubernetes diventano disponibili in Amazon EKS, si consiglia di aggiornare tempestivamente i cluster in modo da usare la versione più recente disponibile.
Una versione secondaria è supportata come standard in Amazon EKS per i primi 14 mesi dopo il rilascio. Una volta superata la data di fine del supporto standard, la versione passa al supporto esteso per i 12 mesi successivi. Il supporto esteso consente di mantenere una versione Kubernetes specifica di più a lungo a un costo aggiuntivo per ora del cluster. Se non hai aggiornato il cluster prima della fine del periodo di supporto esteso, il cluster viene aggiornato automaticamente alla versione estesa più vecchia attualmente supportata.
Il supporto esteso è abilitato per impostazione predefinita. Per disabilitarlo, consulta [Disable EKS extended support](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html).
Ti consigliamo di creare il tuo cluster con l’ultima versione di Kubernetes disponibile supportata da Amazon EKS. Se la propria applicazione richiede una versione specifica di Kubernetes, è possibile selezionare versioni precedenti. Puoi creare nuovi cluster Amazon EKS su qualsiasi versione offerta con supporto standard o esteso.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/_dJdAZ_J_jw?rel=0)
## Versioni disponibili con supporto standard
Le seguenti versioni di Kubernetes sono attualmente disponibili nel supporto standard di Amazon EKS:
+ `1.35`
+ `1.34`
+ `1.33`
+ `1.32`
Per le modifiche importanti di cui tenere conto per ogni versione del supporto standard, consulta [Kubernetes versions standard support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html).
## Versioni disponibili con supporto esteso
Le seguenti versioni di Kubernetes sono attualmente disponibili nel supporto esteso di Amazon EKS:
+ `1.31`
+ `1.30`
+ `1.29`
Per le modifiche importanti di cui tenere conto per ogni versione del supporto esteso, consulta [Kubernetes versions extended support](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-extended.html).
## Calendario di rilascio di Amazon EKS Kubernetes
La tabella seguente mostra le date importanti di rilascio e supporto da considerare per ciascuna versione di Kubernetes. La fatturazione per il supporto esteso parte all’inizio del giorno in cui la versione raggiunge la fine del supporto standard, nel fuso orario UTC\$10. Le date nella tabella seguente utilizzano il fuso orario UTC\$10.
**Nota**
Le date con solo un mese e un anno sono approssimative e vengono aggiornate con una data esatta quando nota.
Per ricevere notifiche di tutte le modifiche al file di origine di questa pagina di documentazione specifica, puoi iscriverti al seguente URL con un lettore RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/versioning/kubernetes-versions.adoc.atom
```
| Versione di Kubernetes | Versione upstream | Rilascio Amazon EKS | Data di fine del supporto standard | Data di fine del supporto esteso |
| --- | --- | --- | --- | --- |
| `1.35` | 17 dicembre 2025 | 27 gennaio 2026 | 27 marzo 2027 | 27 marzo 2028 |
| `1.34` | 27 agosto 2025 | 2 ottobre 2025 | 2 dicembre 2026 | 2 dicembre 2027 |
| `1.33` | 23 aprile 2025 | 29 maggio 2025 | 29 luglio 2026 | 29 luglio 2027 |
| `1.32` | 11 dicembre 2024 | 23 gennaio 2025 | 23 marzo 2026 | 23 marzo 2027 |
| `1.31` | 13 agosto 2024 | 26 settembre 2024 | 26 novembre 2025 | 26 novembre 2026 |
| `1.30` | 17 aprile 2024 | 23 maggio 2024 | 23 luglio 2025 | 23 luglio 2026 |
| `1.29` | 13 dicembre 2023 | 23 gennaio 2024 | 23 marzo 2025 | 23 marzo 2026 |
## Ottieni informazioni sulla versione con la AWS CLI
Puoi utilizzare la AWS CLI per ottenere informazioni sulle versioni di Kubernetes disponibili su EKS, come la data di fine di Standard Support.
### Per recuperare informazioni sulle versioni di Kubernetes disponibili su EKS utilizzando la CLI AWS
1. Apri il terminale.
1. Assicurati di avere la AWS CLI installata e configurata. Per ulteriori informazioni, vedi [Installing or updating to the latest version of the CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Esegui il comando seguente:
```
aws eks describe-cluster-versions
```
1. Il comando restituirà un output JSON con dettagli sulle versioni del cluster disponibili. Ecco un esempio dell’output:
```
{
"clusterVersions": [
{
"clusterVersion": "1.31",
"clusterType": "eks",
"defaultPlatformVersion": "eks.21",
"defaultVersion": true,
"releaseDate": "2024-09-25T17:00:00-07:00",
"endOfStandardSupportDate": "2025-11-25T16:00:00-08:00",
"endOfExtendedSupportDate": "2026-11-25T16:00:00-08:00",
"status": "STANDARD_SUPPORT",
"kubernetesPatchVersion": "1.31.3"
}
]
}
```
**L’output fornisce le seguenti informazioni per ogni versione del cluster:**
+ `clusterVersion`: la versione Kubernetes del cluster EKS
+ `clusterType`: il tipo di cluster (ad esempio, "eks")
+ `defaultPlatformVersion`: la versione predefinita della piattaforma EKS
+ `defaultVersion`: se si tratta della versione predefinita
+ `releaseDate`: la data in cui è stata rilasciata questa versione
+ `endOfStandardSupportDate`: la data di fine del supporto standard
+ `endOfExtendedSupportDate`: la data di fine del supporto esteso
+ `status`: lo stato del supporto corrente della versione, ad esempio `STANDARD_SUPPORT` o `EXTENDED_SUPPORT`
+ `kubernetesPatchVersion`: la versione specifica della patch Kubernetes
## Versione Amazon EKS FAQs
**Quante versioni di Kubernetes sono disponibili nel supporto standard?**
Amazon EKS, in linea con il supporto della community Kubernetes per le versioni di Kubernetes, si impegna a offrire il supporto per almeno tre versioni di Kubernetes in qualunque momento. L’annuncio della data di fine supporto standard di una qualsiasi versione di Kubernetes secondaria sarà comunicato almeno 60 giorni prima. A causa del processo di qualifica e rilascio di Amazon EKS per le nuove versioni di Kubernetes, la data di fine supporto standard di una versione di Kubernetes in Amazon EKS avverrà in corrispondenza o dopo la data in cui il progetto Kubernetes smetterà di supportare la versione a monte.
**Per quanto tempo Kubernetes riceve il supporto standard da parte di Amazon EKS?**
Una versione di Kubernetes è supportata per 14 mesi dopo la prima disponibilità su Amazon EKS. Ciò è confermato anche se Kubernetes a monte non supporterà più una versione disponibile in Amazon EKS. Viene eseguito il backporting delle patch di sicurezza applicabili alle versioni di Kubernetes che sono supportate in Amazon EKS.
**Riceverò un avviso quando il supporto standard per una versione Kubernetes su Amazon EKS è terminato?**
Sì. Se in alcuni cluster del tuo account è in esecuzione la versione prossima alla fine del supporto, Amazon EKS invia un avviso tramite AWS Health Dashboard circa 12 mesi dopo il rilascio della versione di Kubernetes su Amazon EKS. L’avviso include la data di fine supporto, che è successiva di almeno 60 giorni alla data dell’invio dell’avviso.
**Quali funzionalità di Kubernetes sono supportate da Amazon EKS?**
Amazon EKS supporta tutte le funzionalità di disponibilità generale (GA) dell’API di Kubernetes. Per impostazione predefinita, le nuove versioni beta APIs non sono abilitate nei cluster. Tuttavia, la versione beta esistente in precedenza APIs e le nuove versioni beta esistenti APIs continuano ad essere abilitate per impostazione predefinita. Le funzionalità alfa non sono supportate.
**I gruppi di nodi gestiti di Amazon EKS vengono aggiornati automaticamente insieme alla versione del piano di controllo del cluster?**
No, un gruppo di nodi gestiti crea istanze Amazon EC2 nel tuo account. Queste istanze non vengono aggiornate in automatico quando l’utente o Amazon EKS aggiorna il piano di controllo. Per ulteriori informazioni, consulta [Aggiornamento del gruppo di nodi gestito per il cluster](update-managed-node-group.md). Si consiglia di mantenere la stessa versione di Kubernetes sul piano di controllo e sui nodi.
**I gruppi di nodi autogestiti vengono aggiornati automaticamente insieme alla versione del piano di controllo del cluster?**
No, un gruppo di nodi autogestito include le istanze di Amazon EC2 nel tuo account. Queste istanze non vengono aggiornate in automatico quando tu o Amazon EKS aggiornate la versione del piano di controllo per tuo conto. Nella console, un gruppo di nodi autogestito non riceve alcuna indicazione di aggiornamento. È possibile visualizzare la versione di `kubelet` installata su un nodo selezionando il nodo nella finestra di dialogo **Nodi** nella scheda **Panoramica** del cluster per determinare quali nodi devono essere aggiornati. È necessario aggiornare manualmente i nodi. Per ulteriori informazioni, consulta [Aggiornamento dei nodi autogestiti per il tuo cluster](update-workers.md).
Il progetto Kubernetes verifica la compatibilità tra il piano di controllo e i nodi per un massimo di due versioni secondarie. Ad esempio, i nodi `1.32` continuano a funzionare se orchestrati da un piano di controllo `1.35`. Tuttavia, non è consigliabile l’esecuzione di un cluster con nodi aggiornati in modo persistente a tre versioni secondarie precedenti rispetto al piano di controllo. Per ulteriori informazioni, consulta [Policy per la versione Kubernetes e il supporto Skew della versione](https://kubernetes.io/docs/setup/version-skew-policy/) nella documentazione di Kubernetes. Si consiglia di mantenere la stessa versione di Kubernetes sul piano di controllo e sui nodi.
**I pod in esecuzione su Fargate vengono aggiornati automaticamente con un aggiornamento automatico della versione del piano di controllo cluster?**
No. Consigliamo di eseguire i pod Fargate come parte di un controller di replica, così come avviene in un’implementazione di Kubernetes. Quindi esegui un riavvio continuo di tutti i pod Fargate. La nuova versione del pod Fargate viene implementata con una versione `kubelet` che corrisponde alla versione aggiornata del piano di controllo del cluster. Per ulteriori informazioni, consulta l’argomento relativo alla funzionalità [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) nella documentazione Kubernetes.
Se aggiorni il piano di controllo, dovrai comunque aggiornare personalmente i nodi Fargate. Per aggiornare i nodi Fargate, elimina il pod Fargate rappresentato dal nodo e implementalo nuovamente. Il nuovo pod viene implementato con una versione `kubelet` che corrisponde alla versione del cluster.
**Quali versioni di Kubernetes sono supportate per i nodi ibridi?**
Amazon EKS Hybrid Nodes supporta le stesse versioni di Kubernetes dei cluster Amazon EKS con altri tipi di calcolo dei nodi, incluso il supporto della versione Kubernetes standard ed esteso. I nodi ibridi non vengono aggiornati automaticamente quando si aggiorna la versione del piano di controllo, perché ne è responsabile l’utente. Per ulteriori informazioni, consulta [Aggiornamento dei nodi ibridi per il tuo cluster](hybrid-nodes-upgrade.md).
## Supporto esteso per Amazon EKS FAQs
**La terminologia del supporto standard e del supporto esteso è nuova per me. Cosa significano questi termini?**
Il supporto standard per una versione di Kubernetes in Amazon EKS inizia quando viene rilasciata una versione Kubernetes su Amazon EKS e termina 14 mesi dopo la data di rilascio. Il supporto esteso per una versione di Kubernetes inizierà immediatamente dopo la fine del supporto standard e terminerà trascorsi i 12 mesi successivi. Ad esempio, il supporto standard per la versione `1.23` in Amazon EKS termina l’11 ottobre 2023. Il supporto esteso per la versione `1.23` è iniziato il 12 ottobre 2023 ed è terminato l’11 ottobre 2024.
**Cosa devo fare per ottenere un supporto esteso per i cluster Amazon EKS?**
Dovrai abilitare il supporto esteso (vedi [EKS extended support](https://docs.aws.amazon.com/eks/latest/userguide/enable-extended-support.html)) per il tuo cluster modificando la policy di aggiornamento del cluster in EXTENDED. Per impostazione predefinita su tutti i cluster nuovi ed esistenti, la policy di aggiornamento è impostata su EXTENDED, se non diversamente specificato. Consulta [Cluster upgrade policy](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html) per visualizzare la policy di aggiornamento del cluster. Il supporto standard inizia quando viene rilasciata una versione di Kubernetes su Amazon EKS e termina 14 mesi dopo la data di rilascio. Il supporto esteso per una versione di Kubernetes inizierà immediatamente dopo la fine del supporto standard e terminerà trascorsi i 12 mesi successivi.
**Per quali versioni Kubernetes posso ottenere il supporto esteso?**
Puoi eseguire i cluster su qualsiasi versione per un massimo di 12 mesi dopo la fine del supporto standard per quella versione. Ciò significa che ogni versione sarà supportata per 26 mesi in Amazon EKS (14 mesi di supporto standard più 12 mesi di supporto esteso).
**Cosa succede se non voglio utilizzare il supporto esteso?**
Se non desideri ricevere automaticamente il supporto esteso, puoi aggiornare il cluster a una versione di Kubernetes che includa il supporto standard di Amazon EKS. Per disabilitare il supporto esteso, consulta [Disable EKS extended support](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html). Nota: se disabiliti il supporto esteso, il tuo cluster sarà automaticamente aggiornato al termine del supporto standard.
**Cosa succederà alla fine dei 12 mesi di supporto esteso?**
I cluster in esecuzione su una versione di Kubernetes che ha completato il ciclo di vita di 26 mesi (14 mesi di supporto standard più 12 mesi di supporto esteso) verranno aggiornati automaticamente alla versione successiva. L’aggiornamento automatico include solo il piano di controllo Kubernetes. Se disponi di nodi della modalità automatica di EKS, potrebbero aggiornarsi automaticamente. I nodi autogestiti e i gruppi di nodi gestiti EKS rimarranno nella versione precedente.
Allo scadere della data di fine di supporto, non è più possibile creare nuovi cluster Amazon EKS con la versione non supportata. I piani di controllo esistenti vengono aggiornati in automatico da Amazon EKS alla prima versione supportata attraverso un processo di implementazione graduale dopo la data di fine supporto. Dopo l’aggiornamento automatico del piano di controllo, è necessario aggiornare manualmente i componenti aggiuntivi del cluster e i nodi Amazon EC2. Per ulteriori informazioni, consulta [Aggiornamento del cluster esistente alla nuova versione di Kubernetes](update-cluster.md).
**Allo scadere della data di fine supporto esteso, quando avverrà esattamente l’aggiornamento automatico del piano di controllo?**
Amazon EKS non è in grado di fornire periodi di tempo specifici. Gli aggiornamenti automatici possono avvenire in qualsiasi momento dopo la data di fine supporto esteso. Non riceverai alcuna notifica prima dell’aggiornamento. Consigliamo di aggiornare in modo proattivo il piano di controllo senza fare affidamento sul processo di aggiornamento automatico di Amazon EKS. Per ulteriori informazioni, consulta [Aggiornamento del cluster esistente alla nuova versione di Kubernetes](update-cluster.md).
**Posso lasciare il mio piano di controllo su una versione Kubernetes a tempo indeterminato?**
No. La sicurezza del cloud AWS è la massima priorità. Dopo un certo periodo (di solito 1 anno), la community di Kubernetes interrompe il rilascio di patch per vulnerabilità ed esposizioni (CVE) comuni e sconsiglia il loro invio per le versioni non supportate. Ciò significa che le vulnerabilità specifiche di una versione precedente di Kubernetes potrebbero non essere segnalate, lasciando i cluster esposti senza preavviso e senza opzioni di correzione in caso di vulnerabilità. Pertanto, Amazon EKS non consente ai piani di controllo di rimanere a una versione non più coperta dal supporto esteso.
**È previsto un costo aggiuntivo per ottenere un supporto esteso?**
Sì, sono previsti costi aggiuntivi per i cluster Amazon EKS in esecuzione con il supporto esteso. [Per i dettagli sui prezzi, consulta i prezzi del [supporto esteso di Amazon EKS per la versione Kubernetes sul AWS blog o sulla nostra pagina dei prezzi](https://aws.amazon.com/blogs/containers/amazon-eks-extended-support-for-kubernetes-versions-pricing).](https://aws.amazon.com/eks/pricing/)
**Cosa è incluso nel supporto esteso?**
I cluster Amazon EKS in supporto esteso ricevono patch di sicurezza continue per il piano di controllo di Kubernetes. Inoltre, Amazon EKS rilascerà patch per Amazon VPC CNI, `kube-proxy` e componenti aggiuntivi per le versioni di supporto esteso su CoreDNS. Amazon EKS rilascerà anche patch per AWS Amazon EKS già pubblicato e ottimizzato per AMIs Amazon Linux, Bottlerocket e Windows, oltre ai nodi Amazon EKS Fargate per tali versioni. Tutti i cluster di Extended Support continueranno ad avere accesso al supporto tecnico da AWS.
**Esistono limitazioni alle patch per i componenti non Kubernetes inclusi nel supporto esteso?**
Sebbene Extended Support copra tutti i componenti specifici di Kubernetes AWS, fornirà sempre supporto solo per AWS Amazon EKS pubblicato e ottimizzato per AMIs Amazon Linux, Bottlerocket e Windows. Ciò significa che potresti avere componenti più recenti (come sistema operativo o kernel) sulla tua AMI ottimizzata per Amazon EKS durante l’utilizzo del supporto esteso. Ad esempio, una volta che Amazon Linux 2 raggiungerà la [fine del suo ciclo di vita nel 2025](https://aws.amazon.com/amazon-linux-2/faqs/), Amazon Linux ottimizzato per Amazon EKS AMIs verrà creato utilizzando un sistema operativo Amazon Linux più recente. Amazon EKS annuncerà e documenterà importanti discrepanze nel ciclo di vita del supporto, come questa, per ogni versione di Kubernetes.
**Posso creare nuovi cluster utilizzando una versione con supporto esteso?**
Sì.
# Dai un’occhiata alle note di rilascio per le versioni Kubernetes sul supporto standard
**Suggerimento**
[Registrati](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) ai prossimi workshop Amazon EKS.
Questo argomento fornisce importanti modifiche di cui tenere conto per ogni versione Kubernetes del supporto standard. Durante l’aggiornamento, esamina attentamente le modifiche apportate tra la vecchia e la nuova versione del cluster.
## Kubernetes 1.35
Kubernetes `1.35` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.35`, consulta l’[official release announcement](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/).
**Importante**
Supporto per Cgroup v1 rimosso: Kubernetes 1.35 depreca il supporto cgroup v1, il che significa che il kubelet si rifiuterà di avviarsi per impostazione predefinita sui nodi che utilizzano cgroup v1.
AL2023: utilizza cgroup AL2023 v2 per impostazione predefinita e si allinea al comportamento upstream di Kubernetes.
Azione richiesta: i clienti che hanno configurato manualmente l'uso di cgroup v1 devono AL2023 [migrare](https://kubernetes.io/docs/concepts/architecture/cgroups/) a cgroups v2 o impostarli manualmente nella configurazione kubelet. `failCgroupV1: false`
Bottlerocket: Bottlerocket 1.35 utilizza cgroup v2 per impostazione predefinita, tuttavia imposta la configurazione kubelet, mantenendo la compatibilità con le versioni precedenti. `failCgroupV1: false`
Fargate: Fargate continua a utilizzare cgroup v1.
Containerd 1.x End of Support: Kubernetes 1.35 è l'ultima versione che supporta containerd 1.x. È necessario passare a containerd 2.0 o versione successiva prima di eseguire l'aggiornamento alla versione successiva di Kubernetes.
A marzo 2026, il progetto upstream Kubernetes ritirerà Ingress NGINX, un componente dell'infrastruttura fondamentale per molti ambienti Kubernetes.
Azione richiesta: i clienti EKS devono valutare se si affidano a Ingress NGINX e iniziare a pianificare la migrazione verso alternative come l'API Gateway o i controller Ingress di terze parti, poiché non ci saranno ulteriori versioni per correzioni di bug, patch di sicurezza o aggiornamenti dopo il ritiro. Le implementazioni esistenti continueranno a funzionare, ma rimanere con Ingress NGINX dopo il pensionamento rende l'ambiente vulnerabile ai rischi per la sicurezza, poiché nessuna delle alternative disponibili è sostitutiva diretta e richiederà tempi di pianificazione e progettazione. [Per ulteriori informazioni su questo annuncio di Kubernetes, consulta la dichiarazione ufficiale del Kubernetes Steering and Security Response Committee Ingress NGINX Retirement.](https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/)
+ **In-Place Pod Resource Updates (Stable):** In-Place Pod Resource Updates consente agli utenti di regolare le risorse della CPU e della memoria senza riavviare Pod o contenitori. In precedenza, tali modifiche richiedevano la ricreazione dei Pod, che potevano interrompere i carichi di lavoro, in particolare per le applicazioni con stato o in batch. La nuova funzionalità in loco consente una scalabilità verticale più fluida e senza interruzioni, migliora l'efficienza e può anche semplificare lo sviluppo.
+ *Per ulteriori informazioni, consulta [Kubernetes 1.35: In-Place Pod Resize Graduates to Stable sul blog di Kubernetes](https://kubernetes.io/blog/2025/12/19/kubernetes-v1-35-in-place-pod-resize-ga/).*
+ **PreferSameNode Distribuzione del traffico (stabile):** il `trafficDistribution` campo Servizi è stato aggiornato per fornire un controllo più esplicito sul routing del traffico. È stata introdotta una nuova opzione per consentire ai servizi di assegnare una priorità rigorosa agli endpoint sul nodo locale quando disponibili, altrimenti ricorrendo agli endpoint remoti. `PreferSameNode` Questa modifica rende l'API più esplicita sulla preferenza del traffico all'interno del nodo corrente.
+ **StatefulSet MaxUnavailable (Beta):** questa funzionalità abilita gli aggiornamenti paralleli dei Pod tramite impostazioni `maxUnavailable` (ad esempio, 3 o 10%), consentendo alle applicazioni stateful come i cluster di database di aggiornarsi fino al 60% più velocemente rispetto agli one-at-a-time aggiornamenti sequenziali, riducendo significativamente le finestre di manutenzione.
+ **Supporto per Windows Server 2025:** EKS 1.35 aggiunge il supporto per [Windows Server](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) 2025.
+ **Rimozione della bandiera Kubelet: la `--pod-infra-container-image` bandiera** è stata rimossa da Kubelet. Gli utenti AMI personalizzati devono rimuovere questo flag dalla configurazione di Kubelet prima di eseguire l'aggiornamento alla 1.35.
+ **Avviso di deprecazione - Modalità IPVS: la modalità IPVS** in kube-proxy è obsoleta e verrà rimossa in Kubernetes 1.36.
Per il `1.35` changelog completo https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG di Kubernetes, vedi -1.35.md
## Kubernetes 1.34
Kubernetes `1.34` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.34`, consulta l’[official release announcement](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/).
**Importante**
Containerd è stato aggiornato alla 2.1 nella versione 1.34 per il lancio.
In caso di problemi dopo l'aggiornamento, consulta le note di rilascio di [containerd 2.1.](https://github.com/containerd/containerd/releases/tag/v2.1.0)
AWS non rilascia un'AMI Amazon Linux 2 ottimizzata per EKS per Kubernetes 1.34.
AWS ti incoraggia a migrare ad Amazon Linux 2023. Informazioni su come [Aggiornamento da Amazon Linux 2 ad Amazon Linux 2023](al2023.md).
Per ulteriori informazioni, consulta [Deprecazione dell’AMI Amazon Linux 2](#al2-ami-deprecation).
AppArmor è obsoleto in Kubernetes 1.34.
[https://kubernetes.io/docs/tutorials/security/seccomp/](https://kubernetes.io/docs/tutorials/security/seccomp/)
VolumeAttributesClass (VAC) si laurea in GA con Kubernetes 1.34, passando dall'API beta () all'API stabile (). `storage.k8s.io/v1beta1` `storage.k8s.io/v1`
Se utilizzi il driver CSI EBS con contenitori sidecar AWS gestiti (da [CSI Components](https://gallery.ecr.aws/csi-components) nella galleria ECR), la modifica del volume continuerà a funzionare senza problemi sui cluster EKS 1.31-1.33. AWS applicherà una patch ai sidecar per supportare la versione beta di VAC APIs fino alla fine del supporto standard EKS 1.33 (29 luglio 2026).
Se gestisci autonomamente i contenitori sidecar CSI, potrebbe essere necessario aggiungerli a versioni sidecar precedenti su cluster precedenti alla 1.34 per mantenere la funzionalità VAC.
Per utilizzare le VolumeAttributesClass funzionalità GA (come il rollback delle modifiche), esegui l'aggiornamento a EKS 1.34 o versione successiva.
JWT Signer for Service Account Tokens esterno viene promosso alla versione Beta. Quando si utilizzano firmatari esterni, il flag -- service-account-extend-token -expiation non viene più rispettato completamente. Il server API impone la scadenza minima tra l'estensione desiderata (1 anno) e il limite del firmatario esterno (24 ore).
Ti consigliamo di utilizzare [token di account di servizio vincolati](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens), che vengono montati e ruotati automaticamente da Kubernetes.
+ **Dynamic Resource Allocation (DRA) Core APIs (GA):** la Dynamic Resource Allocation è diventata stabile e consente una gestione efficiente dell'hardware specializzato, ad esempio GPUs attraverso interfacce di allocazione standardizzate, semplificando la gestione delle risorse per gli acceleratori hardware e migliorando l'utilizzo di risorse specializzate.
+ **Projected ServiceAccount Tokens for Kubelet (Beta):** questo miglioramento migliora la sicurezza utilizzando credenziali di breve durata per l'estrazione delle immagini dei container anziché segreti di lunga durata, riducendo il rischio di esposizione delle credenziali e rafforzando il livello di sicurezza generale dei cluster.
+ **Richieste e limiti di risorse a livello di POD (Beta):** questa funzionalità semplifica la gestione delle risorse consentendo pool di risorse condivisi per pod multi-container, consentendo un'allocazione e un utilizzo più efficienti delle risorse per applicazioni complesse con più contenitori.
+ **Mutable CSI Node Allocatable Count (Beta):** Il `MutableCSINodeAllocatableCount` feature gate è abilitato di default in EKS 1.34, rendendo mutabile l'attributo CSINode max attachable volume count e introducendo un meccanismo per aggiornarlo dinamicamente in base alla configurazione utente a livello di driver CSI. Questi aggiornamenti possono essere attivati da intervalli periodici o dal rilevamento degli errori, migliorando l'affidabilità dello stateful pod scheduling risolvendo le discrepanze tra la capacità degli allegati riportata e quella effettiva sui nodi.
+ *Per ulteriori informazioni, consulta [Kubernetes v1.34: Mutable CSI Node Allocatable Count sul blog di Kubernetes](https://kubernetes.io/blog/2025/09/11/kubernetes-v1-34-mutable-csi-node-allocatable-count/).*
+ Avviso **di deprecazione - configurazione del driver cgroup: la configurazione manuale del driver cgroup** è obsoleta a favore del rilevamento automatico.
+ **Impatto sul cliente:** se attualmente imposti il `--cgroup-driver` flag manualmente nella configurazione di kubelet, dovresti prepararti a rimuovere questa configurazione.
+ **Azione richiesta:** pianifica di aggiornare gli script di bootstrap dei nodi e le configurazioni AMI personalizzate per rimuovere le impostazioni manuali dei driver cgroup prima che la funzionalità venga rimossa in una futura versione di Kubernetes.
+ [Per ulteriori informazioni, consulta la documentazione del driver cgroup.](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
Per il changelog completo di Kubernetes`1.34`, consulta -1.34.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.33
Kubernetes `1.33` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.33`, consulta l’[official release announcement](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/).
**Importante**
L’API Kubernetes *beta* dell’allocazione dinamica delle risorse è abilitata.
Questa API beta migliora l'esperienza di pianificazione e monitoraggio dei carichi di lavoro che richiedono risorse come. GPUs
L’API beta è definita dalla community Kubernetes e potrebbe cambiare nelle versioni future.
Esamina attentamente [le fasi relative alle funzionalità](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages) nella documentazione di Kubernetes per comprendere le implicazioni dell'utilizzo della versione beta. APIs
AWS non rilascia un'AMI Amazon Linux 2 ottimizzata per EKS per Kubernetes 1.33.
AWS ti incoraggia a migrare ad Amazon Linux 2023. Informazioni su come [Aggiornamento da Amazon Linux 2 ad Amazon Linux 2023](al2023.md).
Per ulteriori informazioni, consulta [Deprecazione dell’AMI Amazon Linux 2](#al2-ami-deprecation).
+ **Ridimensionamento locale delle risorse pod (Beta):** il ridimensionamento locale delle risorse è stato promosso alla versione beta e consente aggiornamenti dinamici della CPU e delle risorse di memoria per i Pod esistenti senza riavvii, permettendo il dimensionamento verticale dei carichi di lavoro stateful con zero tempi di inattività e regolazioni delle risorse senza interruzioni in base ai modelli di traffico.
+ **Container sidecar ora stabili:** i container sidecar sono diventati stabili, implementando i sidecar come container init speciali con `restartPolicy: Always` che iniziano prima dei container applicativi, funzionano per tutto il ciclo di vita dei pod e supportano le sonde per la segnalazione dello stato operativo.
+ Per ulteriori informazioni, consulta [Sidecar Containers](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) nella *documentazione Kubernetes*.
+ **Deprecazione dell'API degli endpoint:** l'API Endpoints è ora ufficialmente obsoleta e restituirà avvisi quando vi si accede: migra invece carichi di lavoro e script per utilizzare l' EndpointSlices API, che supporta funzionalità moderne come la rete dual-stack e ne gestisce più di uno per servizio. EndpointSlices
+ [https://kubernetes.io/blog/2025/04/24/endpoints-deprecation/](https://kubernetes.io/blog/2025/04/24/endpoints-deprecation/)
+ **Supporto di Elastic Fabric Adapter:** il gruppo di sicurezza predefinito per i cluster Amazon EKS ora supporta il traffico Elastic Fabric Adapter (EFA). Il gruppo di sicurezza predefinito ha una nuova regola in uscita che consente il traffico di EFA con la destinazione dello stesso gruppo di sicurezza. Questo consente il traffico EFA all’interno del cluster.
+ Per ulteriori informazioni, consulta [Elastic Fabric Adapter per AI/ML carichi di lavoro HPC su Amazon EC2 nella Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) Elastic Compute Cloud User Guide.
Per il changelog completo di `1.33` Kubernetes, consulta -1.33.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.32
Kubernetes `1.32` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.32`, consulta l’[official release announcement](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/).
**Importante**
La versione `flowcontrol.apiserver.k8s.io/v1beta3` API di FlowSchema ed PriorityLevelConfiguration è stata rimossa nella versione attuale. `1.32` Se li utilizzi APIs, devi aggiornare le configurazioni per utilizzare l'ultima versione supportata prima dell'aggiornamento.
ServiceAccount `metadata.annotations[kubernetes.io/enforce-mountable-secrets]`è stata obsoleta nella versione `1.32` e verrà rimossa in una futura versione secondaria di Kubernetes. Si consiglia di utilizzare namespace separati per isolare l’accesso ai segreti montati.
La versione Kubernetes `1.32` è l'ultima versione per la quale Amazon EKS rilascerà Amazon Linux 2 (). AL2 AMIs A `1.33` partire dalla versione, Amazon EKS continuerà a rilasciare Amazon Linux 2023 (AL2023) e basato su Bottlerocket. AMIs
+ La funzionalità Memory Manager è passata allo stato di disponibilità generale (GA) nella versione Kubernetes `1.32`. Questo miglioramento offre un’allocazione della memoria più efficiente e prevedibile per le applicazioni containerizzate, particolarmente utile per carichi di lavoro con requisiti di memoria specifici.
+ PersistentVolumeClaims (PVCs) StatefulSets finora creati includono funzionalità di pulizia automatica. Quando non PVCs sono più necessari, verranno eliminati automaticamente mantenendo la persistenza dei dati durante StatefulSet gli aggiornamenti e le operazioni di manutenzione dei nodi. Questa funzionalità semplifica la gestione dello storage e aiuta a evitare che rimangano orfani PVCs nel cluster.
+ È stata introdotta la funzionalità Custom Resource Field Selector, che consente agli sviluppatori di aggiungere selettori di campo alle risorse personalizzate. Questa funzionalità offre le stesse funzionalità di filtraggio disponibili per gli oggetti Kubernetes integrati nelle risorse personalizzate, consentendo un filtraggio delle risorse più preciso ed efficiente e promuovendo migliori pratiche di progettazione delle API.
Per il changelog completo di `1.32` Kubernetes, vedi -1.32.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
### Modifiche dell’autenticazione anonima
A partire da Amazon EKS `1.32`, l’autenticazione anonima è limitata ai seguenti endpoint di controllo dell’integrità del server API:
+ `/healthz`
+ `/livez`
+ `/readyz`
Le richieste a qualsiasi altro endpoint che utilizza l’utente `system:unauthenticated` riceveranno una risposta HTTP `401 Unauthorized`. Questo miglioramento della sicurezza aiuta a prevenire l’accesso involontario al cluster che potrebbe verificarsi a causa di policy RBAC non configurate correttamente.
**Nota**
Il ruolo RBAC `public-info-viewer` continua a valere per gli endpoint di controllo dell’integrità sopra elencati.
### Deprecazione dell’AMI Amazon Linux 2
La versione Kubernetes `1.32` è l'ultima versione rilasciata da Amazon EKS. AL2 AMIs Dalla versione `1.33` in poi, Amazon EKS continuerà a essere rilasciato AL2023 e sarà basato su Bottlerocket. AMIs Per ulteriori informazioni, consulta [Guida a EKS AL2 e funzionalità AL2 di transizione accelerata AMIs](eks-ami-deprecation-faqs.md).
# Dai un’occhiata alle note di rilascio per le versioni Kubernetes sul supporto esteso
Amazon EKS supporta le versioni di Kubernetes più a lungo di quelle upstream, con supporto standard per le versioni secondarie di Kubernetes per 14 mesi dal momento in cui vengono rilasciate in Amazon EKS e supporto esteso per le versioni secondarie di Kubernetes per altri 12 mesi di supporto (26 mesi totali per versione).
Questo argomento fornisce importanti modifiche di cui tenere conto per ogni versione di Kubernetes del supporto esteso. Durante l'aggiornamento, esamina attentamente le modifiche apportate tra la vecchia e la nuova versione del cluster.
## Kubernetes 1.31
Kubernetes `1.31` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.31`, consulta l’[official release announcement](https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/).
**Importante**
Il flag kubelet `--keep-terminated-pod-volumes` obsoleto dal 2017 è stato rimosso come parte del rilascio della versione `1.31`. Questa modifica influisce sul modo in cui i volumi dei pod terminati vengono gestiti da kubelet. Se si utilizza questo flag nelle configurazioni dei nodi, è necessario aggiornare gli script di bootstrap e avviare i modelli per rimuoverlo prima dell’aggiornamento.
+ La funzionalità di controllo `VolumeAttributesClass` beta e la risorsa API sono abilitati nella versione Amazon EKS `1.31`. Questa funzionalità consente agli operatori del cluster di modificare le proprietà mutabili di Persistent Volumes (PVs) gestiti da driver CSI compatibili, incluso il driver CSI di Amazon EBS. Per sfruttare questa funzionalità, assicurati che il driver CSI supporti la funzionalità `VolumeAttributesClass` (per il driver CSI di Amazon EBS, esegui l’upgrade alla versione `1.35.0` o successiva per abilitarla automaticamente). Sarai in grado di creare `VolumeAttributesClass` oggetti per definire gli attributi di volume desiderati, come il tipo di volume e la velocità effettiva, e associarli ai tuoi Persistent Volume Claims (). PVCs Per ulteriori informazioni, consulta [official Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/) e la documentazione del driver CSI.
+ Per ulteriori informazioni sul Driver CSI di Amazon EBS, consulta [Utilizzare il volume di archiviazione Kubernetes con Amazon EBS](ebs-csi.md).
+ Il supporto di Kubernetes per [AppArmor](https://apparmor.net/)è diventato stabile ed è ora generalmente disponibile per l'uso pubblico. Questa funzionalità consente di proteggere i contenitori AppArmor impostando il `appArmorProfile.type` campo all'interno del contenitore. `securityContext` Prima della versione Kubernetes`1.30`, AppArmor era controllato da annotazioni. A partire dalla versione `1.30`, è controllato tramite campi. Per sfruttare questa funzionalità, consigliamo di abbandonare le annotazioni e utilizzare il campo `appArmorProfile.type` per garantire la compatibilità dei carichi di lavoro.
+ La funzionalità del tempo di transizione dell' PersistentVolume ultima fase è diventata stabile ed è ora generalmente disponibile per l'uso pubblico nella versione Kubernetes. `1.31` Questa funzionalità introduce un nuovo campo, in `.status.lastTransitionTime` PersistentVolumeStatus, che fornisce un timestamp di quando un' PersistentVolume ultima è passata a una fase diversa. Questo miglioramento consente un migliore monitoraggio e gestione di PersistentVolumes, in particolare in scenari in cui è importante comprendere il ciclo di vita dei volumi.
Per il changelog completo di `1.31` Kubernetes, vedi -1.31.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.30
Kubernetes `1.30` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.30`, consulta l’[official release announcement](https://kubernetes.io/blog/2024/04/17/kubernetes-v1-30-release/).
+ A partire dalla versione Amazon EKS `1.30` o successiva, qualsiasi gruppo di nodi gestiti appena creato utilizzerà automaticamente Amazon Linux 2023 (AL2023) come sistema operativo del nodo. Per ulteriori informazioni sulla specificazione del sistema operativo per un gruppo di nodi gestito, consulta [Creare un gruppo di nodi gestiti per il cluster](create-managed-node-group.md).
+ Con Amazon EKS `1.30`, viene aggiunta l’etichetta `topology.k8s.aws/zone-id` ai nodi worker. Puoi utilizzare Availability Zone IDs (AZ IDs) per determinare la posizione delle risorse in un account rispetto alle risorse di un altro account. Per ulteriori informazioni, consulta [la sezione Zona di disponibilità IDs per le AWS risorse disponibili](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) nella * AWS RAM User Guide*.
+ A partire da `1.30`, Amazon EKS non include più l’annotazione `default` sulla risorsa `gp2 StorageClass` applicata ai cluster appena creati. Questo non ha alcun impatto se si utilizza il nome come riferimento a questa classe di archiviazione. Devi agire se facevi affidamento sulla presenza di un `StorageClass` predefinito nel cluster. Dovresti fare riferimento a `StorageClass` con il nome `gp2`. In alternativa, è possibile distribuire la classe di archiviazione predefinita consigliata da Amazon EBS impostando il parametro `defaultStorageClass.enabled` su true durante l’installazione della versione `1.31.0` o successiva di `aws-ebs-csi-driver add-on`.
+ La policy IAM minima richiesta per il ruolo IAM del cluster Amazon EKS è cambiata. L’azione `ec2:DescribeAvailabilityZones` è obbligatoria. Per ulteriori informazioni, consulta [Ruolo IAM del cluster Amazon EKS](cluster-iam-role.md).
Per il `1.30` changelog completo di Kubernetes, vedi -1.30.md. https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.29
Kubernetes `1.29` è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes `1.29`, consulta l’[official release announcement](https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/).
**Importante**
La versione API `flowcontrol.apiserver.k8s.io/v1beta2` obsoleta di `FlowSchema` e `PriorityLevelConfiguration` non è più disponibile nella versione `1.29` di Kubernetes. Se disponi di manifesti o di un software client che utilizza il gruppo di API beta obsoleto, devi modificarli prima di eseguire l’aggiornamento alla versione `1.29`.
+ Ora il campo `.status.kubeProxyVersion` per gli oggetti del nodo è obsoleto e il progetto Kubernetes propone di rimuovere quel campo in future versioni. Il campo obsoleto non è preciso ed è stato sempre gestito da `kubelet`, che in realtà non conosce la versione `kube-proxy` e nemmeno se `kube-proxy` è in esecuzione. Se hai utilizzato questo campo nel software client, non farlo più: le informazioni non sono affidabili e il campo è ora obsoleto.
+ In Kubernetes `1.29`, per ridurre la potenziale superficie di attacco, la funzionalità `LegacyServiceAccountTokenCleanUp` etichetta i token basati sui segreti generati automaticamente come non validi se non sono stati utilizzati per un lungo periodo (1 anno per impostazione predefinita) e li rimuove automaticamente se non si tenta di utilizzarli per un lungo periodo dopo essere stati contrassegnati come non validi (1 anno aggiuntivo per impostazione predefinita). Per identificare tali token, puoi eseguire:
```
kubectl get cm kube-apiserver-legacy-service-account-token-tracking -n kube-system
```
Per il changelog completo di `1.29` Kubernetes, vedi -1.29.md\$1 1280. https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG changelog-since-v
# Visualizzazione del periodo di supporto del cluster corrente
La sezione relativa al **periodo di supporto per i cluster** della console AWS indica se per il cluster è *attualmente* su un supporto standard o esteso. Se il periodo di supporto del cluster è **Supporto esteso**, ti sarà addebitato il costo del supporto esteso EKS.
Per ulteriori informazioni sul supporto standard ed esteso, consulta [Comprendere il ciclo di vita delle versioni di Kubernetes su EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Vai alla pagina **Cluster** nella sezione EKS della console AWS. Verifica che la console sia impostata sulla stessa regione AWS del cluster che desideri esaminare.
1. Esamina la colonna **Periodo di supporto**. Se il valore è **Supporto standard fino a...**, al momento non ti è addebitato alcun costo per il supporto esteso. Rientri nel periodo di supporto standard. Se il valore è **Supporto esteso...**, al momento a questo cluster è addebitato il costo del supporto esteso.
**Nota**
Il **periodo di supporto** non può essere recuperato con AWS API o CLI.
# Visualizzazione della corrente policy di aggiornamento del cluster
La **policy di aggiornamento del cluster** determina cosa succede al cluster quando esce dal periodo di supporto standard. Se la policy di aggiornamento è `EXTENDED`, il cluster non sarà aggiornato automaticamente ed entrerà il supporto esteso. Se la tua policy di aggiornamento è `STANDARD`, sarà aggiornata automaticamente.
La policy di controllo della versione Kubernetes di Amazon EKS ti consente di scegliere la fine del comportamento di supporto standard per i tuoi cluster EKS. Con questi controlli è possibile decidere quali cluster debbano essere sottoposti al supporto esteso e quali aggiornati automaticamente alla fine del supporto standard per una versione di Kubernetes.
Una versione secondaria è supportata come standard in Amazon EKS per i primi 14 mesi dopo il rilascio. Una volta superata la data di fine del supporto standard, la versione passa al supporto esteso per i 12 mesi successivi. Il supporto esteso consente di mantenere una versione Kubernetes specifica di più a lungo a un costo aggiuntivo per ora del cluster. È possibile abilitare o disabilitare il supporto esteso per un cluster EKS. Se disabiliti il supporto esteso, AWS sarà automaticamente aggiornato alla versione successiva di Kubernetes al termine del supporto standard. Se abiliti il supporto esteso, è possibile mantenere la versione corrente a un costo aggiuntivo per un periodo di tempo limitato. Pianifica di aggiornare regolarmente il tuo cluster Kubernetes, anche se utilizzi il supporto esteso.
È possibile impostare la policy della versione sia per i cluster nuovi che per quelli esistenti, utilizzando la proprietà `supportType`. Esistono due opzioni che possono essere utilizzate per impostare la policy di supporto della versione:
+ ` STANDARD `: il tuo cluster EKS è idoneo all’aggiornamento automatico al termine del supporto standard. Questa impostazione non comporta costi di assistenza estesa, ma il cluster EKS eseguirà automaticamente l’aggiornamento alla successiva versione di Kubernetes supportata con supporto standard.
+ ` EXTENDED `: il tuo cluster EKS entrerà in supporto esteso una volta che la versione Kubernetes raggiungerà la fine del supporto standard. Con questa impostazione ti saranno addebitati costi di supporto estesi. È possibile aggiornare il tuo cluster a una versione Kubernetes standard supportata per evitare di incorrere in costi di supporto esteso. I cluster che utilizzano il supporto esteso saranno idonei all’aggiornamento automatico al termine del supporto esteso.
Il supporto esteso è abilitato per impostazione predefinita per i nuovi cluster e per i cluster esistenti. È possibile verificare se il supporto esteso è abilitato per un cluster in Console di gestione AWS o utilizzando AWS CLI.
**Importante**
Se desideri che il cluster mantenga la versione corrente di Kubernetes per sfruttare il periodo di supporto esteso, è necessario abilitare il supporto esteso nella policy di aggiornamento prima della fine del periodo di supporto standard.
È possibile impostare la policy di supporto della versione per i cluster solo mentre è in esecuzione sulla versione Kubernetes nel supporto standard. Una volta che la versione entrerà nel supporto esteso, non potrai modificare questa impostazione finché non utilizzerai una versione con supporto standard.
Ad esempio, se hai impostato la policy di supporto della versione come `standard`, non potrai modificare questa impostazione dopo che la versione di Kubernetes in esecuzione sul cluster avrà raggiunto la fine del supporto standard. Se hai impostato la policy di supporto della versione come `extended`, non potrai modificare questa impostazione dopo che la versione di Kubernetes in esecuzione sul cluster avrà raggiunto la fine del supporto standard. Per modificare l’impostazione della politica di supporto delle versioni, il cluster deve essere in esecuzione su una versione di Kubernetes supportata in modo standard.
## Visualizzare la policy di aggiornamento del cluster (Console AWS)
1. Vai alla pagina **Cluster** nella sezione EKS della console AWS. Verifica che la console sia impostata sulla stessa regione AWS del cluster che desideri esaminare.
1. Esamina la colonna **Policy di aggiornamento**. Se il valore è **Supporto standard**, il cluster non accederà al supporto esteso. Se il valore è **Supporto esteso**, il cluster entrerà nel supporto esteso.
## Visualizzare la policy di aggiornamento del cluster (AWS CLI)
1. Verifica che AWS CLI sia installata e di aver effettuato l’accesso. [Informazioni su come aggiornare e installare AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
1. Determina il nome del cluster EKS. Imposta CLI sulla stessa regione AWS del cluster EKS.
1. Esegui il comando seguente:
```
aws eks describe-cluster \
--name \
--query "cluster.upgradePolicy.supportType"
```
1. Se il valore è `STANDARD`, il tuo cluster non accederà al supporto esteso. Se il valore è `EXTENDED`, il cluster accederà al supporto esteso.
# Aggiungere flessibilità per pianificare gli aggiornamenti delle versioni di Kubernetes abilitando il supporto esteso EKS
Questo argomento descrive come configurare la *policy di aggiornamento* di un cluster EKS per abilitare il supporto esteso. La policy di aggiornamento di un cluster EKS determina cosa succede quando un cluster raggiunge la fine del *periodo di supporto* standard. Se una policy di aggiornamento ha il supporto esteso abilitato, alla fine del periodo di supporto standard il cluster entrerà nel periodo di supporto esteso. Alla fine del periodo di supporto standard, il cluster non verrà aggiornato automaticamente.
Vengono addebitati costi più alti per i cluster che si trovano effettivamente nel *periodo di supporto esteso*. Se la policy di aggiornamento per è solamente configurata per abilitare il supporto esteso, ma il cluster associato si trova nel *periodo di supporto standard*, vengono addebitati i costi standard.
Se si crea un cluster nella Console AWS, la policy di aggiornamento associata sarà configurata per disabilitare il supporto esteso. Se si crea un cluster con un’altra modalità, la policy di aggiornamento associata sarà configurata per abilitare il supporto esteso. Ad esempio, per i cluster creati con l’API AWS è abilitato il supporto esteso.
Per ulteriori informazioni sulle policy di aggiornamento, consultare la pagina [Cluster upgrade policy](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html).
**Importante**
Se si desidera che il cluster mantenga la versione corrente di Kubernetes per sfruttare il periodo di supporto esteso, è necessario abilitare il supporto esteso nella policy di aggiornamento prima della fine del periodo di supporto standard.
Se il supporto esteso non viene abilitato, il cluster verrà aggiornato automaticamente.
## Abilitare il supporto esteso EKS (Console AWS)
1. Accedere al cluster EKS nella Console AWS. Selezionare la scheda **Panoramica** nella pagina **Informazioni sul cluster**.
1. Nella sezione **Impostazioni della versione di Kubernetes**, selezionare **Gestisci**.
1. Selezionare **Supporto esteso**, poi **Salva modifiche**.
## Abilitare il supporto esteso EKS (AWS CLI)
1. Verificare che AWS CLI sia installata e di aver effettuato l’accesso. [Informazioni su come aggiornare e installare AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
1. Determinare il nome del cluster EKS.
1. Esegui il comando seguente:
```
aws eks update-cluster-config \
--name \
--upgrade-policy supportType=EXTENDED
```
# Prevenire l’aumento del costo dei cluster disabilitando il supporto esteso EKS
Questo argomento descrive come configurare la *policy di aggiornamento* di un cluster EKS per disabilitare il supporto esteso. La policy di aggiornamento di un cluster EKS determina cosa succede quando un cluster raggiunge la fine del *periodo di supporto* standard. Se la policy di aggiornamento di un cluster ha il supporto esteso disabilitato, verrà automaticamente aggiornato alla versione successiva di Kubernetes.
Per ulteriori informazioni sulle policy di aggiornamento, consultare la pagina [Cluster upgrade policy](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html).
**Importante**
Non è possibile disabilitare il supporto esteso una volta che il cluster vi è entrato. È possibile disabilitare il supporto esteso per i cluster solo durante il supporto standard.
AWS consiglia di aggiornare il cluster a una versione valida per il periodo di supporto standard.
## Disabilitare il supporto esteso EKS (Console AWS)
1. Accedere al cluster EKS nella Console AWS. Selezionare la scheda **Panoramica** nella pagina **Informazioni sul cluster**.
1. Nella sezione **Impostazione della versione di Kubernetes**, selezionare **Gestisci**.
1. Selezionare **Supporto standard**, poi **Salva modifiche**.
## Disabilitare il supporto esteso EKS (AWS CLI)
1. Verificare che AWS CLI sia installata e di aver effettuato l’accesso. [Informazioni su come aggiornare e installare AWS CLI.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
1. Determinare il nome del cluster EKS.
1. Esegui il comando seguente:
```
aws eks update-cluster-config \
--name \
--upgrade-policy supportType=STANDARD
```