Container Compute Service:Notes de version de Kubernetes 1.33

Versions des composants

Le tableau suivant répertorie les versions prises en charge pour les composants principaux d'un cluster ACS.

Remarques importantes

En raison d'optimisations apportées au produit ACS, vous devez accorder le rôle lié au service requis à Container Service for Kubernetes (ACK) lors de la création de clusters en version 1.33.3-aliyun.1 ou ultérieure.

Modifications avec rupture de compatibilité

Lors de la création d'une demande de volume persistant NAS, l'option ne prend plus en charge Use Mount Target Domain Name. Sélectionnez désormais ou à la place.

Évolutions des fonctionnalités

• La fonctionnalité In-place Pod Vertical Scaling passe en phase Beta et est activée par défaut. Elle permet de modifier dynamiquement les configurations de ressources CPU et mémoire d'un conteneur sans redémarrer le Pod.

• kubectl prend désormais en charge l'indicateur --subresources pour modifier des sous-ressources spécifiques. Par exemple, utilisez kubectl edit pod <pod-name> --subresource resize pour redimensionner dynamiquement les ressources d'un Pod. Les sous-ressources prises en charge dans la version 1.33 incluent status, scale et resize.

• EndpointSlice TopologyAwareHints atteint le stade de disponibilité générale (GA). L'annotation Beta service.kubernetes.io/topology-mode est obsolète. Nous recommandons d'utiliser le champ spec.trafficDistribution pour définir la politique de topologie. Ainsi, en définissant trafficDistribution sur PreferClose, le trafic est routé de manière préférentielle vers les endpoints situés dans la même zone que le client. Pour plus d'informations, consultez Traffic distribution.

• Le champ Pod .status.resize est obsolète et ne peut plus être défini. Deux nouveaux champs de condition ont été ajoutés : PodResizeInProgress et PodResizePending.

• Le champ .spec.serviceName pour les StatefulSets est désormais facultatif. La validation de ce champ est plus stricte et doit respecter la norme DNS-1123. Si un StatefulSet existant possède un champ .spec.serviceName qui échoue à cette validation, aucun nouveau Pod ne pourra être créé tant que vous n'aurez pas supprimé manuellement ce champ. Cette mise à jour déplace la validation DNS de l'étape de création du Pod vers l'étape de configuration du StatefulSet, ce qui réduit les échecs de nouvelle tentative par le contrôleur StatefulSet.

• Le plugin de volume Git-Repo est désactivé par défaut. Pour continuer à l'utiliser, activez le feature gate GitRepoVolumeDriver.

• La version 1.33.3-aliyun.1 inclut des correctifs pour les CVE-2025-4563.

Nouvelles fonctionnalités

• Les conteneurs sidecar passent en disponibilité générale (GA) et sont activés par défaut. Un conteneur sidecar est un type particulier de conteneur d'initialisation qui utilise restartPolicy: Always pour garantir son exécution pendant tout le cycle de vie du Pod, tout en prenant en charge les configurations de sondes.

• OrderedNamespaceDeletion passe en phase Beta. Cette fonctionnalité optimise le processus de nettoyage des ressources d'un namespace. Lors de la suppression d'un namespace, les Pods de charge de travail sont arrêtés en premier, suivis par les ressources dépendantes telles que les NetworkPolicies et les ressources de stockage. Cela empêche les Pods de rester actifs après la suppression de ressources de sécurité critiques.

• SupplementalGroupsPolicy passe en phase Beta et est activé par défaut. Il permet un contrôle granulaire des groupes supplémentaires pour un Pod via le champ .spec.securityContext.supplementalGroupsPolicy. Cela offre un contrôle plus précis des permissions d'accès aux volumes. Pour plus d'informations, consultez Configure fine-grained SupplementalGroups control for a Pod.

• MultiCIDRServiceAllocator atteint le stade GA et est activé par défaut. Il introduit les ressources ServiceCIDR et IPAddress pour suivre les allocations ClusterIP des services, permettant ainsi d'étendre dynamiquement la plage de ClusterIP assignables via ServiceCIDR.

• JobBackoffLimitPerIndex passe en disponibilité générale (GA). Cette fonctionnalité permet de spécifier le nombre maximal de tentatives de Pod pour chaque index d'un Job indexé.

• JobSuccessPolicy atteint également le stade GA. Elle permet de définir une politique de succès personnalisée pour un Job, par exemple en déterminant l'achèvement du Job en fonction de la réussite d'index spécifiques et du nombre total d'index réussis. Pour plus d'informations, consultez Job's SuccessPolicy Goes GA.

• ImageVolume passe en phase Beta et est désactivé par défaut. Pour utiliser cette fonctionnalité, activez manuellement les feature gates correspondants sur le serveur API et le kubelet. Cela permet aux Pods d'utiliser une source de volume image, qui monte une image de conteneur en tant que volume en lecture seule.

• UserNamespacesSupport passe en phase Beta et est activé par défaut. Cette fonctionnalité permet à un Pod d'utiliser les namespaces utilisateurs Linux pour renforcer la sécurité des conteneurs. Ce changement n'affecte pas les Pods existants. Pour l'utiliser, spécifiez manuellement pod.spec.hostUsers. Pour plus d'informations, consultez User Namespaces enabled by default.

• RelaxedDNSSearchValidation passe en phase Beta et est activé par défaut. Il autorise l'utilisation de caractères spéciaux, tels que . et _, dans le champ .spec.dnsConfig.searches d'un Pod, offrant ainsi une plus grande flexibilité dans la configuration DNS.

