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

Amazon EKS prend en charge les versions de Kubernetes plus longtemps qu’elles ne sont prises en charge en amont, avec un support standard pour les versions mineures de Kubernetes pendant 14 mois à compter de leur publication dans Amazon EKS, et un support étendu pour les versions mineures de Kubernetes pendant 12 mois supplémentaires (26 mois au total par version).

Cette rubrique présente les modifications importantes à prendre en compte pour chaque version de Kubernetes bénéficiant d'un support étendu. Lors de la mise à niveau, examinez attentivement les modifications apportées entre l'ancienne et la nouvelle version de votre cluster.

Kubernetes 1.30

Kubernetes 1.30 est désormais disponible dans Amazon EKS. Pour plus d’informations sur Kubernetes 1.30, consultez l’annonce officielle de publication.

Important

• À partir de la version 1.30 ou ultérieure d’Amazon EKS, tous les groupes de nœuds gérés nouvellement créés utiliseront automatiquement Amazon Linux 2023 (AL2023) comme système d’exploitation par défaut. Auparavant, les nouveaux groupes de nœuds utilisaient par défaut Amazon Linux 2 (AL2). Vous pouvez continuer à utiliser AL2 en le sélectionnant comme type d’AMI lors de la création d’un nouveau groupe de nœuds.

  • Pour plus d’informations sur la migration d’AL2 vers AL2023, consultez Mise à niveau d’Amazon Linux 2 vers Amazon Linux 2023.

  • Pour plus d’informations sur Amazon Linux, consultez Comparaison entre AL2 et AL2023 dans le Guide de l’utilisateur Amazon Linux.

  • 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 les ID de zone de disponibilité (ID AZ) pour déterminer l’emplacement des ressources d’un compte par rapport aux ressources d’un autre compte. Pour plus d’informations, consultez ID de zone de disponibilité pour vos ressources AWS dans le Guide de l’utilisateur 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, consultez Rôle IAM de cluster Amazon EKS.

Pour consulter le journal des modifications complet de Kubernetes 1.30, consultez https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md.

Kubernetes 1.29

Kubernetes 1.29 est désormais disponible dans Amazon EKS. Pour plus d’informations sur Kubernetes 1.29, consultez l’annonce officielle de publication.

Important

• Les versions API obsolètes flowcontrol.apiserver.k8s.io/v1beta2 de FlowSchema et PriorityLevelConfiguration ne sont plus prises en charge dans la version 1.29 de Kubernetes. Si vous disposez de manifestes ou de logiciels clients qui utilisent le groupe d’API bêta obsolète, il est recommandé de les modifier avant de mettre à niveau vers la version 1.29.

• 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

Pour consulter le journal des modifications complet de Kubernetes 1.29, consultez https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#changelog-since-v1280.

Kubernetes 1.28

Kubernetes 1.28 est désormais disponible dans Amazon EKS. Pour plus d’informations sur Kubernetes 1.28, consultez l’annonce officielle de publication.

• Kubernetes v1.28 a étendu le décalage pris en charge entre les composants du nœud principal et ceux du plan de contrôle d’une version mineure, passant de n-2 à n-3, afin que les composants du nœud (kubelet et kube-proxy) pour la version mineure la plus ancienne prise en charge puissent fonctionner avec les composants du plan de contrôle (kube-apiserver, kube-scheduler, kube-controller-manager, cloud-controller-manager) pour la version mineure la plus récente prise en charge.

• Les métriques force_delete_pods_total et force_delete_pod_errors_total du Pod GC Controller ont été améliorées pour tenir compte de toutes les suppressions de pods forcées. Une raison est ajoutée à la métrique pour indiquer si le pod est supprimé de force parce qu’il est résilié, orphelin, résilié avec le rejet hors service ou résilié et non planifié.

• Le contrôleur PersistentVolume (PV) a été modifié pour attribuer automatiquement une StorageClass par défaut à toute PersistentVolumeClaim non associée dont le paramètre storageClassName n'est pas défini. De plus, le mécanisme de validation d’admission PersistentVolumeClaim au sein du serveur API a été ajusté pour permettre de changer les valeurs d’un état non défini à un nom StorageClass réel.

Pour consulter le journal des modifications complet de Kubernetes 1.28, consultez https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#changelog-since-v1270.