Notes de mise à jour pour les versions bénéficiant d'un soutien étendu

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.

Kubernetes1,25

Kubernetes 1.25 est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.25, consultez l'annonce de la version officielle.

Important

• À partir de Kubernetes version 1.25, vous ne pourrez plus utiliser les instances P2 Amazon EC2 avec les instances AMI Amazon Linux accélérées et optimisées pour Amazon EKS prêtes à l’emploi. Ces AMI pour Kubernetes 1.25 ou les versions ultérieures prendront en charge les pilotes de la série NVIDIA 525 ou ultérieurs, qui sont incompatibles avec les instances P2. Toutefois, les pilotes de la série NVIDIA 525 ou ultérieurs sont compatibles avec les instances P3, P4 et P5, ce qui vous permet d’utiliser ces instances avec les AMI pour Kubernetes 1.25 ou une version ultérieure. Avant de mettre à niveau vos clusters Amazon EKS vers la version 1.25, migrez toutes les instances P2 vers les instances P3, P4 et P5. Vous devez également mettre à jour vos applications de manière proactive pour qu'elles fonctionnent avec les pilotes de la série NVIDIA 525 ou d'une série ultérieure. Nous prévoyons de rétroporter les nouvelles NVIDIA 525 séries ou les pilotes ultérieurs vers des Kubernetes versions ultérieures 1.23 et 1.24 ce, fin janvier 2024.

• PodSecurityPolicy (PSP) est supprimé dans Kubernetes 1.25. Les PSPs sont remplacées par la fonctionnalité PSA (Pod Security Admission) et les normes de sécurité des pods (PSS). PSA est un contrôleur d'admission intégré qui met en œuvre les contrôles de sécurité décrits dans la PSS. PSA et PSS passent au statut stable dansKubernetes 1.25 et sont activés dans Amazon EKS par défaut. Si vous PSPs en avez un dans votre cluster, assurez-vous de migrer PSP vers la solution intégrée Kubernetes PSS ou vers une policy-as-code solution avant de passer à la version de votre cluster1.25. Dans le cas contraire, vos charges de travail sont susceptibles d'être interrompues. Pour plus d’informations, consultez le FAQ sur la suppression de la politique de sécurité des pods (PSP).

• La version 1.25 de Kubernetes contient des modifications qui modifient le comportement d'une fonctionnalité existante appelée API Priority and Fairness (APF). APF sert à protéger le serveur d'API d'une surcharge potentielle pendant les périodes d'augmentation du volume de demandes. Pour ce faire, elle impose des restrictions sur le nombre de demandes simultanées pouvant être traitées à un moment donné. Ceci est réalisé en appliquant des niveaux de priorité et des limites distincts aux demandes provenant de différentes charges de travail ou utilisateurs. Cette approche assure un traitement privilégié aux applications critiques ou aux demandes à priorité élevée, tout en évitant que les demandes à faible priorité ne surchargent le serveur d'API. Pour plus d'informations, voir API Priority and Fairness dans la documentation Kubernetes ou API Priority and Fairness dans le guide des meilleures pratiques EKS.

  Ces mises à jour ont été introduites dans PR #10352 et PR #118601. Auparavant, APF traitait tous les types de demandes de manière homogène, chaque demande consommant une seule unité de la limite de demandes simultanées. La modification du comportement d'APF accorde des niveaux de concurrence plus élevés aux demandes LIST en raison de la charge particulièrement lourde qu'elles imposent au serveur d'API. Le serveur d'API estime le nombre d'objets qui seront renvoyés par une demande LIST. Il attribue une unité de concurrence proportionnelle au nombre d'objets renvoyés.

  Suite à la mise à niveau vers la version 1.25 ou supérieure d'Amazon EKS, ce comportement mis à jour pourrait entraîner que les charges de travail avec des demandes LIST lourdes (qui fonctionnaient auparavant sans problème) rencontrent des limitations de débit. Cela serait signalé par un code de réponse HTTP 429. Pour éviter toute perturbation potentielle des charges de travail en raison de la limitation du débit des demandes LIST, nous vous encourageons vivement à restructurer vos charges de travail afin de réduire le débit de ces demandes. Une autre manière de remédier à cette situation est d'adapter les paramètres APF pour allouer davantage de capacité aux demandes essentielles tout en réduisant la capacité allouée aux demandes non essentielles. Pour plus d'informations sur ces techniques d'atténuation, voir Prévention des demandes abandonnées dans le guide des meilleures pratiques EKS.

