Container Compute Service:Notes de version Kubernetes 1.26

Notes de mise à niveau

Les composants suivants sont mis à jour dans les clusters ACK pour prendre en charge Kubernetes 1.26.

Analyse de la version

Modifications incompatibles

• Les versions 1.25 et 1.26 de Kubernetes rendent obsolètes un grand nombre d'API bêta. Avant la mise à niveau, assurez-vous que les contrôleurs et applications utilisant ces API bêta ont été mis à jour vers les versions stables correspondantes. Pour plus d'informations, consultez API obsolètes.

• Kubernetes 1.26 abandonne la prise en charge de CRI v1alpha2 et exige que le runtime de conteneurs soit compatible avec CRI v1. Ainsi, Kubernetes 1.26 ne prend plus en charge containerd 1,5 ou antérieur ; la version minimale requise est containerd 1,6. Lors de la mise à niveau d'un cluster, passez d'abord containerd en version 1.6.0 ou supérieure avant de mettre à niveau les nœuds vers Kubernetes 1.26.

• PodSecurityPolicy a été rendue obsolète dans Kubernetes 1.21 puis supprimée dans Kubernetes 1.25. Cette fonctionnalité est complexe à utiliser et risque d'accorder involontairement des autorisations excessives, provoquant ainsi de sérieux problèmes de disponibilité. Pour plus de détails, reportez-vous à The Historical Context of PodSecurityPolicy.

  Si vos clusters utilisent PodSecurityPolicy, appliquez l'un des contrôles d'admission suivants avant leur mise à niveau.

  • Utilisez la fonctionnalité de gestion des politiques fournie par ACK. Celle-ci offre davantage de règles adaptées aux scénarios d'applications Kubernetes et simplifie la configuration des règles. Pour plus d'informations, consultez Configurer les politiques de sécurité des conteneurs.

  • Adoptez le contrôle d'admission Pod Security Admission intégré, plus simple d'utilisation. Pour plus d'informations, consultez Pod Security Admission. Pour savoir comment migrer de PodSecurityPolicy vers le contrôleur d'admission PodSecurity intégré, reportez-vous à Migrate from PodSecurityPolicy to the Built-in PodSecurity Admission Controller.

  • Déployez et configurez un plugin d'admission tiers.

• Les vulnérabilités CVE suivantes ont été corrigées dans la version 1.26.15-aliyunacs.1 :

  • CVE-2023-45288

  • CVE-2024-3177

  • CVE-2024-24786

Nouvelles fonctionnalités

• La fonctionnalité de conteneurs éphémères, en phase bêta depuis Kubernetes 1.23, passe au stade Stable dans Kubernetes 1.25. Lorsqu'un conteneur plante ou ne dispose pas des outils de débogage nécessaires pour exécuter la commande kubectl exec, lancez un conteneur éphémère dans le Pod existant afin d'en vérifier l'état et d'y exécuter des commandes arbitraires. Pour plus d'informations, consultez Ephemeral Containers.

• Dans Kubernetes 1.25, la prise en charge de cgroups v2 passe au stade Stable. Cette version apporte de nombreuses améliorations par rapport à cgroups v1. Pour plus d'informations, consultez cgroup v2.

• Avec Kubernetes 1.25, la prise en charge de Windows continue de s'améliorer, notamment grâce aux tests unitaires, aux tests de conformité et à un nouveau dépôt dédié à la préparation opérationnelle Windows.

• Depuis Kubernetes 1.25, le registre d'images k8s.gcr.io migre vers registry.k8s.io, et le trafic y est automatiquement redirigé. Pour plus d'informations, consultez k8s.gcr.io Redirect to registry.k8s.io.

• Dans Kubernetes 1.25, le champ EndPort des NetworkPolicy atteint la disponibilité générale (GA). Si votre fournisseur de NetworkPolicy prend en charge ce champ, utilisez-le pour définir une plage de ports dans une politique réseau. Dans le cas contraire, seule une politique à port unique sera créée. Pour plus d'informations, consultez Network Policies.

• L'isolation de capacité du stockage éphémère local passe en disponibilité générale (GA) avec Kubernetes 1.25. Cette fonctionnalité permet d'isoler la capacité de stockage éphémère local entre les Pods, par exemple pour les volumes EmptyDir. Ainsi, lorsqu'un Pod dépasse la limite de stockage éphémère local configurée, le kubelet peut l'expulser afin d'appliquer une limite stricte sur sa consommation de ressources partagées. Pour plus d'informations, consultez Local Ephemeral Storage Capacity Isolation.