• Le kube-apiserver désactive désormais le mécanisme WatchList par défaut au profit d'un mécanisme d'encodage en streaming (incluant StreamingCollectionEncodingToJSON et StreamingCollectionEncodingToProtobuf). Cela améliore les performances des opérations List en diffusant en streaming les requêtes de listes de ressources volumineuses. Pour les requêtes List impliquant de nombreuses ressources, ce changement peut réduire considérablement la consommation de mémoire et améliorer la stabilité du système. Pour plus d'informations, consultez Streaming List responses.

  Le kube-controller-manager n'active plus la fonctionnalité WatchListClient par défaut.

• CPUManagerPolicyOptions passe en disponibilité générale (GA) et est activé par défaut. Cette fonctionnalité permet d'affiner les politiques d'allocation de ressources du CPU Manager :

  • Lorsqu'un Pod nécessite des CPU exclusifs, l'alignement SMT est appliqué pour garantir que les CPU alloués occupent des cœurs physiques complets. Pour plus d'informations, consultez cpu manager extension to reject non SMT-aligned workload.

  • Si des CPU doivent être alloués sur plusieurs nœuds NUMA, vous pouvez garantir une répartition équitable des ressources CPU entre ces nœuds. Pour plus d'informations, consultez Add CPUManager policy option to distribute CPUs across NUMA nodes instead of packing them.

• MatchLabelKeysInPodAffinity atteint le stade GA et est activé par défaut. Il ajoute les champs matchLabelKeys et mismatchLabelKeys aux règles d'affinité des Pods, offrant un contrôle plus précis de la colocalisation des Pods.

• NodeInclusionPolicyInPodTopologySpread passe en disponibilité générale (GA) et est activé par défaut. Il permet d'utiliser nodeAffinityPolicy et nodeTaintsPolicy dans les contraintes de répartition topologique des Pods pour filtrer dynamiquement les nœuds planifiables.

  • nodeAffinityPolicy : La valeur par défaut est Honor. Seuls les nœuds correspondant au nodeSelector ou à l'nodeAffinity du Pod sont inclus dans le calcul de répartition topologique.

  • nodeTaintsPolicy : La valeur par défaut est Ignore. Tous les nœuds sont inclus dans le calcul de répartition topologique, indépendamment des règles nodeAffinity et nodeSelector du Pod.

• HonorPVReclaimPolicy passe en disponibilité générale (GA) et est activé par défaut. Cela garantit que lorsque la reclaimPolicy d'un volume persistant est définie sur Delete, la ressource de stockage sous-jacente est supprimée conformément à la politique, quel que soit l'ordre de suppression du PV ou du PVC. Cela prévient les fuites de ressources de stockage.

• ProcMountType passe en phase Beta. Il permet de personnaliser le type de montage du système de fichiers /proc dans un conteneur via le champ securityContext.procMount d'un Pod. Cela permet un contrôle granulaire de l'accès au système de fichiers /proc, renforçant ainsi la sécurité et l'isolation des Pods. Cette fonctionnalité est utile pour exécuter des conteneurs non privilégiés dans des namespaces utilisateurs, où l'assouplissement des restrictions /proc peut améliorer la compatibilité et la flexibilité.

• PodLifecycleSleepActionAllowZero passe en phase Beta. Il permet de définir à 0 le temps d'attente d'une action sleep dans le hook de cycle de vie preStop d'un conteneur.

• Vous pouvez désormais utiliser un ResourceQuota pour limiter le nombre de demandes de volumes persistants associées à une classe d'attributs de volume spécifique.

• Optimisations des performances du planificateur :

  • La nouvelle fonctionnalité SchedulerPopFromBackoffQ est activée par défaut. Elle optimise la logique de file d'attente de planification en permettant à un Pod d'être extrait directement de la backoffQ lorsque l'activeQ est vide, réduisant ainsi considérablement la latence de planification des Pods.

  • SchedulerAsyncPreemption passe en phase Beta et est activé par défaut. Il permet d'effectuer la préemption de manière asynchrone. La préemption étant une opération gourmande en ressources, son exécution asynchrone permet de réduire efficacement la latence de planification.

  • Les performances de planification pour les Pods utilisant des contraintes de répartition topologique sont optimisées.

API obsolètes

• La version 1.33 utilise containerd 2.1 par défaut. Containerd 2.1 ne prend plus en charge l'API CRI v1alpha2. Si vos charges de travail dépendent de cette version d'API, migrez vers l'API CRI v1 pour garantir la compatibilité.

• L'API Endpoints v1 est officiellement obsolète. Nous recommandons d'utiliser l'API EndpointSlice à la place. L'API EndpointSlice est stable depuis la version 1.21 et introduit des fonctionnalités telles que la prise en charge du réseau double pile. Toutefois, l'API Endpoints v1 ne sera pas supprimée pour le moment. Pour plus d'informations, consultez Continuing the transition from Endpoints to EndpointSlices.

• Le groupe d'API apidiscovery.k8s.io/v2beta1 est désactivé. Cette API permet aux clients de découvrir toutes les ressources API enregistrées dans un cluster. Nous recommandons de migrer vers la version stable v2. Les clients plus anciens peuvent automatiquement revenir à l'API v1 non agrégée pour la découverte de services, ils ne tomberont donc pas en panne immédiatement. Cependant, les clients qui ne prennent pas en charge la version v2 devront effectuer plusieurs appels API pour récupérer les données non agrégées complètes, ce qui risque d'augmenter le volume de requêtes et la latence.

Références

Pour consulter le journal des modifications complet de Kubernetes 1.33, reportez-vous au CHANGELOG-1.33 et à l'article Kubernetes v1.33: Octarine.