View a markdown version of this page

Examiner les notes de mise à jour pour les versions Kubernetes bénéficiant d’une assistance standard - Amazon EKS
Kubernetes 1.37Kubernetes 1.36Kubernetes 1.35Kubernetes 1.34

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 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.

Examiner les notes de mise à jour pour les versions Kubernetes bénéficiant d’une assistance standard

Astuce

Inscrivez-vous aux prochains ateliers Amazon EKS.

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

Kubernetes 1.37

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

Important

  • L'étiquetage des montages SELinux est activé par défaut (GA) : dans Kubernetes 1.37, la SELinuxMount fonctionnalité est activée par défaut. Lorsqu'un pod est configuré seLinuxOptions et que le pilote CSI de son volume est définiseLinuxMount: true, le kubelet monte le volume avec mount -o context=<label> au lieu de renommer chaque fichier. Un montage ne peut porter qu'une seule étiquette SELinux, donc un pod reste actif ContainerCreating si un autre pod du même nœud utilise déjà le même volume avec une étiquette SELinux différente, un niveau de privilège différent ou un niveau de seLinuxChangePolicy privilège différent. Les nœuds sur lesquels SELinux n'est pas activé ne sont pas affectés.

    • Action requise : Avant de procéder à la mise à niveau, lancez kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMount la recherche de pilotes avecseLinuxMount: true. Pour les volumes provenant de ces pilotes, recherchez les pods qui définissent seLinuxOptions et partagent un volume. Les pods qui partagent un volume doivent utiliser le même seLinuxOptions.level etseLinuxChangePolicy. Si un Pod privilégié et un Pod non privilégié partagent un volume, sélectionnez spec.securityContext.seLinuxChangePolicy: Recursive le Pod non privilégié. Recursiveconserve le comportement de réétiquetage précédent ; appliquez-le à tous les Pods partageant le même volume. Pour plus d'informations, voir SELinux Volume Label Changes goes GA (et implications probables dans la version 1.37) et. KEP-1710

  • Consolidation du mode automatique EKS par défaut : à partir de Kubernetes 1.37, nouveau mode automatique EKS NodePools qui ne spécifie pas consolidationPolicy par défaut au lieu de. Balanced WhenEmptyOrUnderutilized Balancedse traduit généralement par une diminution du nombre d'expulsions de Pod pour un coût à peu près le même. Ils sont intégrés general-purpose system NodePools et utilisésBalanced, et vous ne pouvez pas modifier ce paramètre sur eux. Pour plus de détails, consultez les notes de mise à jour d'EKS Auto Mode.

    • Action requise : pour conserver un comportement de consolidation spécifique, consolidationPolicy définissez-le vous-même de manière explicite NodePools. Si une charge de travail nécessite le comportement précédent, ciblez un NodePool comportement définiconsolidationPolicy: WhenEmptyOrUnderutilized.

  • Allocation dynamique des ressources (DRA) : les pilotes DRA et les administrateurs de clusters peuvent altérer les périphériques, tels que les GPU, de sorte que le planificateur ne les alloue pas aux pods qui ne tolèrent pas cette altération. L'utilisation de DRA sur EKS nécessite l'installation d'un pilote DRA, ce qu'EKS n'installe pas. Le pilote NVIDIA DRA est compatible avec la capacité statique Karpenter, les groupes de nœuds gérés EKS et les nœuds autogérés. Il n'est pas compatible avec le mode automatique EKS. Avec EKS Auto Mode ou Karpenter Dynamic Capacity Provisioning, utilisez le plug-in NVIDIA Device.

  • Tolérance configurable de l'autoscaler horizontal Pod (stable) : vous pouvez définir une tolérance par HPA, séparément pour l'augmentation et la réduction de l'échelle, au lieu de vous fier uniquement à la valeur par défaut de 10 % pour l'ensemble du cluster.

  • Horizontal Pod Autoscaler Scale to Zero (bêta) : le HPAScaleToZero Feature Gate est activé par défaut dans Kubernetes 1.37. Un HPA qui évolue en fonction de métriques d'objets ou externes peut être configuré minReplicas: 0 pour passer à zéro Pods lorsqu'il est inactif et pour revenir en arrière lorsque la demande revient. Les métriques d'objets et externes nécessitent un adaptateur de métriques, qu'EKS n'installe pas.

  • Modifications de configuration du kubelet : le kubelet ne démarre plus si un indicateur cAdvisor obsolète est défini (sauf--housekeeping-interval), supprime les container_tasks_state métriques container_cpu_load_average_10scontainer_cpu_load_d_average_10s, et et est traité comme aucune limite. eventRecordQPS: 0 Précédemment, une limite de 5 événements par seconde était eventRecordQPS: 0 appliquée. EKS-optimized Les AMI ne définissent pas les indicateurs cAdvisor obsolètes oueventRecordQPS, par conséquent, leur démarrage de kubelet et leur limite de débit restent inchangés. Les métriques supprimées concernent tous ceux qui les récupèrent, quelle que soit l'AMI.

    • Action requise : si vous utilisez des AMI personnalisées ou des arguments de kubelet supplémentaires, supprimez les indicateurs cAdvisor obsolètes et, si vous les définissezeventRecordQPS: 0, modifiez-les 5 pour conserver la limite de débit précédente. Mettez à jour tous les tableaux de bord ou alertes qui utilisent les mesures supprimées. Pour plus d'informations, consultez la référence de configuration de kubelet (v1beta1).

  • Kubelet enregistre sa configuration au démarrage : le kubelet enregistre désormais sa configuration effective complète au démarrage. Assurez-vous que seuls les utilisateurs de confiance peuvent lire les journaux des nœuds. Pour plus d'informations, consultez kubernetes/kubernetes #139837.

  • Pilote NVIDIA 595 pour les instances Amazon EC2 G7 : les instances G7 nécessitent le pilote NVIDIA 595. Les AMI NVIDIA EKS-optimized Amazon Linux 2023 incluent le pilote 595 sur toutes les versions prises en charge ; les AMI NVIDIA Bottlerocket l'incluent sur Kubernetes 1.37 et versions ultérieures.

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