• Amazon EKS1.25 inclut des améliorations de l'authentification des clusters qui contiennent des bibliothèques YAML mises à jour. Si une valeur YAML de la ConfigMap aws-auth trouvée dans l'espace de noms kube-system commence par une macro, où le premier caractère est une accolade, vous devez ajouter des guillemets (“ ”) avant et après les accolades ({ }). Cela est nécessaire pour garantir que la version aws-iam-authenticator de v0.6.3 analyse correctement la ConfigMap aws-auth dans Amazon EKS 1.25.

• La version bêta de l'API (discovery.k8s.io/v1beta1) de EndpointSlice est devenue obsolète dans Kubernetes 1.21 et n'est plus disponible depuis Kubernetes 1.25. Cette API a été mise à jour vers discovery.k8s.io/v1. Pour plus d'informations, consultez la section EndpointSlicedans la documentation Kubernetes. Le AWS Load Balancer Controller v2.4.6 et les versions antérieures utilisaient le point de terminaison v1beta1 pour communiquer avec EndpointSlices. Si vous utilisez la configuration EndpointSlices pour AWS Load Balancer Controller, vous devez effectuer la mise à niveau vers AWS Load Balancer Controller v2.4.7 avant de mettre à niveau votre cluster Amazon EKS vers 1.25. Si vous effectuez une mise à niveau vers la version 1.25 alors que vous utilisez la configuration EndpointSlices du AWS Load Balancer Controller, le contrôleur se bloquera, ce qui entraînera des interruptions de vos charges de travail. Pour mettre à niveau le contrôleur, consultez la rubrique Qu'est-ce que AWS Load Balancer Controller ?.

• SeccompDefault passe en version bêta dans Kubernetes 1.25. En définissant l'indicateur --seccomp-default lors de la configuration de kubelet, l'environnement d'exécution de conteneur utilise son profil seccomp RuntimeDefault au lieu du mode non confiné (seccomp disabled). Les profils par défaut fournissent un ensemble solide de paramètres de sécurité par défaut, tout en préservant l'intégrité de la charge de travail. Bien que cet indicateur soit disponible, Amazon EKS ne l'active pas par défaut, de sorte que le comportement d'Amazon EKS reste effectivement inchangé. Si vous le souhaitez, vous pouvez l'activer sur vos nœuds. Pour plus d'informations, consultez le didacticiel Restriction des appels système d'un conteneur avec seccomp de la documentation Kubernetes.

• L'interface CRI (Container Runtime Interface) pour Docker (ou Dockershim) n'est plus prise en charge à partir de Kubernetes 1.24. Le seul environnement d'exécution de conteneur dans les AMIs officielles Amazon EKS pour les clustersKubernetes 1.24 et les versions ultérieures est containerd. Avant de passer à Amazon EKS 1.24 ou à une version ultérieure, supprimez toute référence aux indicateurs de script d'amorçage qui ne sont plus pris en charge. Pour plus d’informations, consultez Amazon EKS a mis fin à la prise en charge de Dockershim.

• La prise en charge des requêtes génériques est devenue obsolète dans CoreDNS 1.8.7 et a été supprimée dans CoreDNS 1.9. Cela a été fait par mesure de sécurité. Les requêtes génériques ne fonctionnent plus et renvoient NXDOMAIN au lieu d'une adresse IP.

• 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 version 1.25 de Amazon EKS a activé l'indicateur goaway-chance. Si votre charge de travail exécutée sur le cluster Amazon EKS utilise un client qui n'est pas compatible avec HTTP 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.25, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#changelog-since-v1240.

Kubernetes1,24

Kubernetes 1.24 est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.24, consultez l'annonce de la version officielle.

Important

• À partir de la version 1.24 de Kubernetes, les nouvelles API bêta ne sont pas activées par défaut dans les clusters. Par défaut, les API bêta existantes et les nouvelles versions de celles-ci continuent d'être activées. Amazon EKS adopte le même comportement que l'instance de Kubernetes 1.24 située en amont. Les portails de fonctionnalités qui contrôlent les nouvelles fonctionnalités pour les opérations d'API nouvelles et existantes sont activés par défaut. Ceci est conforme à l'instance de Kubernetes située en amont. Pour plus d'informations, voir KEP-3136 : Les API bêta sont désactivées par défaut. GitHub

