La communauté Kubernetes publie une nouvelle version mineure environ tous les quatre mois. Container Service for Kubernetes (ACK) s'aligne sur ce rythme de publication pour gérer le cycle de vie des versions Kubernetes, y compris leur création, leur maintenance et leur fin de vie (EOL). Cette rubrique présente la politique de prise en charge des versions Kubernetes par ACK, en détaillant leurs publications, leurs cycles de vie et leur support technique.
Historique des publications
Le tableau suivant répertorie les versions Kubernetes prises en charge par les clusters managés ACK.
|
Version |
Statut |
Date de publication ACK |
Fin de prise en charge ACK |
|
Publiée |
Mai 2026 |
30 mai 2027 |
|
|
Publiée |
Février 2026 |
28 février 2027 |
|
|
Publiée |
Septembre 2025 |
30 septembre 2026 |
Format de version
ACK utilise le schéma de versionnement x.y.z-aliyun.n, où x.y.z correspond à la version Kubernetes communautaire (majeure.mineure.correctif) et n représente la version de correctif ACK.
Cycle de vie des versions
Après la publication d'une nouvelle version mineure par la communauté Kubernetes, ACK évalue les risques et exécute des tests de cohérence. En général, vous pouvez créer ou mettre à niveau des clusters vers la nouvelle version dans les deux semaines suivant la première publication du correctif communautaire.
Lorsque la communauté Kubernetes publie une nouvelle version de correctif pour une version mineure, ACK évalue le niveau de risque des problèmes corrigés afin de déterminer s'il convient de publier une mise à jour. Pour les versions de correctifs qui résolvent des vulnérabilités de sécurité critiques, ACK termine généralement son évaluation et publie la nouvelle version sous 24 heures.
Politique de prise en charge
-
Cluster creation
ACK permet de créer des clusters exécutant l'une des trois dernières versions mineures Kubernetes. Par exemple, si les trois dernières versions mineures sont 1,35, 1,34 et 1,33, la création de clusters n'est plus disponible pour la version 1,32 dès qu'ACK commence à prendre en charge la version 1,35. La création de clusters est également indisponible pour les versions de correctifs obsolètes.
Après la publication d'une nouvelle version de correctif pour une version mineure, la création de clusters n'est plus disponible pour les versions de correctifs antérieures. Par exemple, après la publication de la version 1,30.7, vous ne pouvez plus créer de clusters exécutant la version 1,30.1.
-
Cluster upgrade
Vous ne pouvez mettre à niveau les clusters que d'une version mineure à la fois. Les rétrogradations et le saut de versions mineures ne sont pas pris en charge.
Pour les versions de correctifs, vous ne pouvez effectuer la mise à niveau que vers la dernière version de correctif disponible. Les mises à niveau vers des versions de correctifs obsolètes ne sont pas prises en charge.
-
Technical support
ACK fournit une assistance technique, incluant des questions-réponses, des conseils en ligne et le dépannage, pour toutes les versions Kubernetes maintenues.
Risques liés aux versions obsolètes
L'exécution d'une version obsolète pose des risques de sécurité et de stabilité. Lorsqu'une version n'est plus prise en charge, votre cluster ne peut plus recevoir de nouvelles fonctionnalités, de corrections de bugs ni bénéficier d'une assistance technique rapide, et reste vulnérable aux failles de sécurité non corrigées.
Vous devez mettre à niveau votre cluster vers une version sécurisée et stable.
Mettre à niveau un cluster manuellement : Mettez à niveau votre cluster d'une version mineure à la fois jusqu'à la dernière version. Vous pouvez contrôler le rythme de la mise à niveau en spécifiant les nœuds à mettre à jour, en définissant le nombre maximal de nœuds simultanés pour un lot de mise à niveau, et en configurant les intervalles de mise à niveau ainsi que les politiques de pause.
Mettre à niveau un cluster automatiquement : Activez les mises à niveau automatiques du cluster et sélectionnez une fréquence de mise à niveau raisonnable pour maintenir votre cluster dans un cycle de mise à jour régulier.
Mises à jour forcées pour les versions obsolètes
Pour les versions Kubernetes dont la fenêtre de prise en charge amont a expiré, la communauté Kubernetes ne divulgue pas les risques CVE ni ne fournit de correctifs. Les risques de sécurité potentiels dans les versions obsolètes peuvent ne pas être découverts ou corrigés à temps. Étant donné que les clusters ACK utilisent une architecture managée, ces risques de sécurité peuvent affecter non seulement votre cluster, mais aussi la sécurité globale d'Alibaba Cloud. Par conséquent, ACK n'autorise pas l'exécution prolongée de versions obsolètes et effectuera une mise à jour forcée vers une version sécurisée et stable.
ACK n'effectue pas immédiatement une mise à jour forcée dès qu'une version de cluster devient obsolète. Nous vous recommandons de mettre à niveau manuellement votre cluster vers une version prise en charge. Avant d'effectuer une mise à jour forcée, ACK enverra des notifications par SMS, e-mail et messages internes au moins un mois à l'avance.
Une mise à jour forcée comprend les actions suivantes :
Mise à niveau des composants du cluster. Seuls les composants incompatibles avec la nouvelle version du cluster sont mis à niveau.
Mise à niveau du plan de contrôle du cluster.
Mise à niveau des pools de nœuds et des nœuds.
Les mises à jour forcées ne sont pas effectuées dans les cas suivants. Vous devez effectuer la mise à niveau manuellement :
Le cluster est un cluster dédié ACK. Nous vous recommandons de migrer vers un cluster Pro ACK. Pour plus d'informations, consultez la rubrique Migration à chaud d'un cluster dédié ACK vers un cluster Pro ACK.
Le cluster exécute Kubernetes 1.22 et utilise Docker comme moteur d'exécution de conteneurs. Vous devez migrer vers le moteur d'exécution containerd. Pour plus d'informations, consultez la rubrique Migrer le moteur d'exécution de conteneurs des nœuds de Docker vers containerd.
Le contrôleur NGINX Ingress installé est une ancienne version présentant des problèmes de compatibilité avec la version ACK cible. Pour les détails des composants, consultez le journal des modifications du contrôleur NGINX Ingress.
FAQ
Puis-je rester sur une version fixe ?
Non. Les risques de sécurité potentiels dans les versions obsolètes peuvent affecter non seulement votre cluster, mais aussi la sécurité globale d'Alibaba Cloud. ACK n'autorise pas l'exécution prolongée de versions obsolètes et effectuera une mise à jour forcée vers une version sécurisée et stable.
Veuillez mettre à niveau la version de votre cluster rapidement (Mettre à niveau un cluster manuellement) afin de bénéficier des dernières fonctionnalités et de l'assistance technique d'ACK. Avant la mise à niveau, consultez les Notes de version pour les versions Kubernetes prises en charge par ACK pour comprendre les changements de fonctionnalités et les notes importantes pour chaque version. Nous vous recommandons d'activer les mises à niveau automatiques du cluster pour garantir une mise à jour régulière de votre cluster.
Comment mettre à niveau rapidement un ancien cluster ?
Vous pouvez choisir l'une des deux solutions suivantes :
Solution 1 : Mettez à niveau une version à la fois. Après chaque mise à niveau, surveillez votre cluster pour vous assurer que vos applications fonctionnent de manière stable avant de procéder à la mise à niveau suivante. Pour plus d'informations, consultez la rubrique Mettre à niveau un cluster manuellement.
Solution 2 : Créez un nouveau cluster avec la dernière version, migrez progressivement vos applications vers le nouveau cluster, puis mettez hors service l'ancien cluster. Pour savoir comment créer et configurer un cluster, consultez la rubrique Créer un cluster managé ACK.
Puis-je sauter des versions mineures lors de la mise à niveau ?
Le plan de contrôle ne prend pas en charge les mises à niveau transversales entre versions mineures. Le pool de nœuds peut être mis à niveau vers la version du plan de contrôle en sautant des versions mineures.
Comment passer de Docker à containerd ?
ACK ne prend plus en charge Docker comme moteur d'exécution de conteneurs intégré dans les versions Kubernetes v1.24 et ultérieures. Vous devez migrer le moteur d'exécution de conteneurs des nœuds de Docker vers containerd.
Vous pouvez effectuer le changement de moteur d'exécution sur le pool de nœuds d'origine en utilisant la fonctionnalité de mise à niveau du pool de nœuds, ou créer un nouveau pool de nœuds containerd pour effectuer une migration progressive. Pour plus d'informations, consultez la rubrique Migrer le moteur d'exécution de conteneurs des nœuds de Docker vers containerd.
Comment ACK garantit-il la stabilité des mises à niveau ?
Un cluster ACK se compose d'un plan de contrôle et d'un ou plusieurs pools de nœuds.
Mise à niveau du plan de contrôle : ACK propose une vérification préalable à la mise à niveau pour inspecter les API obsolètes, la compatibilité des composants, la compatibilité de la configuration des fonctionnalités et les problèmes liés aux composants du plan de contrôle. L'exécution de cette vérification n'affecte pas le fonctionnement normal de vos applications. Si la vérification signale des problèmes, vous pouvez suivre les conseils de correction fournis dans la console. Pour plus d'informations, consultez la rubrique Mettre à niveau un cluster manuellement.
-
Mise à niveau du pool de nœuds : Une mise à niveau du pool de nœuds inclut la mise à niveau de kubelet et de containerd. ACK propose une vérification préalable à la mise à niveau pour inspecter l'état des nœuds, les ressources système, l'état des disques et l'environnement réseau. L'exécution de cette vérification n'affecte pas le fonctionnement normal de vos applications. Si la vérification signale des problèmes, vous pouvez suivre les conseils de correction fournis dans la console.
Vous pouvez également configurer une politique de mise à niveau personnalisée. Par exemple, vous pouvez contrôler le rythme de la mise à niveau en spécifiant les nœuds à mettre à jour, en définissant le nombre maximal de nœuds simultanés pour un lot de mise à niveau et en configurant une politique de pause. Si le disque système d'un nœud contient des données d'application importantes, vous pouvez également créer un snapshot du disque système du nœud avant de mettre à niveau le pool de nœuds. Pour plus d'informations, consultez la rubrique Mettre à niveau un pool de nœuds.
Précautions lors de la mise à niveau
Les mises à niveau de cluster ne peuvent pas être annulées. Nous vous recommandons de mettre à niveau d'abord un environnement de test, puis l'environnement de production après une vérification réussie. Pendant le processus de mise à niveau, vous pouvez également mettre à niveau certains nœuds en premier à des fins de vérification.
Les versions de composants prises en charge, les fonctionnalités et les API obsolètes varient selon les versions Kubernetes. Pour plus d'informations, consultez les Notes de version pour les versions Kubernetes prises en charge par ACK pour les différentes versions.
Suivez les précautions pour les mises à niveau du plan de contrôle.
Suivez les précautions pour les mises à niveau des pools de nœuds.
Documents connexes
Pour obtenir des informations sur les mises à niveau de cluster, y compris les impacts, les procédures, les précautions et les méthodes de mise à niveau, consultez la rubrique Mettre à niveau des clusters.
Pour connaître les types de systèmes d'exploitation et les versions d'images pris en charge par ACK, consultez les Notes de version des images de système d'exploitation.
Pour en savoir plus sur les corrections CVE et les solutions correspondantes fournies par ACK, consultez la rubrique Corriger les CVE.
Pour plus d'informations sur les vérifications préalables à la mise à niveau et les API obsolètes, consultez la rubrique Éléments de vérification du cluster et solutions de correction.
Les clusters Pro ACK améliorent les clusters de base avec une fiabilité et une sécurité accrues pour les environnements de production d'entreprise à grande échelle, et sont couverts par un SLA indemnitaire. Si vous avez besoin de migrer, consultez la rubrique Migration à chaud des clusters de base managés ACK vers des clusters Pro ACK.