Aidez à améliorer cette page
Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.
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.
Notes de mise à jour pour les versions bénéficiant du support standard
Cette rubrique présente les modifications importantes à prendre en compte pour chaque version de Kubernetes bénéficiant du support standard. Lors de la mise à niveau, examinez attentivement les modifications apportées entre l'ancienne et la nouvelle version de votre cluster.
Note
Pour les clusters 1.24
et versions ultérieures, les AMI Amazon EKS officiellement publiées incluent containerd
comme seul environnement d'exécution. Les versions de Kubernetes antérieures à la version 1.24
utilisent Docker comme environnement d'exécution par défaut. Ces versions disposent d'une option d'indicateur d'amorçage que vous pouvez utiliser pour tester vos charges de travail sur n'importe quel cluster pris en charge avec containerd
. Pour plus d’informations, consultez Amazon EKS a mis fin à la prise en charge de Dockershim.
Kubernetes1,30
Kubernetes 1.30
est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.30
, consultez l'annonce de la version 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 utilisaient par défaut Amazon Linux 2 (AL2). Vous pouvez continuer à 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 Amazon Linux, consultez la section 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
-
-
Avec Amazon EKS
1.30
, l'topology.k8s.aws/zone-id
étiquette est ajoutée aux nœuds de travail. 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 la section ID de zone de disponibilité de vos AWS ressources dans le guide de AWS RAM l'utilisateur. -
À 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'installationv1.31.0
ou ultérieurement 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 plus d’informations, consultez Rôle IAM de cluster Amazon EKS.
Pour obtenir le journal complet des modifications de Kubernetes 1.30
, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md
Kubernetes1,29
Kubernetes 1.29
est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.29
, consultez l'annonce de la version officielle
Important
-
Les versions d'
flowcontrol.apiserver.k8s.io/v1beta2
API obsolètes deFlowSchema
et dans lesquellesPriorityLevelConfiguration
elles ne sont plus diffusées. Kubernetesv1.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 procéder à la mise à niveau vers.v1.29
-
Le
.status.kubeProxyVersion
champ pour les objets de nœud est désormais obsolète, et le Kubernetes projet 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. -
Kubernetes
1.29
Afin de réduire la surface d'attaque potentielle, laLegacyServiceAccountTokenCleanUp
fonctionnalité considère les anciens jetons secrets générés automatiquement comme non valides s'ils n'ont pas été utilisés pendant une longue période (1 an par défaut) et les supprime automatiquement si leur utilisation n'est pas tenté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 -nkube-system
Pour obtenir le journal complet des modifications de Kubernetes 1.29
, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#changelog-since-v1280
Kubernetes1,28
Kubernetes 1.28
est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.28
, consultez l'annonce de la version officielle
-
Kubernetes
v1.28
a étendu la prise en charge du décalage 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 mineure prise en charge la plus ancienne puissent fonctionner avec les composants du plan de contrôle (kube-apiserver
,kube-scheduler
,kube-controller-manager
etcloud-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 des admissions dePersistentVolumeClaim
du serveur d'API a été ajusté pour permettre de remplacer un état non défini par un nom deStorageClass
.
Pour obtenir le journal complet des modifications de Kubernetes 1.28
, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#changelog-since-v1270
Kubernetes1,27
Kubernetes 1.27
est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.27
, consultez l'annonce de la version officielle
Important
-
La prise en charge des annotations alpha
seccomp.security.alpha.kubernetes.io/pod
etcontainer.seccomp.security.alpha.kubernetes.io
des annotationsseccomp
a été supprimée. Les annotations alphaseccomp
sont devenues obsolètes en1.19
, avec leur suppression de1.27
, les champsseccomp
ne seront plus remplis automatiquement pour lesPods
avec les annotationsseccomp
. Utilisez plutôt le champsecurityContext.seccompProfile
réservé aux conteneurs ouPods
pour configurer les profilsseccomp
. Pour vous assurer que vous utilisez la base d'annotations alphaseccomp
obsolètes dans votre cluster, exécutez la commande suivante :kubectl get pods --all-namespaces -o json | grep -E 'seccomp.security.alpha.kubernetes.io/pod|container.seccomp.security.alpha.kubernetes.io'
-
L'argument de ligne de commande
--container-runtime
pourkubelet
a été supprimé. L'environnement d'exécution du conteneur par défaut pour Amazon EKS a étécontainerd
défini depuis1.24
, ce qui élimine le besoin de spécifier le temps d'exécution du conteneur. À partir de1.27
, Amazon EKS ignorera l'argument--container-runtime
transmis à tous les scripts d'amorçage. Il est important de ne pas transmettre cet argument à--kubelet-extra-args
afin d'éviter les erreurs lors du processus d'amorçage du nœud. Vous devez supprimer l'argument--container-runtime
de tous vos flux de travail de création de nœuds et de vos scripts de génération.
-
Le
kubelet
dans Kubernetes1.27
a augmenté la valeur par défautkubeAPIQPS
à50
etkubeAPIBurst
à100
. Ces améliorations permettent àkubelet
de gérer un plus grand volume de requêtes d'API, améliorant ainsi les temps de réponse et les performances. Lorsque les demandes dePods
augmentent, en raison des exigences de mise à l'échelle, les valeurs par défaut révisées garantissent la capacité dekubelet
à gérer efficacement l'augmentation de la charge de travail. Par conséquent, les lancementsPod
sont plus rapides et les opérations de cluster sont plus efficaces. -
Vous pouvez utiliser une topologie
Pod
plus fine pour diffuser des politiques telles queminDomain
. Ce paramètre vous permet de spécifier le nombre minimum de domaines sur lesquels vosPods
devez être répartis.nodeAffinityPolicy
etnodeTaintPolicy
permettent un niveau de granularité supplémentaire dans la gestion de la distributionPod
. Ceci est conforme aux affinités des nœuds, aux rejets et au champmatchLabelKeys
dans letopologySpreadConstraints
de votre spécificationPod's
. Cela permet de sélectionner desPods
pour étaler les calculs après une mise à niveau progressive. -
Kubernetes
1.27
promu en version bêta un nouveau mécanisme de politiqueStatefulSets
contrôlant la durée de vie de leurPersistentVolumeClaims
(PVCs
). La nouvelle politique de rétentionPVC
vous permet de spécifier si les donnéesPVCs
générées à partir du modèle de spécificationStatefulSet
seront automatiquement supprimées ou retenues lors de la suppression duStatefulSet
ou de la réduction des répliques dans leStatefulSet
. -
L'option
goaway-chance
dans le serveur d'API Kubernetes permet d'éviter que les connexions client HTTP/2
soient bloquées sur une seule instance de serveur d'API, en fermant une connexion de manière aléatoire. Lorsque la connexion est fermée, le client essaiera de se reconnecter et atterrira probablement sur un autre serveur d'API en raison de l'équilibrage de charge. La version1.27
de Amazon EKS a activé l'indicateurgoaway-chance
. Si votre charge de travail exécutée sur le cluster Amazon EKS utilise un client qui n'est pas compatible avecHTTP GOAWAY
, nous vous recommandons de mettre à jour votre client pour qu'il gère GOAWAY
en se reconnectant à la fin de la connexion.
Pour obtenir le journal complet des modifications de Kubernetes 1.27
, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#changelog-since-v1260
Kubernetes1,26
Kubernetes 1.26
est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.26
, consultez l'annonce de la version officielle
Important
Kubernetes 1.26
ne prend plus en charge CRI v1alpha2
. Il en résulte que le kubelet
n'enregistre plus le nœud si l'environnement d'exécution du conteneur ne prend pas en charge CRI v1
. Cela signifie également que Kubernetes 1.26
ne prend pas en charge la version mineure de containerd 1.5
et antérieures. Si vous utilisez containerd, vous devez effectuer une mise à niveau vers la version containerd1.6.0
ou une version ultérieure avant de procéder à la mise à niveau de tout nœud vers Kubernetes 1.26
. Vous devez également mettre à niveau tous les autres environnements d'exécution de conteneur qui ne prennent en charge que v1alpha2
. Pour plus d'informations, reportez-vous au fournisseur du moteur d'exécution du conteneur. Par défaut, AMI Amazon Linux et Bottlerocket incluent la version de containerd 1.6.6
.
-
Avant de procéder à la mise à niveau vers Kubernetes
1.26
, mettez à niveau votre Amazon VPC CNI plugin for Kubernetes vers la version1.12
ou ultérieure. Si vous n'effectuez pas la mise à niveau vers la version1.12
ou ultérieure du Amazon VPC CNI plugin for Kubernetes, le Amazon VPC CNI plugin for Kubernetes plantera. Pour plus d’informations, consultez Utilisation du module complémentaire Amazon VPC CNI plugin for Kubernetes Amazon EKS. -
L'option
goaway-chance
dans le serveur d'API Kubernetes permet d'éviter que les connexions client HTTP/2
soient bloquées sur une seule instance de serveur d'API, en fermant une connexion de manière aléatoire. Lorsque la connexion est fermée, le client essaiera de se reconnecter et atterrira probablement sur un autre serveur d'API en raison de l'équilibrage de charge. La version1.26
de Amazon EKS a activé l'indicateurgoaway-chance
. Si votre charge de travail exécutée sur le cluster Amazon EKS utilise un client qui n'est pas compatible avecHTTP GOAWAY
, nous vous recommandons de mettre à jour votre client pour qu'il gère GOAWAY
en se reconnectant à la fin de la connexion.
Pour obtenir le journal complet des modifications de Kubernetes 1.26
, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.26.md#changelog-since-v1250