Kubernetes 1.36

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

Important

  • Suppression du volume GitRepo : le type de gitRepo volume est définitivement désactivé dans Kubernetes 1.36 et ne peut pas être réactivé. L'API Kubernetes accepte toujours les Pods contenant des gitRepo volumes, mais le kubelet refusera de les exécuter et renverra une erreur.

    • Action requise : migrez vers des conteneurs d'initialisation ou des conteneurs sidecar git-sync avant de passer à la version 1.36. Pour plus d’informations, consultez KEP-5040.

  • Modifications de l'étiquetage des volumes SELinux (GA) : dans Kubernetes 1.36, l'étiquetage des volumes SELinux, plus rapide, s'applique par défaut à tous les volumes, en utilisant au lieu d'un réétiquetage récursif des fichiers. mount -o context Le partage d'un volume sur le même nœud entre des pods privilégiés et non privilégiés, ou entre des pods portant des étiquettes SELinux différentes, peut entraîner des problèmes. Le SELinuxMount comportement associé qui peut contenir un pod ContainerCreating est activé par défaut dans Kubernetes 1.37, et non dans 1.36. Consultez la section Kubernetes 1.37 avant de procéder à la mise à niveau.

  • IP/CIDR Validation stricte activée par défaut : la StrictIPCIDRValidation fonctionnalité gate est désormais activée par défaut pour les types d'API intégrés. Les champs d'API n'acceptent plus les valeurs IP ou CIDR comportant des zéros superflus (par exemple, 010.000.000.005 au lieu de10.0.0.5) ou les valeurs CIDR dont la sémantique est ambiguë (par exemple, au lieu de). 192.168.0.5/24 192.168.0.0/24 Les objets stockés existants sont préservés via un cliquet de validation, mais les nouvelles créations et mises à jour seront rejetées. Cela ne s'applique pas aux types de ressources personnalisés.

    • Action requise : Vérifiez les manifestes, les diagrammes Helm et l'automatisation pour les adresses IP contenant des zéros non significatifs ou une notation CIDR non canonique. Mettez-les à jour pour utiliser les formats canoniques avant de procéder à la mise à niveau. Pour plus d’informations, consultez KEP-4858.

  • Espaces de noms utilisateur (stable) : les espaces de noms utilisateur fournissent une défense approfondie en mappant l'utilisateur root d'un conteneur à un utilisateur non privilégié sur l'hôte, garantissant ainsi qu'une rupture de conteneur n'accorde aucun pouvoir administratif sur le nœud.

  • État de santé des ressources (version bêta) : indique l'état de santé de chaque appareil dans l'état du pod, ce qui permet aux opérateurs de déterminer si une boucle de blocage est due à un état de périphérique défectueux ou inconnu plutôt qu'à des problèmes d'application. Fonctionne à la fois avec les plugins de périphériques et l'allocation dynamique des ressources.

    • Pour plus d’informations, consultez KEP-4680.

  • Fonctionnalités d'allocation dynamique des ressources (bêta) : plusieurs fonctionnalités DRA sont désormais activées par défaut : les périphériques partitionnables et la capacité consommable pour un partage plus précis du matériel tel que les GPU, et les conditions de liaison des appareils pour des contrôles approfondis de l'état de préparation des appareils avant la planification.

  • Avis de dépréciation — Service ExternalIps : le externalIPs champ de Service .spec est obsolète dans Kubernetes 1.36. Des avertissements de dépréciation s'afficheront lors de la création ou de la mise à jour de services utilisant ce champ. La suppression complète de Kubernetes 1.43 est prévue. Les clients qui l'utilisent externalIPs doivent migrer vers LoadBalancer les NodePort services ou l'API Gateway. Pour plus d’informations, consultez KEP-5707.

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

