Notes de mise à jour pour les versions bénéficiant du support standard - Amazon EKS

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.

  • Avec Amazon EKS1.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'defaultannotation sur la gp2 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éfaut StorageClass dans le cluster. Vous devez les référencer StorageClass par leur nomgp2. Vous pouvez également déployer la classe de stockage par défaut recommandée par Amazon EBS en définissant le defaultStorageClass.enabled paramètre sur true lors de l'installation v1.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/v1beta2API obsolètes de FlowSchema et dans lesquelles PriorityLevelConfiguration elles ne sont plus diffusées. Kubernetes v1.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é par kubelet - qui ne connaît pas réellement la kube-proxy version, ni même si elle kube-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.

  • Kubernetes1.29Afin de réduire la surface d'attaque potentielle, la LegacyServiceAccountTokenCleanUp 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 (de n-2 à n-3) afin que les composants du nœud (kubelet et kube-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 et cloud-controller-manager) de la version mineure prise en charge la plus récente.

  • Les métriques force_delete_pods_total et force_delete_pod_errors_total du Pod 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 une StorageClass par défaut à toute PersistentVolumeClaim non associée dont le paramètre storageClassName n'est pas défini. En outre, le mécanisme de validation des admissions de PersistentVolumeClaim du serveur d'API a été ajusté pour permettre de remplacer un état non défini par un nom de StorageClass .

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 et container.seccomp.security.alpha.kubernetes.iodes annotations seccomp a été supprimée. Les annotations alpha seccomp sont devenues obsolètes en 1.19, avec leur suppression de 1.27, les champs seccomp ne seront plus remplis automatiquement pour les Pods avec les annotations seccomp. Utilisez plutôt le champ securityContext.seccompProfile réservé aux conteneurs ou Pods pour configurer les profils seccomp. Pour vous assurer que vous utilisez la base d'annotations alpha seccomp 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 pour kubelet 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 de 1.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 Kubernetes 1.27 a augmenté la valeur par défaut kubeAPIQPS à 50 et kubeAPIBurst à 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 de Pods augmentent, en raison des exigences de mise à l'échelle, les valeurs par défaut révisées garantissent la capacité de kubelet à gérer efficacement l'augmentation de la charge de travail. Par conséquent, les lancements Pod 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 que minDomain. Ce paramètre vous permet de spécifier le nombre minimum de domaines sur lesquels vos Pods devez être répartis. nodeAffinityPolicy et nodeTaintPolicy permettent un niveau de granularité supplémentaire dans la gestion de la distribution Pod. Ceci est conforme aux affinités des nœuds, aux rejets et au champ matchLabelKeys dans le topologySpreadConstraints de votre spécification Pod's. Cela permet de sélectionner des Pods pour étaler les calculs après une mise à niveau progressive.

  • Kubernetes1.27 promu en version bêta un nouveau mécanisme de politique StatefulSets contrôlant la durée de vie de leur PersistentVolumeClaims (PVCs). La nouvelle politique de rétention PVC vous permet de spécifier si les données PVCs générées à partir du modèle de spécification StatefulSet seront automatiquement supprimées ou retenues lors de la suppression du StatefulSet ou de la réduction des répliques dans le StatefulSet.

  • 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.27 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.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 version 1.12 ou ultérieure. Si vous n'effectuez pas la mise à niveau vers la version 1.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 version 1.26 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.26, consultez la page https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.26.md#changelog-since-v1250.