• Les volumes éphémères CSI passent au stade Stable dans Kubernetes 1.25. Ils permettent de spécifier directement des volumes CSI dans la définition d'un Pod pour un usage temporaire, sans recourir aux PersistentVolumes (PV) ni aux PersistentVolumeClaims (PVC). Pour plus d'informations, consultez CSI Ephemeral Volumes.

• Kubernetes 1.25 introduit l'API KMS v2 alpha1 afin d'améliorer les performances, la rotation des clés et l'observabilité. Cette API remplace AES-CBC par AES-GCM pour chiffrer au repos les Secrets Kubernetes via une clé de chiffrement des données (DEK). Aucune opération supplémentaire n'est requise, et la lecture reste compatible avec AES-GCM comme avec AES-CBC. Pour plus d'informations, consultez Using a KMS provider for data encryption.

• Avec Kubernetes 1.25, une nouvelle interface standard pour le stockage objet fait son apparition : le Container Object Storage Interface (COSI). COSI vise à normaliser l'utilisation du stockage objet et se trouve actuellement en phase alpha.

• Dans Kubernetes v1.25, lorsque la condition PodHasNetwork du champ status d'un Pod est définie sur True, cela indique que le sandbox d'exécution du Pod a été initialisé et créé avec succès, et que le réseau est configuré. Le Kubelet ne commence à télécharger les images et à démarrer les conteneurs qu'une fois cette condition remplie. Elle constitue donc une métrique fiable pour mesurer la latence d'initialisation du Pod, indépendamment de la vitesse de téléchargement des images ou du chargement de l'application, ce qui permet de générer des indicateurs de niveau de service (SLI) précis. Étant donné que PodHasNetwork est encore en phase alpha, activez le feature gate PodHasNetworkCondition sur le Kubelet pour l'utiliser. Pour plus d'informations, consultez the difference between PodHasNetwork and Initialized.

• Le champ minReadySeconds des StatefulSets passe au stade Stable dans Kubernetes 1.25. Il permet d'imposer un délai d'attente à chaque Pod, ralentissant ainsi la mise à jour progressive d'un StatefulSet. Pour plus d'informations, consultez Minimum Ready Seconds.

• Dans Kubernetes 1.25, le champ maxSurge des DaemonSets atteint le stade Stable. Il autorise l'exécution simultanée de plusieurs instances du même Pod sur un nœud pendant une mise à jour progressive, réduisant ainsi les temps d'arrêt du DaemonSet. Notez que les champs maxSurge et hostPort sont mutuellement exclusifs, car deux Pods actifs ne peuvent pas partager le même port sur un même nœud. Pour plus d'informations, consultez Perform a Rolling Update on a DaemonSet.

• Une fonctionnalité alpha de Kubernetes 1.25 permet d'exécuter des Pods dans un namespace utilisateur. L'utilisateur root du Pod est alors mappé à un ID non nul hors du conteneur. Le Pod s'exécute donc en tant que root du point de vue du conteneur, mais en tant qu'utilisateur non privilégié classique du point de vue de l'hôte. Cette fonctionnalité étant en phase alpha, son utilisation requiert l'activation du feature gate UserNamespacesStatelessPodsSupport ainsi qu'un runtime de conteneurs compatible. Pour plus d'informations, consultez Alpha support for running Pods with user namespaces.

• Kubernetes 1.25 introduit le feature gate RetroactiveDefaultStorageClass, qui modifie l'attribution de la StorageClass par défaut à un PVC. Auparavant, il fallait créer la StorageClass avant le PVC pour que l'attribution fonctionne ; sinon, la StorageClass du PVC restait nulle. Une fois cette fonctionnalité activée, les PVC sans StorageClass assignée reçoivent automatiquement la StorageClass par défaut sans nécessiter de recréation. Promue au stade bêta dans Kubernetes 1.26, elle est activée par défaut.

• La fonctionnalité JobPodFailurePolicy, ajoutée dans Kubernetes 1.25, permet de configurer la manière dont un Job gère les échecs de Pods en fonction des codes de sortie des conteneurs et des conditions du Pod. Elle passe au stade bêta dans Kubernetes 1.26. Configurez le champ podFailurePolicy dans la définition du Job pour définir une politique d'échec, évitant ainsi les tentatives inutiles et ignorant les expulsions de Pods. Pour plus d'informations, consultez Pod failure policy.

