1.36 Informations sur la version et procédures de mise à jour

Consultez les informations relatives à la version 1.36 du site IBM Cloud® Kubernetes Service. Pour plus d'informations sur la version 1.36 du projet « Kubernetes », consultez le journal des modifications de Kubernetes.

Ce badge indique la certification « Kubernetes » version 1.36 pour IBM Cloud Kubernetes Service
Kubernetes version 1.36 badge de certification

IBM Cloud Kubernetes Service Il s'agit d'un produit certifié « Kubernetes » pour la version 1.36 dans le cadre du programme de certification de conformité logicielle « Kubernetes » de la CNCF. Kubernetes® est une marque The Linux Foundation aux États-Unis et dans d'autres pays, et est utilisée en vertu d'une licence de la Fondation Linux.

Calendrier de diffusion

Le tableau ci-dessous présente le calendrier de sortie prévu pour la version 1.36 du site IBM Cloud® Kubernetes Service. Vous pouvez utiliser ces informations à des fins de planification, par exemple pour estimer la durée générale pendant laquelle la version ne sera plus prise en charge.

Les dates avec l'indicateur représentant un poignard (†) sont provisoires et peuvent changer.

Calendrier de lancement de la version « IBM Cloud Kubernetes Service » 1.36
Version Pris en charge ? Date de publication Date de non prise en charge
1.36 Oui 26 juin 2026 1er août 2027 †

Préparation à la mise à jour

Pour obtenir la liste complète des modifications susceptibles d'affecter vos applications déployées lors de la mise à jour de votre cluster, consultez le journal des modifications de la communauté à l'adresse Kubernetes ainsi que le journal des modifications de version à l'adresse IBM pour la version 1.36. Vous pouvez également consulter les avertissements utiles de l' Kubernetes.

Kubernetes Serveur API et tunnel Konnectivity accessibles via le port 443

Le serveur API d' Kubernetes et le tunnel Konnectivity sont désormais accessibles via le port 443 standard d' HTTPS, et non plus via un port de nœud attribué dynamiquement (par exemple, un port de la plage 20000–32767 ). Le trafic est acheminé vers le service backend approprié grâce à un routage basé sur le nom d'hôte; c'est pourquoi chaque fonction dispose d'un nom d'hôte dédié, même si tous les services partagent le port 443. Cette modification facilite la connexion à votre cluster depuis des environnements réseau restrictifs, car vous n'avez plus besoin d'autoriser un port non standard au niveau de vos pare-feu et de vos contrôles de sortie. Votre cluster expose deux noms d'hôte spécialement conçus via ses points de terminaison de service privés et publics :

  • <cluster>.api.<region-domain> — le point de terminaison du serveur API « Kubernetes »
  • <cluster>.tunnel.<region-domain> — le point d'extrémité du tunnel Konnectivity utilisé pour la communication entre le plan de contrôle et le nœud de travail

Cette fonctionnalité est disponible à partir de la version 1.36 d'IKS dans les régions suivantes : Montréal (ca-mon), Chennai (in-che) et Mumbai (in-mum). La prise en charge d'autres régions sera bientôt disponible.

Si vous avez mis à jour un cluster utilisant le point de terminaison de service public, un fichier kubeconfig qui fait toujours référence à ce point de terminaison ( URL ) continue d'utiliser l'ancien port, ce qui entraîne l'échec des commandes kubectl en raison d'un délai d'expiration de la connexion. Pour éviter cela, vous pouvez soit télécharger un nouveau fichier kubeconfig en exécutant la commande ibmcloud ks cluster config, soit modifier manuellement le port dans votre fichier kubeconfig existant pour le remplacer par 443.

  • Nouveaux clusters : aucune action n'est requise. Les nouveaux clusters sont créés avec des points de terminaison sur le port 443, et le fichier kubeconfig que vous téléchargez utilise déjà ce port.
  • Clusters mis à jour qui utilisent uniquement le point de terminaison du service privé : aucune action n'est requise pour le moment. Les connexions existantes qui ciblent l'ancienne adresse NodePort continuent de fonctionner après la mise à jour. Le nouveau fichier kubeconfig que vous téléchargez utilise le point de terminaison du port 443.
  • Règles réseau personnalisées : mettez à jour toutes les règles de pare-feu, de groupe de sécurité ou de liste blanche de trafic sortant qui font explicitement référence à l'ancien port du plan de contrôle à numéro élevé afin d'autoriser à la place l' HTTPS sortant sur le port 443. Toutes les règles qui épinglaient le port précédent à numéro élevé peuvent être supprimées.
  • Listes d'autorisation basées sur les adresses IP : les enregistrements DNS du point de terminaison du service public pointent désormais vers les adresses IP frontales d'Akamai IP Protect (IPP) au lieu des anciennes adresses IP de l'équilibreur de charge (NLB). Si votre pare-feu ou vos règles de sortie autorisent le trafic vers votre cluster en fonction de l'adresse IP de destination, mettez-les à jour afin d'utiliser les plages d'adresses IP IPP actuelles d'Akamai.