Kubernetes 1.35

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

Important

  • Suppression du support Cgroup v1 : Kubernetes 1.35 déconseille le support du cgroup v1, ce qui signifie que le kubelet refusera de démarrer par défaut sur les nœuds utilisant cgroup v1.

    • AL2023 : AL2023 utilise le cgroup v2 par défaut et s'aligne sur le comportement en amont de Kubernetes.

      • Action requise : les clients qui ont configuré manuellement AL2023 pour utiliser cgroup v1 doivent soit migrer vers cgroups v2, soit configurer manuellement failCgroupV1: false dans la configuration kubelet.

    • Bottlerocket : Bottlerocket 1.35 utilise cgroup v2 par défaut, mais le définit failCgroupV1: false dans la configuration de Kubelet, en maintenant la rétrocompatibilité.

    • Fargate : Fargate continue d'utiliser le cgroup v1.

  • Fin du support de Containerd 1.x : Kubernetes 1.35 est la dernière version supportant Containerd 1.x. Vous devez passer à containerd 2.0 ou version ultérieure avant de passer à la prochaine version de Kubernetes.

  • En mars 2026, le projet Kubernetes en amont retirera Ingress NGINX, un composant d'infrastructure essentiel pour de nombreux environnements Kubernetes.

    • Action requise : les clients d'EKS doivent évaluer s'ils font confiance à Ingress NGINX et commencer à planifier la migration vers des alternatives telles que l'API Gateway ou des contrôleurs d'entrée tiers, car aucune autre version ne corrigera des bogues, des correctifs de sécurité ou des mises à jour après leur retrait. Les déploiements existants continueront de fonctionner, mais le fait de continuer à utiliser Ingress NGINX après la retraite rend votre environnement vulnérable aux risques de sécurité, car aucune des alternatives disponibles n'est un remplacement direct et nécessitera du temps de planification et d'ingénierie. Pour plus d'informations sur cette annonce de Kubernetes, consultez la déclaration officielle des comités de pilotage et de réponse à la sécurité de Kubernetes : Ingress NGINX a pris sa retraite. https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

  • In-Place Mises à jour des ressources des In-Place pods (stable) : les mises à jour des ressources des pods permettent aux utilisateurs d'ajuster les ressources du processeur et de la mémoire sans redémarrer les pods ou les conteneurs. Auparavant, de telles modifications nécessitaient de recréer des Pods, ce qui pouvait perturber les charges de travail, en particulier pour les applications avec état ou par lots. La nouvelle fonctionnalité intégrée permet une mise à l'échelle verticale plus fluide et sans interruption, améliore l'efficacité et peut également simplifier le développement.

  • PreferSameNode Distribution du trafic (stable) : le trafficDistribution champ des services a été mis à jour afin de permettre un contrôle plus explicite de l'acheminement du trafic. Une nouvelle option a été introduite pour permettre aux services de hiérarchiser strictement les points de terminaison sur le nœud local lorsqu'ils sont disponibles, et de revenir aux points de terminaison distants dans le cas contraire. PreferSameNode Cette modification rend l'API plus explicite quant à la préférence pour le trafic au sein du nœud actuel.

  • StatefulSet MaxUnavailable (Bêta) : cette fonctionnalité permet des mises à jour parallèles des pods par réglage maxUnavailable (par exemple, 3 ou 10 %), ce qui permet aux applications avec état telles que les clusters de bases de données de se mettre à jour jusqu'à 60 % plus rapidement que les mises à jour séquentielles une par une, ce qui réduit considérablement les fenêtres de maintenance.

  • Prise en charge de Windows Server 2025 : EKS 1.35 ajoute la prise en charge de Windows Server 2025.

  • Suppression de l'indicateur Kubelet : Le --pod-infra-container-image drapeau a été supprimé de Kubelet. Les utilisateurs d'AMI personnalisés doivent supprimer cet indicateur de la configuration de Kubelet avant de passer à la version 1.35.

  • Avis de dépréciation - Mode IPVS : le mode IPVS dans kube-proxy est obsolète et sera supprimé dans une future version de Kubernetes. Migrez vers le mode nftables. Pour plus d'informations, consultez Exécution de kube-proxy en mode nftables.

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