• Un problème lié à PodTopologySpread, qui provoquait une répartition inégale des Pods en violation des contraintes lors des mises à jour progressives, a été corrigé dans Kubernetes 1.25. Le champ minDomains passe quant à lui en phase bêta.

• Les performances de kube-proxy ont été améliorées pour les grands clusters dans Kubernetes 1.25. Par exemple, dans un cluster comptant 1 000 Endpoints, les règles iptables inutilisées sont conservées pendant une période de synchronisation maximale complète, ce qui dispense de leur analyse à chaque cycle. Pour les clusters plus petits, ces règles continuent d'être supprimées immédiatement.

• Kubernetes 1.26 introduit la fonctionnalité d'allocation dynamique des ressources, permettant de demander et de partager des ressources entre Pods ou entre conteneurs d'un même Pod. Les utilisateurs peuvent initialiser ces ressources en fournissant des paramètres spécifiques. Actuellement en phase alpha, cette fonctionnalité nécessite l'activation du feature gate DynamicResourceAllocation ainsi que du groupe d'API resource.k8s.io/v1alpha1, et l'installation d'un pilote adapté aux ressources à gérer. Pour plus d'informations, consultez Alpha API For Dynamic Resource Allocation.

• Dans Kubernetes 1.26, l'arrêt non progressif des nœuds passe en phase bêta. En cas de panne d'un nœud, les Pods qui s'y trouvent restent bloqués à l'état Terminating et les VolumeAttachments ne peuvent pas être supprimés. Pour les Pods d'un StatefulSet, aucun nouveau Pod ne peut démarrer sur un autre nœud, car les noms doivent rester uniques. Contrairement à l'arrêt progressif des nœuds, géré automatiquement par le Kubelet lors de la détection d'un événement d'arrêt, l'arrêt non progressif exige l'ajout manuel d'un taint out-of-service au nœud concerné. Cela déclenche la migration des Pods vers d'autres nœuds opérationnels. Une fois le nœud rétabli, retirez manuellement ce taint.

• Depuis Kubernetes 1.26, le fsGroup du Pod peut être transmis aux pilotes CSI lors du montage. Le pilote CSI, plutôt que le kubelet, peut alors modifier les permissions des fichiers et répertoires du volume. Cette évolution est largement transparente pour les utilisateurs. Si vous développez un pilote CSI, consultez CSI Driver fsGroup Support.

• Introduite dans Kubernetes 1.26, la fonctionnalité de barrières de planification des Pods (scheduling gates) indique au planificateur le moment opportun pour planifier un Pod. Lorsque de nombreux Pods sont bloqués par des événements externes et restent en attente prolongée, les performances du planificateur peuvent en pâtir. Les barrières de planification résolvent ce problème en permettant de déclarer qu'un Pod nouvellement créé n'est pas encore prêt à être planifié. Si le champ spec.schedulingGates est défini pour un Pod, le planificateur l'ignore, évitant ainsi des tentatives inutiles. Un contrôleur externe doit déterminer quand le Pod est prêt et lever les barrières. Pour plus d'informations, consultez Pod Scheduling Gates.

• Le cpu manager atteint la disponibilité générale (GA) dans Kubernetes 1.26. En phase bêta depuis Kubernetes v1.10, ce composant du kubelet alloue des CPU exclusifs aux conteneurs selon trois options de politique. Pour plus d'informations, consultez Control CPU Management Policies on the Node.

• Kubernetes 1.26 introduit une prise en charge alpha des sources de données de stockage inter-namespaces. Spécifiez ainsi une source de données pour un PVC même si celle-ci réside dans un namespace différent. Pour plus d'informations, consultez Cross-Namespace Storage Data Sources.

• Dans Kubernetes v1.26, configurez une politique d'expulsion pour les Pods défaillants dans un PodDisruptionBudget. Définir .spec.unhealthyPodEvictionPolicy=AlwaysAllow permet d'expulser ces Pods sans blocage par le PDB. Cette fonctionnalité, actuellement en phase alpha, nécessite l'activation du feature gate PDBUnhealthyPodEvictionPolicy. Pour plus d'informations, consultez Unhealthy Pod Eviction Policy.

