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.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.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 de plus amples informations, veuillez consulter KEP-5040.

  • Modifications de l'étiquetage des volumes SELinux (GA) : l'étiquetage des volumes SELinux est désormais plus rapide par défaut pour tous les volumes de Kubernetes 1.36, en utilisant plutôt un réétiquetage récursif des fichiers. mount -o context Le partage d'un volume entre des pods privilégiés et non privilégiés sur le même nœud peut entraîner des problèmes. Les prochaines versions de Kubernetes pourraient introduire d'autres modifications majeures liées à cette fonctionnalité.

  • 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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter 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 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 Kubernetes 1.36.

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