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 publication pour Kubernetes versions sur support standard
Cette rubrique présente les changements importants à prendre en compte pour chacun d'entre eux. Kubernetes version en 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 les versions ultérieures, Amazon, publié officiellement, EKS AMIs inclut containerd
comme seul environnement d'exécution. Kubernetes versions antérieures à la date d'1.24
utilisation 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 de plus amples informations, veuillez consulter Migrer dockershim de containerd.
Kubernetes 1,31
Kubernetes 1.31
est désormais disponible sur AmazonEKS. Pour plus d'informations sur Kubernetes 1.31
, voir l'annonce de sortie officielle
Important
-
L'indicateur kubelet,
--keep-terminated-pod-volumes
obsolète depuis 2017, a été supprimé dans le cadre de la publication.v1.31
Cette modification a un impact sur la façon dont les volumes de pods terminés sont gérés par le kubelet. Si vous utilisez cet indicateur dans les configurations de vos nœuds, vous devez mettre à jour vos scripts de démarrage et vos modèles de lancement pour le supprimer avant la mise à niveau.
-
Le portail et la API ressource des
VolumeAttributesClass
fonctionnalités bêta sont activés sur Amazon EKSv1.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 CSI pilotes compatibles, y compris le EBS CSI pilote Amazon. Pour tirer parti de cette fonctionnalité, assurez-vous que votre CSI chauffeur prend en charge cetteVolumeAttributesClass
fonctionnalité (pour le EBS CSI pilote Amazon, passez à la versionv1.35.0
ou à une version ultérieure pour activer automatiquement la fonctionnalité). Vous pourrez créerVolumeAttributesClass
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). Consultez la documentation officielle de Kubernetesainsi que la documentation de votre CSI pilote pour plus d'informations. -
Pour plus d'informations sur Amazon EBS CSI Driver, consultezStockez des volumes Kubernetes avec Amazon EBS.
-
-
Le support de Kubernetes pour est AppArmor
devenu 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 Kubernetesv1.30
, il AppArmor était contrôlé par des annotations. Tout d'abordv1.30
, il est contrôlé à l'aide de champs. Pour tirer parti de cette fonctionnalité, nous vous recommandons de vous éloigner des annotations et d'utiliser leappArmorProfile.type
champ pour 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
v1.31
Kubernetes. 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.
Pour le complet Kubernetes 1.30
changelog, voir -1.31.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
Kubernetes 1,30
Kubernetes 1.30
est désormais disponible sur AmazonEKS. Pour plus d'informations sur Kubernetes 1.30
, voir l'annonce de sortie officielle
Important
-
À partir de EKS la version d'Amazon
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 AMI type lors de la création d'un nouveau groupe de nœuds.-
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 (AZIDs) 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 AWS RAM l'utilisateur. -
À partir de là
1.30
, 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 l'existence d'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 EBS recommandée par Amazon 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 IAM politique minimale requise pour le IAM rôle de EKS cluster Amazon a changé. L'action
ec2:DescribeAvailabilityZones
est requise. Pour de plus amples informations, veuillez consulter IAMRôle EKS du cluster Amazon.
Pour le complet Kubernetes 1.30
journal des modifications, voir https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG -1.30.md.
Kubernetes 1,29
Kubernetes 1.29
est désormais disponible sur AmazonEKS. Pour plus d'informations sur Kubernetes 1.29
, voir l'annonce de sortie officielle
Important
-
Les
flowcontrol.apiserver.k8s.io/v1beta2
API versions obsolètes deFlowSchema
et nePriorityLevelConfiguration
sont plus servies dans Kubernetesv1.29
. Si vous avez des manifestes ou un logiciel client qui utilise le API groupe 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 Le 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. -
Entrée Kubernetes
1.29
pour 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 depuis longtemps (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 -n kube-system
Pour le complet Kubernetes 1.29
journal des modifications, voir https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOGchangelog-since-v-1.29.md#
Kubernetes 1,28
Kubernetes 1.28
est désormais disponible sur AmazonEKS. Pour plus d'informations sur Kubernetes 1.28
, voir l'annonce de sortie officielle
-
Kubernetes
v1.28
a étendu l'inclinaison prise en charge entre les composants du nœud principal et du plan de contrôle d'une version secondaire, 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 API du serveur a été ajusté pour permettre de changer les valeurs d'un état non défini à unStorageClass
nom réel.
Pour le complet Kubernetes 1.28
journal des modifications, voir https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOGchangelog-since-v-1.28.md#