• Dans Kubernetes v1.26, les handlers httpGet des hooks de cycle de vie de conteneur preStop et postStart respectent désormais les champs scheme et headers. Leur comportement s'aligne ainsi sur celui des probes, permettant l'utilisation de headers personnalisés et de HTTPS. Si HTTPS est utilisé alors que HTTP est attendu, une erreur est journalisée et le handler revient à HTTP pour préserver la compatibilité ascendante. Pour désactiver cette fonctionnalité sur le Kubelet, utilisez le paramètre --feature-gates=ConsistentHTTPGetHandlers=false.

• Avec Kubernetes v1.26, API Priority and Fairness (APF) permet d'emprunter des places à d'autres niveaux de priorité. Deux nouveaux champs apparaissent dans .spec.limited : lendablePercent définit le pourcentage de places pouvant être prêtées, tandis que borrowingLimitPercent fixe le pourcentage maximal de places empruntables auprès d'autres niveaux de priorité.

• Dans Kubernetes v1.26, le composant kube-controller-manager accepte le paramètre --concurrent-horizontal-pod-autoscaler-syncs pour définir le nombre de workers du contrôleur HPA (Horizontal Pod Autoscaler).

• Kubernetes 1.26 ajoute une validation des sélecteurs de libellés pour le HPA. Lorsque plusieurs HPA ciblent le même ensemble de Pods ou le même déploiement, ils deviennent inopérants et le système génère un événement AmbiguousSelector.

