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à.
Dai un’occhiata alle note di rilascio per le versioni Kubernetes sul supporto standard
Suggerimento
Registrati
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.37
Kubernetes 1.37 è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes 1.37, consulta l’official release announcement
Importante
-
SELinux Mount Labeling Enabled by Default (GA): in Kubernetes 1.37, la funzionalità è abilitata per impostazione predefinita.
SELinuxMountQuando viene impostato un PodseLinuxOptionse viene impostato il driver CSI del relativo volumeseLinuxMount: true, il kubelet monta il volume con invece di rietichettare tutti i file.mount -o context=<label>Un mount può contenere solo un'etichetta SELinux, quindi un Pod rimane attivoContainerCreatingse un altro Pod sullo stesso nodo utilizza già lo stesso volume con un'etichetta SELinux diversa, un livello di privilegio diverso o diverso.seLinuxChangePolicyI nodi senza SELinux abilitato non sono interessati.-
Azione richiesta: prima dell'aggiornamento, corri
kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMounta cercare i driver con.seLinuxMount: truePer i volumi generati da questi driver, trova i Pod che impostanoseLinuxOptionse condividono un volume. I pod che condividono lo stesso volume devono utilizzare lo stessoseLinuxOptions.levele.seLinuxChangePolicySe un Pod con privilegi e un Pod non privilegiato condividono lo stesso volume, impostalospec.securityContext.seLinuxChangePolicy: Recursivesul Pod senza privilegi.Recursivemantiene il precedente comportamento di rietichettatura; applicalo a tutti i Pod che condividono il volume. Per maggiori informazioni, vedi SELinux Volume Label Changes goes GA (e probabili implicazioni nella v1.37) e.KEP-1710
-
-
EKS Auto Mode Consolidation Default: a partire da Kubernetes 1.37, nuova EKS Auto Mode che non specifica l'impostazione predefinita su invece di. NodePools
consolidationPolicyBalancedWhenEmptyOrUnderutilizedBalancedin genere si traduce in un minor numero di sfratti dei Pod all'incirca allo stesso costo.systemNodePools Sono integratigeneral-purposee utilizzatiBalanced, e non è possibile modificare questa impostazione su di essi. Per i dettagli, consulta le note sulla versione di EKS Auto Mode.-
Azione richiesta: per mantenere un comportamento di consolidamento specifico, impostalo in
consolidationPolicymodo esplicito e personalizzato. NodePools Se un carico di lavoro richiede il comportamento precedente, scegli come target un NodePool set.consolidationPolicy: WhenEmptyOrUnderutilized
-
-
Dynamic Resource Allocation (DRA) Device Taints and Tolerations (Stable): i driver DRA e gli amministratori di cluster possono contaminare i dispositivi, come le GPU, in modo che lo scheduler non li allochi a pod che non tollerano la contaminazione. L'uso di DRA su EKS richiede l'installazione di un driver DRA, che EKS non installa. Il driver NVIDIA DRA è supportato con la capacità statica di Karpenter, i gruppi di nodi gestiti da EKS e i nodi autogestiti. Non è supportato con la modalità EKS Auto. Con EKS Auto Mode, o Karpenter dynamic capacity provisioning, usa il plug-in del dispositivo NVIDIA.
-
Quando crei un
DeviceTaintRule, imposta sempre.spec.deviceSelectorPer scegliere come target tutti i dispositivi, usadeviceSelector: {}. Per ulteriori informazioni, consulta Utilizzare il driver o il plug-in del dispositivo NVIDIA DRA su Amazon EKS.
-
-
Horizontal Pod Autoscaler Configurable Tolerance (Stable): puoi impostare una tolleranza per HPA, separatamente per scalare verso l'alto e verso il basso, invece di fare affidamento solo sul valore predefinito del 10% a livello di cluster.
-
Horizontal Pod Autoscaler Scale to Zero (Beta): il feature gate è abilitato per impostazione predefinita in Kubernetes 1.37.
HPAScaleToZeroUn HPA scalabile in base a metriche Object o External può essere impostato in modo da scalare a zero Pod quando è inattivo edminReplicas: 0eseguire il backup quando la domanda ritorna. Le metriche relative agli oggetti e alle metriche esterne richiedono un adattatore per le metriche, che EKS non installa. -
Modifiche alla configurazione di Kubelet: il kubelet non si avvia più se viene impostato un flag CADvisor obsoleto (eccetto
--housekeeping-interval), elimina le metriche e e viene considerato come uncontainer_cpu_load_average_10slimitecontainer_cpu_load_d_average_10s.container_tasks_stateeventRecordQPS: 0In precedenza veniva applicatoeventRecordQPS: 0un limite di 5 eventi al secondo. EKS-optimized Le AMI non impostano i flag CADvisor obsoletieventRecordQPS, quindi il loro limite di avvio e velocità del kubelet sono invariati. Le metriche rimosse influiscono su chiunque le elabori, su qualsiasi AMI.-
Azione richiesta: se utilizzi AMI personalizzate o argomenti kubelet aggiuntivi, rimuovi i flag CADvisor obsoleti e, se impostati
eventRecordQPS: 0, modificali per mantenere il limite di frequenza precedente.5Aggiorna eventuali dashboard o avvisi che utilizzano le metriche rimosse. Per ulteriori informazioni, consulta il riferimento alla configurazione di kubelet (v1beta1).
-
-
Kubelet registra la sua configurazione all'avvio: Kubelet ora registra la sua configurazione completa effettiva all'avvio. Assicurati che solo gli utenti fidati possano leggere i log dei nodi. Per ulteriori informazioni, vedere kubernetes/kubernetes #139837
. -
Driver NVIDIA 595 per istanze Amazon EC2 G7: le istanze G7 richiedono il driver NVIDIA 595. Le AMI NVIDIA di EKS-optimized Amazon Linux 2023 includono il driver 595 in tutte le versioni supportate; le AMI NVIDIA Bottlerocket lo includono su Kubernetes 1.37 e versioni successive.
Per 1.37 il changelog completo di Kubernetes, consulta https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.37.md
Kubernetes 1.36
Kubernetes 1.36 è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes 1.36, consulta l’official release announcement
Importante
-
Rimozione del volume GitRepo: il tipo di volume è permanentemente disabilitato in
gitRepoKubernetes 1.36 e non può essere riattivato. L'API Kubernetes accetta ancora pod congitRepovolumi, ma kubelet si rifiuterà di eseguirli e restituirà un errore.-
Azione richiesta: esegui la migrazione ai contenitori init
o ai contenitori sidecar git-sync prima di eseguire l'aggiornamento alla 1.36. Per ulteriori informazioni, consulta KEP-5040 .
-
-
SELinux Volume Labeling Changes (GA): in Kubernetes 1.36, l'etichettatura dei volumi SELinux più veloce viene impostata per impostazione predefinita su tutti i volumi, utilizzando invece la rietichettatura ricorsiva dei file.
mount -o contextLa condivisione di un volume sullo stesso nodo tra Pod con privilegi e non privilegiati o tra Pod con etichette SELinux diverse può causare problemi. IlSELinuxMountcomportamento correlato che può contenere un PodContainerCreatingè abilitato di default in Kubernetes 1.37, non in 1.36. Consulta la sezione Kubernetes 1.37 prima dell'aggiornamento.-
Azione richiesta: prima dell'aggiornamento, controlla i cluster che eseguono i SELinux-enabled nodi e assicurati che le etichette dei
seLinuxChangePolicycampi e dei volumi SELinux siano impostate correttamente sui pod che condividono un volume. Per maggiori informazioni, vedi SELinux Volume Label Changes goes GA (e probabili implicazioni nella versione 1.37).
-
-
IP/CIDR Validazione rigorosa abilitata per impostazione predefinita: il
StrictIPCIDRValidationfeature gate è ora abilitato per impostazione predefinita per i tipi di API integrati. I campi API non accettano più valori IP o CIDR con zeri iniziali estranei (ad esempio,010.000.000.005invece di10.0.0.5) o valori CIDR con semantica ambigua (ad esempio, invece di).192.168.0.5/24192.168.0.0/24Gli oggetti archiviati esistenti vengono conservati tramite il ratcheting di convalida, ma le nuove creazioni e gli aggiornamenti verranno rifiutati. Ciò non si applica ai tipi di risorse personalizzati.-
Azione richiesta: controlla i manifesti, i grafici Helm e l'automazione per individuare gli indirizzi IP contenenti zeri iniziali o notazione CIDR non canonica. Aggiornali per utilizzare i formati canonici prima dell'aggiornamento. Per ulteriori informazioni, consulta KEP-4858
.
-
-
User Namespaces (stabile): User Namespaces fornisce una difesa approfondita associando l'utente root di un container a un utente non privilegiato sull'host, assicurando che un breakout del container non conceda alcun potere amministrativo sul nodo.
-
Per ulteriori informazioni, consulta User Namespaces in Kubernetes are finally GA nel blog di Kubernetes. https://kubernetes.io/blog/2026/04/23/kubernetes-v1-36-userns-ga/
-
-
Resource Health Status (Beta): riporta lo stato di salute di ogni dispositivo nello stato Pod, consentendo agli operatori di determinare se un crash loop è dovuto a uno stato del dispositivo non integro o sconosciuto piuttosto che a problemi dell'applicazione. Funziona sia con i plug-in dei dispositivi che con l'allocazione dinamica delle risorse.
-
Per ulteriori informazioni, consulta KEP-4680
.
-
-
Funzionalità di allocazione dinamica delle risorse (beta): diverse funzionalità DRA sono ora abilitate per impostazione predefinita: dispositivi partizionabili e capacità consumabile per una condivisione più granulare di hardware come le GPU e Device Binding Conditions per controlli approfonditi della disponibilità dei dispositivi prima della pianificazione.
-
Per ulteriori informazioni, consulta Kubernetes v1.36: More Drivers, New Features e the Next Era of DRA nel blog di Kubernetes.
-
-
Avviso di deprecazione — Service ExternalIPS: il campo Service è obsoleto in Kubernetes 1.36.
externalIPs.specVisualizzerai avvisi di deprecazione durante la creazione o l'aggiornamento dei servizi che utilizzano questo campo. La rimozione completa è prevista per Kubernetes 1.43. I clienti che lo utilizzanoexternalIPsdevono migrare a LoadBalancer Services o Gateway API. NodePort https://gateway-api.sigs.k8s.io/Per ulteriori informazioni, consulta KEP-5707 .
Per il changelog completo di Kubernetes1.36, consulta https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md
Kubernetes 1.35
Kubernetes 1.35 è ora disponibile in Amazon EKS. Per ulteriori informazioni su Kubernetes 1.35, consulta l’official release announcement
Importante
-
Supporto per Cgroup v1 rimosso: Kubernetes 1.35 depreca il supporto per cgroup v1, il che significa che kubelet si rifiuterà di avviarsi per impostazione predefinita sui nodi che utilizzano cgroup v1.
-
AL2023: AL2023 utilizza cgroup v2 per impostazione predefinita e si allinea al comportamento upstream di Kubernetes.
-
Azione richiesta: i clienti che hanno configurato manualmente AL2023 per utilizzare cgroup v1 devono migrare a cgroups v2 o impostarlo manualmente nella configurazione kubelet. https://kubernetes.io/docs/concepts/architecture/cgroups/
failCgroupV1: false
-
-
Bottlerocket: Bottlerocket 1.35 utilizza cgroup v2 per impostazione predefinita, ma viene impostato nella configurazione kubelet, mantenendo la compatibilità con le versioni precedenti.
failCgroupV1: false -
Fargate: Fargate continua a utilizzare cgroup v1.
-
-
Fine del supporto per Containerd 1.x: Kubernetes 1.35 è l'ultima versione che supporta containerd 1.x. È necessario passare a containerd 2.0 o versioni successive prima di eseguire l'aggiornamento alla versione successiva di Kubernetes.
-
Nel marzo 2026, il progetto Kubernetes upstream ritirerà Ingress NGINX, un componente dell'infrastruttura fondamentale per molti ambienti Kubernetes.
-
Azione necessaria: i clienti EKS dovrebbero 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 ritiro rende l'ambiente vulnerabile ai rischi di sicurezza, poiché nessuna delle alternative disponibili è una sostituzione diretta e richiederà tempo di pianificazione e progettazione. Per ulteriori informazioni su questo annuncio di Kubernetes, consulta la dichiarazione ufficiale del ritiro di Ingress NGINX da Ingress NGINX da Kubernetes Steering and Security Response Committees. https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
-
-
In-Place Pod Resource Updates (stabile): Pod Resource Updates consente agli utenti di regolare le risorse di CPU e memoria senza riavviare In-Place Pod o contenitori. In precedenza, tali modifiche richiedevano la ricreazione dei Pod, il che poteva interrompere i carichi di lavoro, in particolare per le applicazioni stateful o batch. La nuova funzionalità in-place consente un ridimensionamento verticale più fluido 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.
-
-
PreferSameNode Distribuzione del traffico (stabile): il
trafficDistributioncampo Servizi è stato aggiornato per fornire un controllo più esplicito sull'instradamento del traffico. È stata introdotta una nuova opzionePreferSameNode,, per consentire ai servizi di assegnare una priorità rigorosa agli endpoint sul nodo locale quando disponibile, ricorrendo altrimenti agli endpoint remoti. Questa modifica rende l'API più esplicita sulla preferenza del traffico all'interno del nodo corrente. -
StatefulSet MaxUnavailable (Beta): questa funzionalità consente gli aggiornamenti paralleli dei Pod impostando
maxUnavailable(ad esempio, 3 o 10%), consentendo alle applicazioni stateful come i cluster di database di aggiornarsi fino al 60% più velocemente rispetto agli aggiornamenti sequenziali uno alla volta, riducendo significativamente le finestre di manutenzione. -
Supporto per Windows Server 2025: EKS 1.35 aggiunge il supporto per Windows Server 2025. https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html
-
Rimozione della bandiera Kubelet: la
--pod-infra-container-imagebandiera è stata rimossa da kubelet. Gli utenti delle AMI personalizzate devono rimuovere questo flag dalla configurazione di Kubelet prima di eseguire l'aggiornamento alla versione 1.35. -
Avviso di deprecazione - Modalità IPVS: la modalità IPVS in kube-proxy è obsoleta e verrà rimossa in una futura versione di Kubernetes. Migrare alla modalità nftables. Per maggiori informazioni, vedi Esecuzione di kube-proxy in modalità nftables.
Per il changelog completo di Kubernetes, vedi 1.35 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-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
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.
-
-
AWS non sta rilasciando un'AMI EKS-optimized Amazon Linux 2 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.
-
Per ulteriori informazioni, consulta Deprecazione dell’AMI Amazon Linux 2.
-
-
AppArmor è deprecato in Kubernetes 1.34.
-
Consigliamo di migrare a soluzioni di sicurezza dei container alternative come seccomp
o Pod Security Standards.
-
-
VolumeAttributesClass (VAC) si laurea in GA in Kubernetes 1.34, migrando dall'API beta () all'API stabile ().
storage.k8s.io/v1beta1storage.k8s.io/v1-
Se si utilizza il driver EBS CSI con container sidecar AWS gestiti (da CSI Components
sulla ECR Gallery), la modifica del volume continuerà a funzionare senza problemi sui cluster EKS 1.31-1.33. AWS applicherà delle patch ai sidecar per supportare le API VAC beta fino alla fine del supporto per lo standard EKS 1.33 (29 luglio 2026). -
Se gestisci autonomamente i contenitori sidecar CSI, potresti dover aggiungere le versioni sidecar precedenti ai 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 successivo.
-
-
Il firmatario esterno di JWT Signer for Service Account Tokens viene promosso alla versione beta. Quando si utilizzano firmatari esterni, il flag --service-account-extend-token-expiration non è più completamente rispettato. Il server API impone la scadenza minima tra l'estensione desiderata (1 anno) e il limite del firmatario esterno (24 ore).
-
Consigliamo di utilizzare token di account di servizio associati
, che vengono montati e ruotati automaticamente da Kubernetes.
-
-
Dynamic Resource Allocation (DRA) Core APIs (GA): Dynamic Resource Allocation è diventata stabile, consentendo una gestione efficiente di hardware specializzato come le GPU 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.
-
Pod-level Resource Requests and Limits (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
MutableCSINodeAllocatableCountfeature gate è abilitato per impostazione predefinita 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 di errori, migliorando l'affidabilità della pianificazione stateful dei pod risolvendo le discrepanze tra la capacità di collegamento riportata e quella effettiva sui nodi.-
Per ulteriori informazioni, consulta Kubernetes v1.34: Mutable CSI Node Allocatable Count nel blog di Kubernetes.
-
-
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-driverflag 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 Kubernetes1.34, consulta https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md