L'accès anonyme au serveur API de l' Kubernetes est désormais restreint

L'accès anonyme au serveur API de l' Kubernetes est désormais limité aux points de terminaison de vérification de l'état de santé (/healthz, /readyz, /livez, /livez/ping). Tous les autres points de terminaison nécessitent une authentification (par exemple, /version). Cela réduit les risques liés à des erreurs de configuration accidentelles du modèle RBAC qui accorderaient des autorisations à system:anonymous ou system:unauthenticated.

Kubernetes Le tableau de bord est obsolète

Le tableau de bord open source « Kubernetes » est obsolète et a été archivé. Le tableau de bord « Kubernetes » n'est plus installé sur les clusters nouvellement provisionnés et est supprimé des clusters fonctionnant sous des versions antérieures lors de la mise à niveau vers « 1.36 ». L'extension « Headlamp » est disponible en remplacement de l'interface utilisateur d' Kubernetes.

NVIDIA Les pilotes GPU ne sont plus installés automatiquement

À partir de la version Kubernetes 1.36, IBM Cloud Kubernetes Service n'installe plus automatiquement les pilotes GPU NVIDIA sur les nœuds de travail GPU. Vous devez installer et gérer vous-même les pilotes GPU pour exécuter des charges de travail sur GPU. Pour plus d'informations, consultez la section « Migration vers les pilotes GPU autogérés ».

L'outil d'ajustement automatique de la taille des clusters ne prend pas encore en charge la version 1.36. Ne mettez pas à jour votre cluster vers la version 1.36 si l'autoscaler est installé.

Mise à jour avant le maître

Passez en revue les modifications suivantes que vous devez effectuer avant de mettre à jour le serveur principal d' Kubernetes.

Modifications à effectuer avant de mettre à jour le serveur principal vers la version « Kubernetes » 1.36
Type Description
Supprimé : plugin de volume « Portworx » intégré à l'arborescence Le plugin de volume « Portworx » intégré à l'arborescence a été supprimé dans la version Kubernetes 1.36, ce qui marque la fin de la migration vers le pilote CSI Portworx. La fonctionnalité « CSIMigrationPortworx » (en phase de validation et verrouillée depuis 1.33 ) ainsi que la fonctionnalité « alpha InTreePluginPortworxUnregister » sont également supprimées, et toutes les opérations de volume « Portworx » intégrées au code source sont redirigées vers CSI. Avant de procéder à la mise à jour, assurez-vous que le pilote CSI « Portworx » est installé et que vos ressources StorageClass, PersistentVolume et PersistentVolumeClaim font référence à ce pilote CSI. Les clusters qui utilisent encore le plugin intégré perdent l'accès aux volumes « Portworx » après la mise à jour.
Modification : validation plus stricte des adresses IP et des masques CIDR La fonctionnalité « StrictIPCIDRValidation » est activée par défaut sur le serveur API. Les champs de l'API contenant des valeurs IP ou CIDR n'acceptent plus les adresses comportant des zéros superflus en début de chaîne (par exemple, 010.000.000.005 au lieu de 10.0.0.5) ni les valeurs CIDR présentant des bits d'hôte ambigus (par exemple, 192.168.0.5/24 au lieu de 192.168.0.0/24 ou 192.168.0.5/32). Vérifiez vos manifestes et vos outils pour les ressources telles que Service, NetworkPolicy et EndpointSlice, et corrigez toute valeur IP ou CIDR non canonique avant de procéder à la mise à jour. Une fois le serveur maître mis à jour, les requêtes visant à créer ou à mettre à jour des objets avec des valeurs non valides sont rejetées.
Modification : changement de nom des indicateurs du plan de contrôle La métrique « volume_operation_total_errors » (kube-controller-manager) est renommée « volume_operation_errors_total », et la métrique « etcd_bookmark_counts » est renommée « etcd_bookmark_total ». Si vous utilisez des tableaux de bord de surveillance personnalisés ou des règles d'alerte faisant référence aux anciens noms de métriques, remplacez-les par les nouveaux noms afin que votre surveillance continue de fonctionner après la mise à jour du plan de contrôle.
Supprimé : plugin de volume « git-repo » Le plugin de volume « git-repo » est désactivé par défaut et ne peut pas être réactivé; la fonctionnalité « GitRepoVolumeDriver » n'a plus aucun effet. Ce type de volume n'est plus pris en charge dans « IBM Cloud Kubernetes Service » depuis la version 1.33. Si certaines charges de travail utilisent encore un volume de type « gitRepo », migrez-les vers un volume de type « emptyDir » alimenté par un conteneur de type « init » qui clone le référentiel à l'aide de git. Pour plus d'informations, consultez la section « Suppression du pilote de volume « gitRepo » intégré à l'arborescence ».

