1.34 informations sur la version et actions de mise à jour
Consultez les informations relatives à la version 1.34 de IBM Cloud® Kubernetes Service. Pour plus d'informations sur la version Kubernetes du projet 1.34, consultez le journal Kubernetes des modifications.
IBM Cloud Kubernetes Service est un produit certifié Kubernetes pour la version 1.34 dans le cadre du programme de certification de conformité des logiciels de la CNCF Kubernetes. 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 suivant indique le calendrier prévu pour la publication de la version 1.34 de 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.
| Version | Pris en charge ? | Date de publication | Date de non prise en charge |
|---|---|---|---|
| 1.34 | Oui | 20 novembre 2025 | 20 janvier 2027 † |
Préparation à la mise à jour
Ces informations résument les mises à jour susceptibles d'avoir un impact sur les applications déployées lorsque vous mettez à jour un cluster vers la version 1.34. Pour obtenir la liste complète des modifications, consultez le journal des Kubernetes modifications de la communauté et le journal IBM des modifications de la version 1.34. Vous pouvez également consulter les avertissements Kubernetes utiles.
Portworx ne prend pas encore en charge la version 1.34. Ne mettez pas à niveau votre cluster vers la version 1.34 si vos applications utilisent Portworx.
CoreDNS Le délai de mise en cache DNS par défaut dans les configurations DNS d' CoreDNS et d' NodeLocal a été augmenté de 30 à 120 secondes.
Mise à jour avant le maître
Le tableau suivant présente les actions que vous devez effectuer avant de mettre à jour le maître Kubernetes.
| Type | Description |
|---|---|
| Cluster Autoscaler: seule la version 2.0.0 et les versions ultérieures du Cluster Autoscaler sont prises en charge dans la version 1.34. | Mettez à niveau votre cluster autoscaler vers au moins la version 2.0.0 avant de mettre à jour votre cluster vers la version 1.34. |
Diffusion de la topologie des pods: la mise en œuvre de matchLabelKeys dans topologySpreadConstraints fusionne désormais avec labelSelector. |
Si vous utilisez cette fonctionnalité, ne passez pas directement de v1.32 à v1.34; effectuez d'abord la mise à niveau vers v1.33. Assurez-vous que les pods créés sur v1.32 à l'aide de matchLabelKeys sont planifiés ou supprimés
avant de passer à v1.34. |
Admission de sécurité des pods: les politiques baseline restricted et bloquent désormais le .host champ dans les sondes et les gestionnaires de cycle de vie (par exemple, livenessProbe,
httpGet). |
Supprimez .host de vos configurations de pod si vous utilisez ces politiques. |
AppArmor: les profils d' AppArmor s dans ne SecurityContext sont plus synchronisés avec les annotations container.apparmor.security.beta.kubernetes.io/ obsolètes. |
Mettre à jour les outils pour lire à partir de SecurityContext. |
Élection du leader: Les endpoint-controller et workload-leader-election FlowSchemas ont été supprimés. |
Les charges de travail qui dépendent de configmapsleases ou endpointsleases pour l'élection du leader doivent migrer vers le type leases de verrouillage. |
Mesures: apiserver_cache_list_fetched_objects_total, apiserver_cache_list_returned_objects_total, apiserver_cache_list_total |
Remplacer resource_prefix label par API group et resource labels. |
Indicateurs: apiserver_selfrequest_total |
Ajouter une étiquette group API. |
Mesures: apiserver_watch_events_sizes et apiserver_watch_events_total |
Remplacer l'API kind label par resource label. |
Mesures: apiserver_request_body_size_bytes, apiserver_storage_events_received_total, apiserver_storage_list_evaluated_objects_total apiserver_storage_list_fetched_objects_total,
apiserver_storage_list_returned_objects_total,, apiserver_storage_list_total, apiserver_watch_cache_events_dispatched_total, apiserver_watch_cache_events_received_total apiserver_watch_cache_initializations_total,
apiserver_watch_cache_resource_version, watch_cache_capacity, apiserver_init_events_total, apiserver_terminated_watchers_total, watch_cache_capacity_increase_total, watch_cache_capacity_decrease_total,,
apiserver_watch_cache_read_wait_seconds, apiserver_watch_cache_consistent_read_total, apiserver_storage_consistency_checks_total, etcd_bookmark_counts, storage_decode_errors_total |
Extrayez le groupe API de resource la balise et placez-le dans la nouvelle group balise. Pour plus d'informations, voir #131845 SIG API Machinery,
Etcd, Instrumentation et Tests. |
| Containerd 2.0 Docker Schéma 1: Docker Le format d'image Schéma 1 ( application/vnd.docker.distribution.manifest.v1+prettyjws ) n'est plus pris en charge par défaut. | Assurez-vous que vos images sont conformes à la norme Schema 2 d' Docker. |
| 2.0 de Containerd - API CRI: l'API CRI v1alpha2 a été supprimée. | Assurez-vous que les composants et outils d' Kubernetes s qui interagissent avec containerd utilisent l'API CRI v1. |
| 2.0 s Containerd - Runtimes: les shims Runtime V1 et Runc V1 ont été supprimés. | Vérifiez que vos charges de travail sont compatibles avec les shims d' V2 s d'exécution de containerd. |
| 2.0 de Containerd Ports non privilégiés et ICMP: les ports non privilégiés et ICMP sont désormais activés par défaut. | Vérifiez les contextes de sécurité de votre application et supprimez les capacités supplémentaires ou les sysctls (tels que NET_BIND_SERVICE ou net.ipv4.ping_group_range) qui étaient auparavant requis pour ces
fonctionnalités. Consultez les journaux des modifications en amont pour plus de détails. |
Mise à jour après le maître
Aucune action requise.