IBM Cloud Docs
Informations sur la version de Kubernetes

Informations sur la version de Kubernetes

Consultez cette page pour obtenir des informations générales sur les versions IBM Cloud® Kubernetes Service et la mise à jour vers les versions plus récentes.

Pour plus d'informations sur les versions de projet Kubernetes, voir les journaux des modifications de Kubernetes.

Versions IBM Cloud® Kubernetes Service disponibles

IBM Cloud Kubernetes Service prend en charge plusieurs versions de Kubernetes simultanément. Lorsque la version la plus récente (n) est publiée, jusqu'à 2 versions antérieures (n-2) sont prises en charge. Les versions au-delà de deux versions avant la version la plus récente (n-3) sont d'abord obsolètes, puis finissent par ne plus être prises en charge. Pour continuer à recevoir d'importantes mises à jour de correctifs de sécurité, assurez-vous que vos clusters exécutent toujours une version de Kubernetes prise en charge. Les clusters obsolètes risquent de ne pas recevoir les mises à jour de sécurité. Pour plus d'informations, voir Cycle de vie des éditions.

Les dates avec l'indicateur représentant un poignard (†) sont provisoires et peuvent changer. Les systèmes d'exploitation marqués d'un astérisque (*) sont obsolètes ; migrez tous les noeuds worker qui utilisent un système d'exploitation obsolète pour s'exécuter sur une version plus récente du système d'exploitation.

Dernière Par défaut 1.32

1.31

1.30

{: tag-deprecated} [obsolète] 1.29

Déclassé 1.28

Ubuntu 20 est obsolète et la prise en charge prend fin le 31 mai 2025. Migrez vos nœuds de travail vers Ubuntu 24 avant la fin du support. Assurez-vous de bien comprendre les limitations d'Ubuntu 24 avant de commencer la migration. Pour plus d'informations, voir Migrer vers une nouvelle version d'Ubuntu.

Types de mise à jour

Votre cluster Kubernetes dispose de trois types de mise à jour : principale, secondaire et correctif. Dès que des mises à jour deviennent disponibles, vous en êtes informé lorsque vous affichez des informations sur le maître ou les noeuds worker du cluster, par exemple en exécutant les commandes suivantes : ibmcloud ks cluster ls, cluster get, worker ls ou worker get.

IBM fournit des groupes de correctifs de noeud worker toutes les deux semaines. IBM a pour objectif de remédier aux vulnérabilités légitimes détectées dans un délai adapté aux risques qu'elles représentent. Pour garantir la qualité et la stabilité de l'édition, les groupes de correctifs peuvent être retardés.

Les groupes de correctifs sont appliqués à la dernière version de noyau stable en amont fournie par Canonical.

  • Pour Ubuntu 20.04, il s'agit du noyau 5.4.

Pour sécuriser vos noeuds, vous devez installer des groupes de correctifs de noeud worker dès que possible. Vous pouvez vous abonner à des notifications pour être alerté lorsqu'une nouvelle mise à jour est disponible.

Impacts des mises à jour Kubernetes
Type de mise à jour Exemples de libellé de version Mise à jour par Impact
Major 1.x.x Vous Modifications d'opérations pour les clusters, y compris scripts ou déploiements.
Mineur x.22.x Vous Modifications d'opérations pour les clusters, y compris scripts ou déploiements.
Patch x.x.4_1510 IBM et vous Correctifs Kubernetes, ainsi que d'autres mises à jour du composant IBM Cloud Provider, tels que des correctifs de sécurité et de système d'exploitation. IBM met automatiquement à jour les maîtres, mais c'est à vous d'appliquer les correctifs à vos noeuds worker. Vous trouverez plus d'informations sur les correctifs dans la section suivante.
Mises à jour de version principale et de version secondaire (1.x)
Tout d'abord, mettez à jour votre noeud maître, puis mettez à jour vos noeuds worker.
  • Vous ne pouvez pas mettre à jour un maître Kubernetes deux ou plusieurs versions mineures avant (n+2). Par exemple, si votre master actuel est la version 1.22 et que vous voulez le mettre à jour vers 1.24, vous devez d'abord mettre à jour vers 1.23.
  • Les nœuds worker ne peuvent pas exécuter une version majeure ou mineure de Kubernetes qui est postérieure à celle des maîtres. De plus, vos noeuds worker ne peuvent être que de deux versions antérieurs à la version maître (n-2).
  • Si vous utilisez une version de l'interface de commande kubectl qui ne correspond pas au moins à la version principale et secondaire (major.minor) de vos clusters, vous risquez d'obtenir des résultats inattendus. Assurez-vous de maintenir votre cluster Kubernetes et les versions de l'interface CLI à jour.