Kubernetes 1.34

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

Important

  • Containerd a été mis à jour vers la version 2.1 dans la version 1.34 pour le lancement.

    • Si vous rencontrez des problèmes après la mise à niveau, consultez les notes de publication de containerd 2.1.

  • AWS ne publie pas d'AMI EKS-optimized Amazon Linux 2 pour Kubernetes 1.34.

  • AppArmor est obsolète dans Kubernetes 1.34.

  • VolumeAttributesClass (VAC) passe à GA dans Kubernetes 1.34, puis passe de l'API bêta (storage.k8s.io/v1beta1) à l'API stable (). storage.k8s.io/v1

    • Si vous utilisez le pilote EBS CSI avec des conteneurs sidecar AWS gérés (depuis CSI Components sur la galerie ECR), la modification des volumes continuera de fonctionner de manière fluide sur les clusters EKS 1.31-1.33. AWS corrigera les sidecars pour prendre en charge les API VAC bêta jusqu'à la fin de la prise en charge de la norme EKS 1.33 (29 juillet 2026).

    • Si vous gérez vous-même vos conteneurs de sidecar CSI, vous devrez peut-être vous connecter à d'anciennes versions de sidecar sur des clusters antérieurs à la version 1.34 pour conserver la fonctionnalité VAC.

    • Pour utiliser les VolumeAttributesClass fonctionnalités GA (telles que l'annulation des modifications), passez à EKS 1.34 ou version ultérieure.

  • Le signataire JWT externe pour les jetons de compte de service est promu en version bêta. Lorsque vous utilisez des signataires externes, l'indicateur --service-account-extend-token-expiration n'est plus totalement respecté. Le serveur API applique l'expiration minimale entre l'extension souhaitée (1 an) et la limite du signataire externe (24 heures).

    • Nous vous recommandons d'utiliser des jetons de compte de service liés, qui sont automatiquement montés et pivotés par Kubernetes.

  • API principales (GA) d'allocation dynamique des ressources (DRA) : L'allocation dynamique des ressources est devenue stable, ce qui permet une gestion efficace du matériel spécialisé tel que les GPU via des interfaces d'allocation standardisées, simplifiant ainsi la gestion des ressources pour les accélérateurs matériels et améliorant l'utilisation des ressources spécialisées.

  • ServiceAccount Jetons projetés pour Kubelet (version bêta) : cette amélioration améliore la sécurité en utilisant des informations d'identification de courte durée pour les extraits d'images de conteneurs au lieu de secrets de longue durée de vie, réduisant ainsi le risque d'exposition des informations d'identification et renforçant la posture de sécurité globale de vos clusters.

  • Pod-level Demandes et limites de ressources (version bêta) : cette fonctionnalité simplifie la gestion des ressources en autorisant des pools de ressources partagés pour les pods multi-conteneurs, ce qui permet une allocation et une utilisation plus efficaces des ressources pour les applications complexes comportant plusieurs conteneurs.

  • Nombre de nœuds CSI modifiables pouvant être alloués (bêta) : la MutableCSINodeAllocatableCount fonctionnalité est activée par défaut dans EKS 1.34, ce qui rend mutable l'attribut CSInode max attachable volume count et introduit un mécanisme pour le mettre à jour dynamiquement en fonction de la configuration utilisateur au niveau du pilote CSI. Ces mises à jour peuvent être déclenchées soit par intervalles périodiques, soit par détection de défaillances, ce qui améliore la fiabilité de la planification dynamique des pods en corrigeant les incohérences entre la capacité de connexion signalée et la capacité réelle des nœuds.

  • Avis de dépréciation - Configuration du pilote de groupe de contrôle : la configuration manuelle du pilote de groupe de contrôle est obsolète au profit de la détection automatique.

    • Impact sur le client : si vous définissez actuellement l'--cgroup-driverindicateur manuellement dans votre configuration kubelet, vous devez vous préparer à supprimer cette configuration.

    • Action requise : prévoyez de mettre à jour les scripts d'amorçage des nœuds et les configurations AMI personnalisées afin de supprimer les paramètres manuels du pilote de groupe de contrôle avant que la fonctionnalité ne soit supprimée dans une future version de Kubernetes.

    • Pour plus d'informations, consultez la documentation du pilote cgroup.

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