Aidez à améliorer cette page
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Consultez les notes de mise à jour des versions de Kubernetes sur le 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 pour 12 mois de support 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 sur Amazon EKS. Pour plus d'informations sur Kubernetes1.30
, consultez l'annonce de sortie officielle
Important
-
À 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. Auparavant, les nouveaux groupes de nœuds étaient par défaut Amazon Linux 2 (AL2). Vous pouvez continuer à l'utiliser AL2 en le choisissant comme type d'AMI lors de la création d'un nouveau groupe de nœuds.-
Pour plus d'informations sur la migration de la AL2 version AL2 023, consultez. Mise à niveau d'Amazon Linux 2 vers Amazon Linux 2023
-
Pour plus d'informations sur Amazon Linux, consultez Comparing AL2 et AL2 023 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éez un groupe de nœuds gérés pour votre cluster
-
-
Avec Amazon EKS
1.30
, l'topology.k8s.aws/zone-id
étiquette est ajoutée aux nœuds de travail. 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
1.30
là, Amazon EKS n'inclut plus l'default
annotation sur lagp2 StorageClass
ressource appliquée aux clusters nouvellement créés. Cela n'a aucun impact si vous référencez cette classe de stockage par son nom. Vous devez prendre des mesures si vous comptez sur une valeur par défautStorageClass
dans le cluster. Vous devez les référencerStorageClass
par leur nomgp2
. Vous pouvez également déployer la classe de stockage par défaut recommandée par Amazon EBS en définissant ledefaultStorageClass.enabled
paramètre sur true lors de l'installation de la version1.31.0
ou ultérieure duaws-ebs-csi-driver add-on
. -
La politique IAM minimale requise pour le rôle IAM du cluster Amazon EKS a changé. L'action
ec2:DescribeAvailabilityZones
est requise. Pour de plus amples informations, veuillez consulter Rôle IAM de cluster Amazon EKS.
Kubernetes 1.29
Kubernetes 1.29
est désormais disponible sur Amazon EKS. Pour plus d'informations sur Kubernetes1.29
, consultez l'annonce de sortie officielle
Important
-
Les versions d'
flowcontrol.apiserver.k8s.io/v1beta2
API obsolètes deFlowSchema
et nePriorityLevelConfiguration
sont plus servies dans la version Kubernetes.1.29
Si vous avez des manifestes ou un logiciel client qui utilise le groupe d'API bêta obsolète, vous devez les modifier avant de passer à la version.1.29
-
Le
.status.kubeProxyVersion
champ pour les objets de nœud est désormais obsolète, et le projet Kubernetes propose de supprimer ce champ dans une future version. Le champ obsolète n'est pas précis et a toujours été géré parkubelet
- qui ne connaît pas réellement lakube-proxy
version, ni même si ellekube-proxy
est en cours d'exécution. Si vous avez utilisé ce champ dans un logiciel client, arrêtez. 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, laLegacyServiceAccountTokenCleanUp
fonctionnalité identifie les anciens jetons secrets générés automatiquement 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 avoir été marqués comme non valides (1 an 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
Kubernetes 1.28
Kubernetes 1.28
est désormais disponible sur Amazon EKS. Pour plus d'informations sur Kubernetes1.28
, consultez l'annonce de sortie officielle
-
Kubernetes
v1.28
a étendu l'écart pris en charge entre les composants du nœud principal et du plan de contrôle d'une version mineure, den-2
àn-3
, afin que les composants du nœud (kubelet
etkube-proxy
) de la version secondaire prise en charge la plus ancienne puissent fonctionner avec les composants du plan de contrôle (kube-apiserver
,,kube-scheduler
kube-controller-manager
,cloud-controller-manager
) de la version mineure prise en charge la plus récente. -
Les métriques
force_delete_pods_total
etforce_delete_pod_errors_total
duPod 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 fermé, orphelin, altéré ou parce qu'il s'arrête et n'est out-of-service pas planifié. -
Le contrôleur
PersistentVolume (PV)
a été modifié pour attribuer automatiquement uneStorageClass
par défaut à toutePersistentVolumeClaim
non associée dont le paramètrestorageClassName
n'est pas défini. En outre, le mécanisme de validation desPersistentVolumeClaim
admissions au sein du serveur API a été ajusté pour permettre de changer les valeurs d'un état non défini à unStorageClass
nom réel.