• L'interface CRI (Container Runtime Interface) pour Docker (ou Dockershim) n'est plus prise en charge à partir de la version 1.24 de Kubernetes. Les AMI officielles d'Amazon EKS utilisent containerd comme seul environnement d'exécution. Avant de passer à Amazon EKS 1.24 ou version ultérieure, vous devez supprimer toute référence aux indicateurs de script d'amorçage qui ne sont plus pris en charge. Vous devez également vous assurer que le transfert IP est activé pour vos nœuds de travail. Pour plus d’informations, consultez Amazon EKS a mis fin à la prise en charge de Dockershim.

• Si vous avez déjà configuré Fluentd pour Container Insights, vous devez effectuer la migration Fluentd vers Fluent Bit avant de mettre à jour votre cluster. Les analyseurs Fluentd sont configurés pour analyser uniquement les messages du journal au format JSON. Contrairement à dockerd, l'exécution du conteneur containerd a des messages de journal qui ne sont pas au format JSON. Si vous ne migrez pas vers Fluent Bit, certains des analyseurs Fluentd's configurés généreront un grand nombre d'erreurs à l'intérieur du conteneur Fluentd. Pour plus d'informations sur la migration, voir Configurer en Fluent Bit tant que DaemonSet pour envoyer des CloudWatch journaux vers Logs.

• Dans Kubernetes 1.23 et versions antérieures, les certificats de service kubelet dotés d'une adresse IP et d'un SAN (Subject Alternative Name) invérifiables étaient automatiquement émis avec un SAN invérifiable. Ces SAN invérifiables sont omis du certificat fourni. Dans les versions 1.24 et ultérieures des clusters, les certificats de service kubelet ne sont pas émis si un SAN est invérifiable. Cela entrave le fonctionnement des commandes kubectl exec et kubectl logs. Pour plus d’informations, consultez Considérations relatives à la signature des certificats avant la mise à niveau de votre cluster vers Kubernetes 1.24.

• Lorsque vous mettez à niveau un cluster Amazon EKS 1.23 qui utilise Fluent Bit, vous devez vous assurer qu'il est exécuté avec la version k8s/1.3.12 ou une version ultérieure. Vous pouvez le faire en réappliquant le dernier fichier YAML Fluent Bit applicable à partir de GitHub. Pour plus d'informations, consultez la section Configuration Fluent Bit dans le guide de CloudWatch l'utilisateur Amazon.

• Vous pouvez avoir recours à des indicateurs prenant en compte la topologie (Topology Aware Hints) pour spécifier que vous préférez maintenir le trafic dans une zone lorsque les composants master du cluster sont déployés dans plusieurs zones de disponibilité. Le routage du trafic au sein d'une zone peut contribuer à réduire les coûts et à améliorer les performances du réseau. Par défaut, les indicateurs prenant en compte la topologie sont activés dans Amazon EKS 1.24. Pour plus d'informations, consultez Indicateurs prenant en compte la topologie dans la documentation Kubernetes.

• Il est prévu que la PSP (PodSecurityPolicy) soit supprimée de Kubernetes 1.25. Les PSPs sont remplacées par la fonctionnalité Pod Security Admission (PSA). PSA est un contrôleur d'admission intégré qui utilise les contrôles de sécurité décrits dans les normes de sécurité des pods (Pod Security Standards - PSS). PSA et PSS sont des fonctionnalités bêta activées par défaut dans Amazon EKS. Pour remédier à la suppression de la PSP dans la version 1.25, nous vous recommandons d'implémenter PSS dans Amazon EKS. Pour plus d'informations, consultez la section Implémentation des normes de sécurité des pods dans Amazon EKS sur le blog AWS .

• Le client.authentication.k8s.io/v1alpha1 ExecCredential est retiré dans Kubernetes1.24. L' ExecCredential API était généralement disponible en Kubernetes1.22. Si vous utilisez un plug-in d'informations d'identification client-go qui repose sur l'API v1alpha1, contactez le distributeur de votre plug-in pour savoir comment migrer vers l'API v1.