• Depuis Kubernetes v1.26, si plusieurs StorageClasses sont marquées comme par défaut (via l'annotation storageclass.kubernetes.io/is-default-class), la plus récente est sélectionnée automatiquement au lieu de générer une exception.

Fonctionnalités obsolètes

• Obsolescence et suppression de pilotes de stockage

  • Dans Kubernetes 1.25, les plugins de volume intégrés (in-tree) sont supprimés au profit de l'intégration CSI. La migration CSI résulte d'un effort continu du SIG Storage visant à externaliser le code des plugins de volume vers des pilotes CSI indépendants. Avec Kubernetes 1.25, la migration CSI principale est désormais stable.

  • Dans Kubernetes 1.25, les plugins de volume intégrés GlusterFS et Portworx sont rendus obsolètes, tandis que les plugins Flocker, Quobyte et StorageOS sont supprimés. Le pilote de volume vSphere intégré ne prend plus en charge les versions de vSphere antérieures à 7.0u2.

  • Avec Kubernetes 1.26, le pilote intégré GlusterFS est supprimé, tout comme l'intégration de stockage OpenStack intégrée (type de volume Cinder), déjà obsolète.

• Nettoyage de la propriété des chaînes iptables

  Kubernetes crée généralement des chaînes iptables pour garantir la bonne livraison des paquets réseau. Ces chaînes et leurs noms constituent des détails d'implémentation internes réservés à un usage interne. Certains composants s'appuient actuellement sur ces détails, mais Kubernetes ne prévoit pas de prendre en charge les outils qui en dépendent. Pour plus d'informations, consultez Kubernetes's IPTables Chains Are Not API.

  À partir de Kubernetes 1.25, le kubelet utilise le feature gate IPTablesCleanup pour migrer progressivement vers l'arrêt de la création de chaînes iptables dans la table NAT, telles que KUBE-MARK-DROP, KUBE-MARK-MASQ et KUBE-POSTROUTING.

  Pour plus d'informations sur le nettoyage de la propriété des chaînes iptables, consultez Cleaning up iptables chain ownership.

• Suppression du code de gestion des identifiants intégré

  Depuis Kubernetes 1.26, le code d'authentification spécifique aux fournisseurs (Azure et Google Cloud) intégré à client-go et kubectl a été supprimé. Utilisez plutôt le mécanisme de plugins d'authentification. Pour plus d'informations, consultez Authentication plugins.

• Suppression de composants kube-proxy

  • Le mode proxy Userspace a été supprimé dans Kubernetes 1.26. Ce mode obsolète n'est plus pris en charge ni sous Linux ni sous Windows. Les utilisateurs Linux doivent utiliser iptables ou IPVS, et les utilisateurs Windows doivent opter pour Kernelspace. L'utilisation de --mode userspace échouera désormais.

  • Le kube-proxy winkernel Windows ne prend plus en charge les API Windows HNS v1.

• Obsolescence du paramètre --prune-whitelist de kubectl

  Dans Kubernetes 1.26, conformément à l'Inclusive Naming Initiative, le paramètre --prune-whitelist est rendu obsolète et remplacé par --prune-allowlist. Il sera complètement supprimé dans une version future.

• Suppression de la configuration dynamique du Kubelet

  Le feature gate DynamicKubeletConfig a été supprimé. Cette fonctionnalité permettait de mettre à jour dynamiquement la configuration du kubelet sur un nœud via une API. Le code associé a été retiré du kubelet dans Kubernetes 1.24, puis de l'API server dans Kubernetes 1.26. Cette suppression simplifie le code et améliore la fiabilité. Modifiez plutôt le fichier de configuration du kubelet et redémarrez-le. Pour plus d'informations, consultez Remove Dynamic Kubelet Configuration from the API server.

• Suppression de paramètres de ligne de commande

  • Dans Kubernetes 1.25, UnversionedKubeletConfigMap de kubeadm atteint la disponibilité générale (GA). Par défaut, kube-system ou kubelet-config est utilisé à la place de kube-system ou kubelet-config-x.yy.

  • Depuis Kubernetes 1.25, kubeadm n'applique plus le taint node-role.kubernetes.io/master:NoSchedule aux nœuds du plan de contrôle. Ce taint est également supprimé lors de l'exécution de kubeadm upgrade apply.

  • Dans Kubernetes 1.25, les annotations Seccomp seccomp.security.alpha.kubernetes.io/pod et container.seccomp.security.alpha.kubernetes.io ne sont plus prises en charge. Utilisez plutôt SeccompProfile. Pour plus d'informations, consultez Restrict a Container's Syscalls with seccomp.

  • Dans Kubernetes 1.25 et 1.26, certains paramètres de démarrage de kube-controller-manager sont rendus obsolètes ou supprimés.

    • Les paramètres deleting-pods-qps, deleting-pods-burst et register-retry-count sont supprimés.

    • Les paramètres experimental-cluster-signing-duration et pod-eviction-timeout sont rendus obsolètes et remplacés par cluster-signing-duration.

    • Dans Kubernetes 1.27, pod-eviction-timeout et enable-taint-manager seront supprimés conjointement.

  • Dans Kubernetes 1.26, plusieurs paramètres de ligne de commande liés aux journaux, déjà rendus obsolètes dans les versions précédentes, sont supprimés.

  • Le paramètre de ligne de commande --master-service-namespace est rendu obsolète dans Kubernetes 1.26. Il n'a aucun effet sur l'API server.

  • Dans Kubernetes 1.26, plusieurs paramètres inutilisés de kubectl run sont marqués comme obsolètes et seront supprimés dans une version future. Ces paramètres incluent --cascade, --filename, --force, --grace-period, --kustomize, --recursive, --timeout et --wait.

API obsolètes

Les API suivantes sont rendues obsolètes dans Kubernetes 1.25 et 1.26. Pour plus d'informations, consultez le Guide de migration des API obsolètes.

• CronJob

  Depuis Kubernetes 1.25, la version d'API batch/v1beta1 de CronJob n'est plus servie. Utilisez la version batch/v1, disponible depuis Kubernetes 1.21.

• EndpointSlice

  Depuis Kubernetes 1.25, la version d'API discovery.k8s.io/v1beta1 d'EndpointSlice n'est plus servie. Utilisez la version discovery.k8s.io/v1, disponible depuis Kubernetes 1.21.

  La liste suivante décrit les changements notables dans discovery.k8s.io/v1.

  • Le champ NodeName est utilisé pour chaque Endpoint à la place du champ obsolète topology["kubernetes.io/hostname"].

  • Le champ Zone est utilisé pour chaque Endpoint à la place du champ obsolète topology["kubernetes.io/zone"].

  • Le champ Topology est remplacé par le champ deprecatedTopology et n'est plus modifiable dans la version d'API v1.

• Event

  Depuis Kubernetes 1.25, la version d'API events.k8s.io/v1beta1 d'Event n'est plus servie. Utilisez la version events.k8s.io/v1, disponible depuis Kubernetes v1.19.

  La liste suivante décrit les changements notables dans events.k8s.io/v1.

  • Le champ type accepte uniquement les valeurs Normal ou Warning.

  • Le champ involvedObject a été renommé en regarding.

  • Lors de la création d'un nouvel Event events.k8s.io/v1, les champs action, reason, reportingController et reportingInstance sont tous obligatoires.

  • Utilisez le champ eventTime à la place du champ obsolète firstTimestamp. Ce dernier a été renommé en deprecatedFirstTimestamp et n'est plus autorisé dans les nouveaux objets Event events.k8s.io/v1.

  • Utilisez le champ series.lastObservedTime à la place du champ obsolète lastTimestamp. Le champ lastTimestamp a été renommé en deprecatedLastTimestamp et n'est plus autorisé dans les nouveaux objets Event events.k8s.io/v1.

  • Utilisez le champ series.count à la place du champ obsolète count. Le champ count a été renommé en deprecatedCount et n'est plus autorisé dans les nouveaux objets Event events.k8s.io/v1.

  • Utilisez le champ reportingController à la place du champ obsolète source.component. Le champ source.component a été renommé en deprecatedSource.component et n'est plus autorisé dans les nouveaux objets Event events.k8s.io/v1.

  • Utilisez le champ reportingInstance à la place du champ obsolète source.host. Le champ source.host a été renommé en deprecatedSource.host et n'est plus autorisé dans les nouveaux objets Event events.k8s.io/v1.

• PodDisruptionBudget

  Depuis Kubernetes 1.25, la version d'API policy/v1beta1 de PodDisruptionBudget n'est plus disponible. Utilisez la version policy/v1, disponible depuis Kubernetes 1.21.

  Un changement notable dans policy/v1 concerne la définition de spec.selector sur une valeur vide ({}) : celle-ci sélectionne désormais tous les Pods du namespace. Dans la version policy/v1beta1, un spec.selector vide ne sélectionnait aucun Pod. Si spec.selector n'est pas défini, aucun Pod n'est sélectionné, quelle que soit la version d'API.

• PodSecurityPolicy

  À partir de Kubernetes v1.25, PodSecurityPolicy n'est plus disponible via l'API policy/v1beta1. Le contrôleur d'admission PodSecurityPolicy a également été supprimé. Migrez vers Pod Security Admission ou vers un webhook d'admission tiers.

  Pour consulter un guide de migration, reportez-vous à Migrate from PodSecurityPolicy to the Built-in PodSecurity Admission Controller. Pour plus d'informations sur cette obsolescence, consultez PodSecurityPolicy Deprecation: Past, Present, and Future.

• RuntimeClass

  Depuis Kubernetes v1.25, la version d'API node.k8s.io/v1beta1 de RuntimeClass n'est plus prise en charge. Utilisez la version node.k8s.io/v1, disponible depuis Kubernetes v1.20.

• HorizontalPodAutoscaler

  • Depuis Kubernetes 1.25, la version d'API autoscaling/v2beta1 de HorizontalPodAutoscaler n'est plus disponible.

  • Depuis Kubernetes 1.26, la version d'API autoscaling/v2beta2 de HorizontalPodAutoscaler n'est plus disponible. Utilisez la version autoscaling/v2, disponible depuis Kubernetes 1.23.

• Ressources de contrôle de flux

  Depuis Kubernetes v1.26, la version d'API flowcontrol.apiserver.k8s.io/v1beta1 n'est plus servie pour les ressources FlowSchema et PriorityLevelConfiguration. L'API flowcontrol.apiserver.k8s.io/v1beta2 est disponible depuis Kubernetes v1.23, et l'API flowcontrol.apiserver.k8s.io/v1beta3 est introduite dans Kubernetes v1.26.

Feature gates

Les feature gates comportent généralement trois phases : Alpha, Bêta et GA. Une fonctionnalité est désactivée par défaut en phase Alpha, généralement activée par défaut en phase Bêta, et toujours activée par défaut en phase GA. À ce stade, elle ne peut plus être désactivée et son option de bascule est supprimée dans une version ultérieure. Voici quelques-uns des changements majeurs. Pour plus d'informations, consultez Feature Gates.

• Dans Kubernetes 1.25, SeccompDefault passe en phase Bêta. Pour savoir comment utiliser SeccompDefault, consultez Restrict a Container's Syscalls with seccomp.

• Le langage d'expression de validation des Custom Resource Definitions (CRD) passe en phase Bêta dans Kubernetes 1.25, et CustomResourceValidationExpressions est activé par défaut. L'utilisation du Common Expression Language (CEL) pour valider les ressources personnalisées est plus pratique et efficace que le recours aux webhooks. Pour plus d'informations, consultez Validation rules.

• Dans Kubernetes 1.25, le feature gate ServerSideFieldValidation passe en phase Bêta et est activé par défaut. L'API server prend désormais en charge la validation des champs inconnus, ce qui permettra à terme de retirer cette fonctionnalité de kubectl. Pour plus d'informations, consultez Server-side field validation.

• Kubernetes 1.25 introduit la nouvelle fonctionnalité Alpha ContainerCheckpoint, qui active l'API Checkpoint du Kubelet. Pour plus d'informations, consultez Kubelet Checkpoint API.

• La nouvelle fonctionnalité Alpha PodHasNetworkCondition fait son apparition dans Kubernetes 1.25. Elle permet au Kubelet de marquer un Pod avec la condition PodHasNetwork. Pour plus d'informations, consultez PodHasNetwork.

• Kubernetes 1.25 introduit la nouvelle fonctionnalité Alpha UserNamespacesStatelessPodsSupport pour activer la prise en charge des namespaces utilisateurs pour les Pods sans état.

• La nouvelle fonctionnalité Alpha JobPodFailurePolicy est ajoutée dans Kubernetes 1.25. Elle permet de configurer la gestion des échecs de Pods par un Job en fonction des codes de sortie des conteneurs et des conditions du Pod. Cette fonctionnalité passe en phase Bêta dans Kubernetes 1.26.

• Kubernetes 1.25 introduit la nouvelle fonctionnalité Alpha MultiCIDRRangeAllocator, permettant à NodeIPAM de gérer plusieurs ClusterCIDR. Pour activer la prise en charge par le contrôleur, configurez kube-controller-manager avec --cidr-allocator-type=MultiCIDRRangeAllocator.

• Dans Kubernetes 1.25, StatefulSetMinReadySeconds passe en phase GA. Le champ minReadySeconds est pris en charge par défaut pour les StatefulSets et ne peut pas être désactivé.

• Dans Kubernetes 1.25, CronJobTimeZone passe en phase Bêta. Le champ TimeZone est utilisable par défaut dans les CronJobs et ne peut pas être désactivé.

• Dans Kubernetes 1.25, DaemonSetUpdateSurge passe en phase GA. Le champ MaxSurge est utilisable par défaut dans les DaemonSets et ne peut pas être désactivé.

• Dans Kubernetes 1.25, IdentifyPodOS passe en phase GA. Le champ spec.podOS est activé par défaut et ne peut pas être désactivé.

• Dans Kubernetes 1.25, CSIInlineVolume passe en phase GA. La prise en charge des volumes inline CSI est activée par défaut et ne peut pas être désactivée.

• Dans Kubernetes 1.25, EphemeralContainers passe en phase GA. La prise en charge des conteneurs éphémères est activée par défaut et ne peut pas être désactivée.

• Kubernetes 1.25 introduit la nouvelle fonctionnalité CSINodeExpandSecret, permettant de transmettre des données d'authentification secrètes à un pilote CSI lors de l'ajout d'un nœud.

• Dans Kubernetes 1.25, CSIMigration passe en phase GA. Cette fonctionnalité est activée par défaut et ne peut pas être désactivée.

• Dans Kubernetes 1.25, CSIMigrationPortworx passe en phase Bêta.

• Dans Kubernetes 1.25, ProbeTerminationGracePeriod reste en phase Bêta, mais sa valeur par défaut passe à true. Pour plus d'informations, consultez Probe-level terminationGracePeriodSeconds.

• Dans Kubernetes 1.26, JobTrackingWithFinalizers passe en phase GA. Par défaut, l'achèvement des Jobs est suivi via des finalizers plutôt que par le décompte des Pods restants. Pour plus d'informations, consultez Job tracking with finalizers.

• Kubernetes 1.26 introduit la nouvelle fonctionnalité Alpha PDBUnhealthyPodEvictionPolicy, permettant de spécifier une politique d'expulsion pour les Pods défaillants dans un PodDisruptionBudget.

• Dans Kubernetes 1.26, la prise en charge de l'API d'allocation dynamique des ressources est activée. Elle permet de gérer et d'utiliser des ressources dotées de paramètres personnalisés, indépendantes du cycle de vie des Pods.

• Kubernetes 1.26 introduit la nouvelle fonctionnalité Alpha StatefulSetStartOrdinal, permettant de configurer l'ordinal de départ d'un StatefulSet.

• Dans Kubernetes 1.26, ServiceInternalTrafficPolicy passe en phase GA. Elle permet d'utiliser le champ internalTrafficPolicy pour configurer la politique de trafic interne d'un Service. Cette fonctionnalité est activée par défaut et ne peut pas être désactivée. Pour plus d'informations, consultez Service Traffic Policy.

• Kubernetes 1.26 introduit la nouvelle fonctionnalité Alpha ValidatingAdmissionPolicy, qui implémente un contrôleur d'admission extensible basé sur des expressions CEL.

• Dans Kubernetes 1.26, MixedProtocolLBService passe en phase GA. Elle permet d'utiliser différents protocoles au sein d'une même instance de Service de type LoadBalancer.

• Dans Kubernetes 1.26, EndpointSliceTerminatingCondition passe en phase GA. Elle permet d'utiliser les champs de condition Terminating et Serving d'un EndpointSlice. Cette fonctionnalité ne peut pas être désactivée.

• Dans Kubernetes 1.26, APIServerIdentity passe en phase Bêta. Par défaut, un Lease est créé dans le namespace kube-system pour chaque API server actif.

• Dans Kubernetes 1.26, DelegateFSGroupToCSIDriver passe en phase GA et ne peut pas être désactivé.

• Dans Kubernetes 1.26, NodeOutOfServiceVolumeDetach passe en phase Bêta et est activé par défaut. Lorsqu'un nœud est marqué hors service avec le taint node.kubernetes.io/out-of-service, les Pods qui ne tolèrent pas ce taint sont supprimés de force. Le détachement des volumes est immédiatement effectué pour les Pods terminés sur ce nœud.

• Dans Kubernetes 1.26, ServiceIPStaticSubrange passe en phase GA. Cette fonctionnalité permet à la stratégie d'allocation des ClusterIP de subdiviser la plage d'adresses ClusterIP.

• Dans Kubernetes 1.26, CPUManager et DevicePlugins passent en phase GA. Ces fonctionnalités sont activées par défaut et ne peuvent pas être désactivées.

• Kubernetes 1.26 introduit la nouvelle fonctionnalité Alpha ComponentSLIs, qui active l'endpoint /metrics/slis sur les composants Kubernetes tels que kubelet, kube-scheduler, kube-proxy, kube-controller-manager et cloud-controller-manager, permettant ainsi la collecte de métriques de vérification de santé.

• Dans Kubernetes 1.26, WindowsHostProcessContainers passe en phase GA. La prise en charge des conteneurs Windows HostProcess est activée par défaut.

• Dans Kubernetes 1.26, ExpandedDNSConfig passe en phase Bêta. Elle permet d'utiliser davantage de domaines de recherche DNS et une liste de recherche plus longue, sous réserve de la prise en charge par le runtime.

• Dans Kubernetes 1.26, LegacyServiceAccountTokenNoAutoGeneration passe en phase GA. Cette fonctionnalité met fin à la génération automatique de tokens de compte de service basés sur des Secrets. Elle est activée par défaut et ne peut pas être désactivée.

• Dans Kubernetes 1.26, ProxyTerminatingEndpoints passe en phase Bêta et est activé par défaut. Il permet à kube-proxy de gérer les endpoints en cours de terminaison lorsque ExternalTrafficPolicy est défini sur Local.

• Kubernetes 1.26 introduit la nouvelle fonctionnalité Alpha LegacyServiceAccountTokenTracking, désactivée par défaut. Elle ajoute le libellé kubernetes.io/legacy-token-last-used aux Secrets contenant des tokens de compte de service afin d'indiquer leur date d'expiration.

• Dans Kubernetes 1.26, la fonctionnalité PodDisruptionConditions passe en phase Bêta et est activée par défaut. Ajoutez une condition DisruptionTarget au statut d'un Pod pour indiquer que sa suppression résulte d'une interruption. Le champ reason fournit des détails sur la cause de la terminaison. Pour plus d'informations, consultez Pod disruption conditions.

Améliorations pour Kubernetes 1.26

Améliorations de sécurité

Les permissions d'accès aux fichiers Kubernetes sensibles suivants sur les nœuds ont été renforcées.

Références

• CHANGELOG-1.25

• CHANGELOG-1.26