Examiner les notes de mise à jour pour les versions de Kubernetes bénéficiant d’un support étendu

La fonctionnalité bêta VolumeAttributesClass et la ressource API sont activées dans Amazon EKS version 1.31. Cette fonctionnalité permet aux opérateurs de clusters de modifier les propriétés mutables des volumes persistants (PVs) gérés par des pilotes CSI compatibles, notamment le pilote Amazon EBS CSI. Pour tirer parti de cette fonctionnalité, veuillez vous assurer que votre pilote CSI prend en charge la fonctionnalité VolumeAttributesClass (pour le pilote CSI Amazon EBS, veuillez mettre à niveau vers la version 1.35.0 ou ultérieure afin d’activer automatiquement la fonctionnalité). Vous pourrez créer VolumeAttributesClass des objets pour définir les attributs de volume souhaités, tels que le type de volume et le débit, et les associer à vos demandes de volume persistantes (PVCs). Pour plus d’informations, consultez la documentation officielle de Kubernetes ainsi que la documentation de votre pilote CSI.

Le support de Kubernetes pour est AppArmordevenu stable et est désormais généralement disponible pour un usage public. Cette fonctionnalité vous permet de protéger vos conteneurs AppArmor en définissant le appArmorProfile.type champ dans le conteneursecurityContext. Avant la version de Kubernetes1.30, il AppArmor était contrôlé par des annotations. À partir de la version 1.30, il est contrôlé à l’aide de champs. Pour tirer parti de cette fonctionnalité, nous vous recommandons de migrer depuis les annotations et d’utiliser le champ appArmorProfile.type afin de garantir la compatibilité de vos charges de travail.

La fonctionnalité de transition de PersistentVolume dernière phase est devenue stable et est désormais généralement disponible pour une utilisation publique dans la version Kubernetes. 1.31 Cette fonctionnalité introduit un nouveau champ, dans le .status.lastTransitionTime PersistentVolumeStatus, qui fournit un horodatage indiquant la date à laquelle une PersistentVolume dernière phase est passée à une phase différente. Cette amélioration permet un meilleur suivi et une meilleure gestion PersistentVolumes, en particulier dans les scénarios où il est important de comprendre le cycle de vie des volumes.

À partir de la version Amazon EKS 1.30 ou d'une version plus récente, tous les groupes de nœuds gérés nouvellement créés utiliseront automatiquement par défaut Amazon Linux 2023 (AL2023) comme système d'exploitation des nœuds. Pour plus d’informations sur la spécification du système d’exploitation d’un groupe de nœuds gérés, consultez Création d’un groupe de nœuds gérés pour votre cluster.

Avec Amazon EKS 1.30, l’étiquette topology.k8s.aws/zone-id est ajoutée aux composants master. Vous pouvez utiliser la zone de disponibilité IDs (AZ IDs) pour déterminer l'emplacement des ressources d'un compte par rapport aux ressources d'un autre compte. Pour plus d'informations, consultez la section Zone de disponibilité IDs de vos AWS ressources dans le Guide de l'utilisateur de la AWS RAM.

À partir de la version 1.30, Amazon EKS n’inclut plus l’annotation default sur la ressource gp2 StorageClass appliquée aux clusters nouvellement créés. Cela n’a aucune incidence si vous référencez cette classe de stockage par son nom. Vous devez prendre des mesures si vous comptiez sur la présence d’une StorageClass par défaut dans le cluster. Vous devez référencer la StorageClass par le nom gp2. Vous pouvez également déployer la classe de stockage par défaut recommandée par Amazon EBS en définissant le paramètre defaultStorageClass.enabled sur true lors de l’installation de la version 1.31.0 ou ultérieure du aws-ebs-csi-driver add-on.

La politique IAM minimale requise pour le rôle IAM du cluster Amazon EKS a été modifiée. L’action ec2:DescribeAvailabilityZones est requise. Pour de plus amples informations, veuillez consulter Rôle IAM de cluster Amazon EKS.

Le champ .status.kubeProxyVersion pour les objets nœud est désormais obsolète, et le projet Kubernetes propose de le supprimer dans une prochaine version. Le champ obsolète n’est pas précis et a toujours été géré par kubelet, qui ne connaît pas réellement la version de kube-proxy, ni même si kube-proxy est en cours d’exécution. Si vous avez utilisé ce champ dans un logiciel client, veuillez cesser de le faire, car les informations ne sont pas fiables et le champ est désormais obsolète.

Dans Kubernetes 1.29, afin de réduire la surface d’attaque potentielle, la fonctionnalité LegacyServiceAccountTokenCleanUp marque les jetons hérités générés automatiquement et basés sur des secrets comme non valides s’ils n’ont pas été utilisés depuis longtemps (1 an par défaut), et les supprime automatiquement si aucune tentative d’utilisation n’est effectuée pendant une longue période après leur marquage comme non valides (1 année supplémentaire par défaut). Pour identifier ces jetons, vous pouvez exécuter :

kubectl get cm kube-apiserver-legacy-service-account-token-tracking -n kube-system