Dai un’occhiata alle note di rilascio per le versioni Kubernetes sul supporto esteso

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 e la documentazione del driver CSI.

Il supporto di Kubernetes per AppArmorè 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 Kubernetes1.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.

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.

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 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.

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