• Pour Kubernetes 1.24, nous avons ajouté une fonctionnalité au projet Cluster Autoscaler situé en amont afin de simplifier le dimensionnement des groupes de nœuds gérés par Amazon EKS vers et depuis zéro nœud. Auparavant, pour que l'outil Cluster Autoscaler puisse comprendre les ressources, les étiquettes et les rejets d'un groupe de nœuds géré dont la taille était réduite à zéro nœud, vous deviez baliser le groupe Amazon EC2 Auto Scaling sous-jacent avec les détails des nœuds dont il était responsable. Désormais, lorsqu'aucun nœud n'est en cours d'exécution dans le groupe de nœuds géré, Cluster Autoscaler appelle l'opération d'API DescribeNodegroup d'Amazon EKS. Cette opération d'API fournit les informations dont Cluster Autoscaler a besoin en termes de ressources, d'étiquettes et de rejets du groupe de nœuds géré. Pour utiliser cette fonctionnalité, vous devez ajouter l'autorisation eks:DescribeNodegroup à la politique IAM du compte de service Cluster Autoscaler. Lorsque la valeur d'une balise Cluster Autoscaler figurant sur le groupe Auto Scaling qui alimente un groupe de nœuds géré par Amazon EKS entre en conflit avec le groupe de nœuds lui-même, Cluster Autoscaler préfère la valeur de la balise du groupe Auto Scaling. Cela vous permet de remplacer les valeurs selon vos besoins. Pour plus d’informations, consultez Autoscaling.

• Si vous avez l'intention d'utiliser Inferentia ou d'utiliser des types d'Trainiuminstance avec Amazon EKS1.24, vous devez effectuer une mise à niveau vers le plug-in pour AWS Neuron appareil version 1.9.3.0 ou ultérieure. Pour plus d'informations, consultez la version Neuron K8 [1.9.3.0] dans la documentation. AWS Neuron

• IPv6 est activée par défaut dans Containerd pour les Pods. Containerd applique les paramètres du noyau des nœuds aux espaces de noms des réseaux de Pod. De ce fait, les conteneurs d'un Pod sont liés à la fois aux adresses de bouclage IPv4 (127.0.0.1) et IPv6 (::1). IPv6 est le protocole de communication par défaut. Avant de mettre à jour votre cluster vers la version 1.24, nous vous recommandons de tester vos Pods multi-conteneurs. Modifiez les applications de sorte qu'elles puissent se lier à toutes les adresses IP sur les interfaces de bouclage. La plupart des bibliothèques permettent la liaison IPv6, qui est rétrocompatible avec IPv4. S'il vous est impossible de modifier le code de votre application, deux options s'offrent à vous :

  • Exécutez un conteneur init et définissez disable ipv6 sur true (sysctl -w net.ipv6.conf.all.disable_ipv6=1).

  • Configurez un webhook d'admission en mutation pour injecter un conteneur init parallèlement à vos Pods d'applications.

  Si vous devez bloquer IPv6 pour tous les Pods sur tous les nœuds, vous devrez peut-être désactiver IPv6 sur vos instances.

• 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 version 1.24 de Amazon EKS a activé l'indicateur goaway-chance. Si votre charge de travail exécutée sur le cluster Amazon EKS utilise un client qui n'est pas compatible avec HTTP 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.24, consultez https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#changelog-since-v1230.

Kubernetes1,23

Kubernetes 1.23 est désormais disponible dans Amazon EKS. Pour plus d'informations sur Kubernetes 1.23, consultez l'annonce de la version officielle.

Important

• La fonctionnalité de migration de volume de l'interface de stockage de conteneurs (CSI) disponible dans l'arborescence Kubernetes est activée. Cette fonctionnalité permet de remplacer les plugins de stockage existants dans l'arborescence Kubernetes pour Amazon EBS avec un pilote Amazon EBS CSI correspondant. Pour plus d'informations, veuillez consulter la fonctionnalité Kubernetes1.17 : La migration des volumes de l'arborescence Kubernetes vers CSI passe en version bêtasur le blog Kubernetes.

  La fonctionnalité traduit les API dans l'arborescence en API CSI équivalentes et délègue les opérations à un pilote CSI de remplacement. Grâce à cette fonctionnalité, si vous utilisez StorageClass,PersistentVolume, et PersistentVolumeClaim qui appartiennent à ces charges de travail, il n'y aura probablement aucun changement conséquent. La fonctionnalité permet à Kubernetes de déléguer toutes les opérations de gestion du stockage depuis le plug-in intégré à l'arborescence au pilote CSI. Si vous utilisez des volumes Amazon EBS dans un cluster existant, vous devrez installer le pilote Amazon EBS CSI avant de mettre à jour votre cluster vers la version 1.23. Si vous n'installez pas ce pilote avant de mettre à jour un cluster existant, vous pourriez faire face à une interruption de la charge de travail. Si vous prévoyez de déployer des charges de travail qui utilisent des volumes Amazon EBS dans un nouveau cluster 1.23, installez le pilote Amazon EBS CSI dans votre cluster avant d'y déployer les charges de travail. Pour plus d'instructions sur l'installation du pilote CSI Amazon EBS sur votre cluster, consultez Pilote CSI Amazon EBS. Pour les questions fréquentes sur la fonction de migration, consultez Foire aux questions sur la migration vers Amazon EBS CSI.