Mises à jour de correctifs (x.x.4_1510)
Les modifications apportées aux correctifs sont documentées dans le journal des modifications de chaque version. Les correctifs de maître sont appliqués automatiquement, mais vous initiez les correctifs et les mises à jour de nœud worker. Les noeuds worker peuvent également exécuter des versions de correctif supérieures à celle du maître. Dès que des mises à jour deviennent disponibles, vous en êtes informé lorsque vous affichez des informations sur le maître ou les noeuds worker dans la console ou l'interface de ligne de commande IBM Cloud, par exemple en exécutant les commandes suivantes : ibmcloud ks cluster ls, cluster get, worker ls ou worker get.
Les correctifs peuvent s'appliquer aux noeuds worker et/ou aux maîtres.
  • Correctiifs de nœud worker : vérifiez chaque mois qu'une mise à jour est disponible et utilisez la commande ibmcloud ks worker update ou la commande ibmcloud ks worker reload pour appliquer ces correctifs de sécurité et de système d'exploitation. Durant une mise à jour ou un rechargement, la machine de votre noeud worker est réimagée et les données sont supprimées si elles ne sont pas stockées hors du noeud worker.
  • Correctifs du maître : les correctifs du maître sont appliqués automatiquement sur plusieurs jours, de sorte que la version d'un correctif de maître s'affiche comme étant disponible avant d'être appliquée à votre maître. L'automatisation de la mise à jour ignore également les clusters qui ne sont pas dans un état sain ou dont les opérations sont encore en cours d'exécution. Occasionnellement, IBM peut désactiver les mises à jour automatiques pour un correctif maître spécifique, comme indiqué dans le journal des modifications, tel qu'un correctif qui n'est nécessaire que si un maître est mis à jour d'une version mineure à une autre. Dans tous ces cas, vous pouvez choisir d'utiliser vous-même la commande ibmcloud ks cluster master update sans attendre que l'automatisation de la mise à jour s'applique.

Cycle de vie des éditions

Chaque version d' IBM Cloud Kubernetes Service prise en charge passe par un cycle de vie comportant les étapes suivantes : test, développement, édition générale, prise en charge, dépréciation puis, progressivement, fin de prise en charge. Passez en revue les descriptions de chaque phase du cycle de vie d'une version.

L'estimation des jours et les versions sont fournies pour une compréhension générale. La disponibilité effective et les dates de publication sont susceptibles de changer et dépendent de divers facteurs, tels que les mises à jour de la communauté, les correctifs de sécurité et les changements de technologie qui interviennent d'une version à l'autre.

  1. Edition de la communauté: La communauté publie la nouvelle version. IBM les ingénieurs commencent à tester et à renforcer la version communautaire en vue de la publication d'une version supportée par IBM Cloud Kubernetes Service.

  2. Cycle de vie des versions prises en charge:

    Edition de développement
    L'édition est en cours de développement et peut être disponible en tant que version bêta pour sélectionner des clients. IBM fournit une prise en charge optimale de l'édition.
    Disponibilité générale
    L'édition est disponible en version GA (GA). IBM fournit une prise en charge complète de l'édition. IBM fournit une date cible provisoire pour que l'édition ne soit pas prise en charge. L'édition devient la version par défaut utilisée lors de la création du cluster une fois qu'il existe des restrictions minimales et un taux d'adoption raisonnable pour l'édition.
    Maintenance
    L'édition est entrée dans le support de maintenance tel que défini par la communauté Kubernetes. IBM fournit une prise en charge de la maintenance pour Kubernetes en fonction de la politique de la communauté. Sinon, IBM fournit une prise en charge complète.

  3. Version obsolète: la version est obsolète. IBM fournit une date cible non prise en charge mise à jour pour l'édition. Un compte à rebours non pris en charge jusqu'à cette date est fourni au moins 45 jours avant que l'édition ne devienne non prise en charge. IBM fournit une prise en charge minimale de l'édition en conformité avec la communauté Kubernetes. Cette phase de prise en charge est généralement la phase finale avant que l'édition ne soit pas prise en charge et remplace les phases de maintenance et de prise en charge étendue en cas de chevauchement. Les mises à jour des correctifs de sécurité peuvent ne pas être fournies. Pendant la période de dépréciation, la version est toujours prise en charge et votre cluster est toujours fonctionnel, mais peut nécessiter une mise à jour vers une version prise en charge pour corriger des failles de sécurité. Par exemple, en ajoutant ou en rechargeant des noeuds worker.

  4. Version non prise en charge: la version n'est pas prise en charge. IBM fournit uniquement la prise en charge de la mise à niveau vers une édition prise en charge. La version n'est pas prise en charge. Les clusters qui ne sont pas pris en charge ne reçoivent pas des mises à jour de sécurité et des correctifs et ne bénéficient pas du service de support IBM Cloud. Bien que votre cluster et vos applications puissent continuer à s'exécuter pendant un certain temps, vous ne pouvez plus créer, recharger ou effectuer d'autres actions correctives sur le maître ou les noeuds worker du cluster lorsqu'un problème se produit. Vous pouvez toujours supprimer le cluster ou les noeuds worker ou mettre à jour le cluster vers la version suivante. Examinez les impacts potentiels et mettez à jour le cluster immédiatement pour continuer à recevoir des mises à jour de sécurité importantes et bénéficier du service de support. Si le maître cluster exécute deux versions ou plus derrière la version prise en charge la plus ancienne, vous ne pouvez plus appliquer de mises à jour et vous devez supprimer le cluster et en créer une nouvelle.

