Consultez les notes de mise à jour des versions de Kubernetes sur le support étendu

Le .status.kubeProxyVersion champ pour les objets de nœud est désormais obsolète, et le projet Kubernetes 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.

Dans Kubernetes, 1.29 afin de réduire la surface d'attaque potentielle, la LegacyServiceAccountTokenCleanUp fonctionnalité identifie 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 aucune tentative d'utilisation n'est effectué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

Kubernetes v1.28 a étendu l'écart pris en charge 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 (kubeletetkube-proxy) de la version secondaire prise en charge la plus ancienne puissent fonctionner avec les composants du plan de contrôle (kube-apiserver,, kube-schedulerkube-controller-manager,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 PersistentVolumeClaim admissions au sein du serveur API a été ajusté pour permettre de changer les valeurs d'un état non défini à un StorageClass nom réel.

kubeletDans Kubernetes, la valeur par défaut 1.27 a été augmentée à et kubeAPIQPS à50. 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.

Kubernetes 1.27 a promu en version bêta un nouveau mécanisme de politique StatefulSets qui contrôle 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 du serveur d'API Kubernetes permet d'éviter que les connexions HTTP/2 client ne 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 la gestion de votre client en vous GOAWAY reconnectant à la fin de la connexion.

Avant de procéder à la mise à niveau vers Kubernetes1.26, mettez à niveau votre plugin Amazon VPC CNI pour Kubernetes vers la version ou ultérieure. 1.12 Si vous n'effectuez pas la mise à niveau vers le plug-in Amazon VPC CNI pour Kubernetes ou une version ultérieure1.12, le plug-in Amazon VPC CNI pour Kubernetes se bloquera. Pour de plus amples informations, veuillez consulter Attribuer IPs à des pods avec l'Amazon VPC CNI.

L'option goaway-chance du serveur d'API Kubernetes permet d'éviter que les connexions HTTP/2 client ne 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 la gestion de votre client en vous GOAWAY reconnectant à la fin de la connexion.