• Support étendu pour les Windows AMI optimisées Amazon EKS publiées par AWS n'est pas disponible pour les Kubernetes versions 1.23 mais est disponible pour les Kubernetes versions 1.24 et supérieures.

• Kubernetes ne prend plus en charge dockershim dans sa version 1.20 et a supprimé dockershim dans la version 1.24. Pour plus d'informations, voir l'article intitulé Kubernetes is Moving on From Dockershim: Commitments and Next Steps sur le blog Kubernetes. Amazon EKS cessera de prendre en charge dockershim à partir de la version 1.24 d'Amazon EKS. À partir de la version 1.24, les AMI officiels d'Amazon EKS auront containerd comme seul environnement d'exécution.

  Même si la version 1.23 d'Amazon EKS continue de prendre en charge dockershim, nous vous recommandons de commencer à tester vos applications dès maintenant pour identifier et supprimer les dépendances Docker. En procédant ainsi, vous êtes prêt à mettre à jour votre cluster vers la version 1.24. Pour en savoir plus sur la suppression de dockershim, consultez Amazon EKS a mis fin à la prise en charge de Dockershim.

• Kubernetes a fait évolué les IPv4/IPv6 vers la mise en réseau du double empilement Pods, services et nœuds à la disponibilité générale. Toutefois, Amazon EKS et le Amazon VPC CNI plugin for Kubernetes ne prennent actuellement pas en charge la mise en réseau du double empilement. Vos clusters peuvent attribuer IPv4 ou IPv6 adresses de Pods et les services. Toutefois, il ne peut pas attribuer les deux types d'adresses.

• Kubernetes a fait passer la fonctionnalité Pod Security Admission (PSA) en version bêta. Cette fonction est activée par défaut. Pour plus d'informations, consultez Politiques d'admission de sécurité de Pod dans la documentation Kubernetes. PSA remplace le contrôleur d'admission PSP (Pod Security Policy). Le contrôleur d'admission PSP n'est pas pris en charge et sa suppression est prévue dans Kubernetes version1.25.

  Le PSP contrôleur d'admission applique Pod normes de sécurité sur Pods dans un espace de noms basé sur des étiquettes d'espace de noms spécifiques qui définissent le niveau d'application. Pour plus d'informations, veuillez consulter normes de sécurité des pods (PSS) et l'admission de sécurité du pod (PSA) dans le Guide des bonnes pratiques Amazon EKS.

• L'imagekube-proxy déployée avec des clusters est désormais l'image de base minimale gérée par Amazon EKS Distro (EKS-D). L'image contient un minimum de packages et ne possède pas de shell ni de gestionnaire de packages.

• Kubernetes a fait évoluer les conteneurs éphémères vers la version bêta. Les conteneurs éphémères sont des conteneurs temporaires qui s'exécutent dans le même espace de noms qu'un conteneur existant Pod. Vous pouvez les utiliser pour observer l'état de Pods et des conteneurs pour les besoins de dépannage et de débogage. Ceci est particulièrement utile pour le dépannage interactif lorsque kubectl exec est insuffisant parce qu'un conteneur a planté ou qu'une image de conteneur n'inclut pas d'utilitaires de débogage. Voici un exemple de conteneur comprenant un utilitaire de débogage :images sans distroless. Pour plus d'informations, veuillez consulter Débogage avec un conteneur de débogage éphémère dans la documentation Kubernetes.

• Kubernetes a fait évoluer l'API stable de HorizontalPodAutoscaler autoscaling/v2 pour une disponibilité générale. L'API HorizontalPodAutoscaler autoscaling/v2beta2 est obsolète. Elle sera indisponible dans 1.26.

• 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 version 1.23 de Amazon EKS a activé l'indicateur goaway-chance. Si votre charge de travail exécutée sur le cluster Amazon EKS utilise un client qui n'est pas compatible avec HTTP 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.23, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#changelog-since-v1220.