Les clusters exécutant une version non prise en charge finiront par échouer car les certificats de cluster expirent. Les défaillances peuvent inclure, sans s'y limiter, un plan de contrôle de cluster indisponible, des nœuds de travail d' NotReady, ou un Ingress non sain.

  1. Archivé: la version n'est pas prise en charge sans chemin de mise à niveau. IBM ne fournit aucune prise en charge. IBM se réserve le droit d'arrêter les plans de contrôle de ces clusters.

IBM Cloud Kubernetes Service n'a pas développé sa déviation prise en charge entre les composants de noeud central et de plan de contrôle par une version mineure. La déviation prise en charge reste n-2. Pour plus d'informations, voir Changes to supported skew between control plane and node versions pour les informations de la communauté Kubernetes.

Si vous attendez que votre cluster soit au moins antérieur à deux versions mineures de la version la plus ancienne prise en charge, vous ne pouvez pas mettre à jour le cluster. A la place, créez un nouveau cluster, déployez vos applications sur le nouveau cluster et supprimez le cluster non pris en charge. Pour éviter ce problème, mettez à jour les clusters obsolètes vers une version prise en charge antérieure d'une ou deux versions par rapport à la version actuelle, telle que 1.21 ou 1.22, puis mise à jour vers la dernière version 1.23. Si les noeuds worker exécutent une version inférieure d'au moins deux niveaux par rapport à celle du maître, il se peut que vos pods échouent en passant à un état tel que MatchNodeSelector, CrashLoopBackOff ou ContainerCreating jusqu'à ce que vous mettiez à jour les noeuds worker vers la même version. Après que vous avez effectué une mise à jour à partir d'une version obsolète vers une version prise en charge, votre cluster peut effectuer à nouveau des opérations normales et continuer à recevoir l'aide du support. Vous pouvez savoir si votre cluster n'est pas pris en charge en consultant le champ State dans la sortie de la commande ibmcloud ks cluster ls ou dans la console IBM Cloud Kubernetes Service.

Préparation à la mise à jour

La mise à jour d'un cluster vers une nouvelle version à partir de la version précédente est susceptible d'avoir un impact sur les applications déployées. Pour obtenir la liste complète des modifications, consultez les journaux des modifications de la communauté Kubernetes, les journaux des modifications de versionIBM et les avertissements utilesKubernetes.

Pour connaître les actions que vous devez effectuer avant et après la mise à jour de votre cluster, consultez les liens d'informations de version dans Versions disponibles de IBM Cloud® Kubernetes Service.

Archiver

Les clusters qui ne sont pas pris en charge ne reçoivent pas des mises à jour de sécurité et des correctifs et ne bénéficient pas du service de support IBM Cloud. Bien que votre cluster et vos applications puissent continuer à s'exécuter pendant un certain temps, vous ne pouvez plus créer, recharger ou effectuer d'autres actions correctives sur le maître ou les noeuds worker du cluster lorsqu'un problème se produit. Vous pouvez toujours supprimer le cluster ou les noeuds worker ou mettre à jour le cluster vers la version suivante. Examinez les impacts potentiels et mettez à jour le cluster immédiatement pour continuer à recevoir des mises à jour de sécurité importantes et bénéficier du service de support. Si votre maître cluster est inférieur d'au moins deux versions à la version prise en charge la plus ancienne, vous devez créer un nouveau cluster et déployer vos applications sur le nouveau cluster.

Versions non prises en charge de Kubernetes
Historique des versions archivées