Mise à jour après le maître

Passez en revue les modifications suivantes que vous devez effectuer après la mise à jour du serveur principal d' Kubernetes.

Modifications à effectuer après la mise à jour du fichier maître vers la version « Kubernetes » 1.36
Type Description
Obsolète : Service .spec.externalIPs Le champ « .spec.externalIPs » des ressources « Service » est obsolète, et le serveur API renvoie désormais un avertissement d'obsolescence lorsque ce champ est défini. Prévoyez de ne plus utiliser externalIPs et de rediriger le trafic externe via un service LoadBalancer ou un Ingress. Pour plus d'informations, consultez la section « Adresses IP externes ».
Modification : profil par défaut d' kubectl debug Le profil par défaut de kubectl debug passe de legacy à general. Si vous disposez de scripts ou de runbooks qui dépendent du comportement du profil « legacy », indiquez explicitement « --profile=legacy ». La suppression du profil « legacy » est prévue dans la version Kubernetes 1.39. Pour plus d'informations, consultez la section « Débogage des pods en cours d'exécution ».
Modification : ordre des événements de l'informateur client-go (AtomicFIFO) La fonctionnalité « client-go AtomicFIFO » est activée par défaut. Les magasins d'Informer sont désormais entièrement mis à jour vers une version cohérente des ressources avant que les gestionnaires par élément OnAdd, OnUpdate et OnDelete ne soient appelés. De plus, le processus de resynchronisation d'Informer a légèrement évolué, ce qui peut entraîner des différences perceptibles dans le moment où ces gestionnaires sont appelés. Tester les contrôleurs et opérateurs personnalisés qui intègrent client-go. Si vous constatez des régressions, vous pouvez temporairement définir le « feature gate » client-go « AtomicFIFO » sur « false » dans votre propre binaire de contrôleur le temps de procéder aux adaptations nécessaires.
Modification : validation numérique plus stricte de la variable « CustomResourceDefinition » CustomResourceDefinition La validation (CRD) impose désormais strictement les plages des formats numériques int32, int64, float et double lorsqu'ils sont définis dans un schéma. Les objets existants qui contiennent déjà des valeurs hors plage sont conservés grâce au mécanisme de validation progressive, mais les valeurs nouvelles ou mises à jour doivent se situer dans la plage autorisée. Passez en revue les ressources personnalisées qui utilisent ces formats numériques.
Obsolète : champ « liste blanche » du plugin « Credential » Dans la liste blanche du plugin de credentials client, le champ « AllowlistEntry.Name » a été renommé « AllowlistEntry.Command ». Si vous configurez une liste blanche de plugins d'authentification (par exemple, via kuberc), mettez à jour votre configuration afin d'utiliser le nouveau nom de champ.
Obsolète : accès direct à metav1.FieldsV1.Raw L'accès direct au champ « Raw » de « metav1.FieldsV1 » est obsolète. Le code qui crée ou lit des objets de type FieldsV1 (par exemple, des contrôleurs ou des outils qui inspectent des champs gérés) doit être migré vers les nouvelles méthodes d'accès NewFieldsV1(string), GetRawBytes(), GetRawString()`` et SetRawBytes() .
Action requise : plugins d' PreBind s pour le planificateur personnalisé Le framework de planification prend désormais en charge l'exécution en parallèle des plugins « PreBind ». Si vous gérez des plugins de planification personnalisés, mettez-les à jour afin qu’ils renvoient une valeur « PreBindPreFlightResult » à partir de la méthode « PreBindPreFlight »; le fait de renvoyer « nil » conserve le comportement séquentiel existant, tandis que les plugins optent pour l’exécution parallèle en renvoyant « AllowParallel: true ». Cette action s'applique uniquement aux clusters qui exécutent des plugins de planification personnalisés.
Action requise : RBAC granulaire pour les pilotes DRA Lorsque la fonctionnalité « DRAResourceClaimGranularStatusAuthorization » est activée (version bêta disponible sur 1.36 ), les pilotes et contrôleurs de l’allocation dynamique des ressources (DRA) nécessitent des autorisations RBAC granulaires pour mettre à jour les statuts de l’ ResourceClaim. Les planificateurs et les contrôleurs ont besoin de update ou patch sur resourceclaims/binding, tandis que les pilotes DRA ont besoin de associated-node:update ou arbitrary-node:update sur resourceclaims/driver, en fonction de leur resourceNames spécifique. Si vous utilisez des pilotes DRA, mettez à jour leur RBAC. Cette action s'applique uniquement aux clusters qui utilisent DRA.