Pour éviter les risques de sécurité et de stabilité liés aux versions obsolètes et bénéficier des dernières fonctionnalités Kubernetes ainsi que du support technique, mettez à jour la version de votre cluster en temps voulu. ACK propose des vérifications préalables, permet de configurer les politiques et le rythme de mise à niveau, et offre un suivi de la progression pour garantir une transition fluide.
Pourquoi mettre à niveau
ACK vous permet de créer des clusters en utilisant les trois dernières versions mineures de Kubernetes. Par exemple, si ACK prend en charge Kubernetes 1.31, 1,32 et 1,33, vous ne pouvez plus créer de clusters utilisant la version 1.30. La création de clusters avec des versions correctives expirées est également impossible. Pour plus d'informations, reportez-vous au guide des versions.
L'exécution d'une version obsolète présente des risques de sécurité et de stabilité. Lorsqu'une version n'est plus prise en charge, votre cluster ne reçoit plus les nouvelles fonctionnalités, les corrections de bogues ni le support technique en temps opportun, ce qui le rend vulnérable aux failles de sécurité non corrigées.
Important
Lors de la mise à niveau d'un cluster, ACK exécute des pré-vérifications. Toutefois, ces contrôles ne détectent pas toutes les configurations de fonctionnalités ou API incompatibles. Conformément au modèle de responsabilité partagée, il vous appartient de vous tenir informé des sorties de versions en consultant la documentation et en surveillant les messages de la console ainsi que les notifications internes. Avant toute mise à niveau, examinez les notes de version de la nouvelle mouture.
Impact de la mise à niveau
ACK fournit des politiques de mise à niveau progressives et par lots afin d'assurer la continuité et la stabilité de vos pods d'application pendant l'opération.
Pré-vérification : avant de mettre à niveau le plan de contrôle ou un pool de nœuds, ACK lance une analyse pour identifier les risques potentiels de compatibilité. Cela inclut les API obsolètes, les versions de composants incompatibles et les problèmes liés à l'état des nœuds ou des disques. Des suggestions de résolution sont également fournies. Cette étape n'affecte pas les services de votre cluster.
-
Plan de contrôle :
Clusters gérés ACK : ACK gère l'API Server et le redémarre de manière progressive lors de la mise à niveau. Ce processus n'affecte généralement pas les applications en cours d'exécution. Si une application dépend fortement de l'API Server, elle pourrait devoir rétablir ses connexions suite à de brèves interruptions.
Clusters dédiés ACK : lors de la mise à niveau, ACK effectue une mise à jour sur place de chaque nœud maître de façon séquentielle. En règle générale, cela n'affecte pas les applications actives. Néanmoins, si une application dépend fortement de l'API Server, des tentatives de reconnexion peuvent être nécessaires en raison de micro-coupures.
-
Pool de nœuds : les nœuds sont mis à niveau par lots pour garantir la continuité de service. Personnalisez la politique de mise à niveau par lots (nombre maximal de nœuds par lot, intervalle entre les lots, etc.) afin de maîtriser l'impact sur vos services.
Lors d'une mise à niveau sur place, les disques ne sont pas remplacés et les nœuds ne sont pas réinitialisés. Les pods d'application continuent de fonctionner sans interruption de service.
-
Une mise à niveau par remplacement du disque système implique le drainage du nœud, le changement du disque système et la réinitialisation du nœud. Notez les impacts suivants :
Pendant cette opération, ACK draine le nœud. Les pods sont évacués vers d'autres nœuds disponibles conformément au Pod Disruption Budget (PDB). Pour assurer une haute disponibilité, adoptez une stratégie de déploiement multi-réplicas, répartissez les charges de travail sur plusieurs nœuds et configurez un PDB pour les services critiques afin de limiter le nombre de pods perturbés simultanément. Cela préserve la continuité de service durant la maintenance.
ACK réinitialise le nœud selon la configuration actuelle du pool de nœuds (méthode de connexion, image OS, version du runtime conteneur, etc.). Mettez à jour la configuration du pool en modifiant le pool de nœuds. Toute modification apportée au nœud par d'autres moyens sera écrasée durant la mise à niveau.
Si un pod sur le nœud référence un HostPath pointant vers le disque système, les données du répertoire HostPath seront perdues après le remplacement du disque.
Processus de mise à niveau
La mise à niveau d'un cluster ACK concerne le plan de contrôle et les pools de nœuds. Lancez une pré-vérification avant de commencer et planifiez l'opération pendant les heures creuses pour en minimiser l'impact. Une fois le plan de contrôle mis à jour, vérifiez attentivement l'état opérationnel du cluster, puis mettez à niveau les pools de nœuds pour aligner leur version sur celle du plan de contrôle.
1. Préparation
Déterminez la version cible pour la mise à niveau en consultant les notes de version ACK. ACK ne permet de franchir qu'une seule version mineure à la fois. Il est impossible de sauter des versions ou de revenir à une version antérieure.
Lisez attentivement le guide des versions correspondant à la version cible. Assurez-vous de bien comprendre les considérations de mise à niveau, les changements majeurs et les fonctionnalités dépréciées afin d'éviter tout problème de compatibilité ultérieur.
Planifiez une fenêtre de maintenance pour le cluster. Exécutez les pré-vérifications en amont pour identifier les risques potentiels et réalisez la mise à niveau pendant les heures creuses.
2. Mise à niveau du plan de contrôle
-
Exécutez une pré-vérification : avant toute mise à niveau, lancez cette analyse. Ne procédez à l'opération que si tous les points de contrôle sont validés ou si les problèmes identifiés ont été résolus.
Cette vérification inspecte notamment les API obsolètes (pour la version 1.20 et ultérieures), la compatibilité des composants et des fonctionnalités, l'état du cluster ainsi que celui des composants du plan de contrôle.
-
Réalisez la mise à niveau : une fois la pré-vérification réussie, lancez l'opération.
Clusters gérés ACK et clusters ACK Serverless : ACK gère le processus. Les composants du plan de contrôle sont mis à jour, y compris kube-apiserver, kube-controller-manager, kube-scheduler et kube-proxy.
-
Clusters dédiés ACK : une mise à niveau sur place est utilisée pour maximiser la continuité de service et réduire les risques liés à la migration des données et aux ajustements de configuration.
Cliquez pour voir le processus
Si ACK détecte que l'etcd et le runtime conteneur de votre cluster nécessitent une mise à jour, il les met à niveau sur les nœuds maîtres un par un.
Les nœuds maîtres sont sélectionnés et mis à niveau individuellement. L'ID du nœud maître en cours de mise à jour s'affiche.
Mettez à niveau les composants maîtres, notamment kube-apiserver, kube-controller-manager, kube-scheduler et kube-proxy.
Mettez à niveau le kubelet sur les nœuds maîtres.
Vérification post-mise à niveau : assurez-vous que la version du cluster est bien actualisée et que les composants principaux, les applications, la création de pods ainsi que l'ajout de nœuds fonctionnent correctement.
3. Mise à niveau du pool de nœuds
La mise à niveau d'un pool de nœuds concerne le kubelet et le runtime conteneur.
-
Exécutez une pré-vérification : avant de commencer, lancez cette analyse. Ne poursuivez la mise à niveau que si tous les contrôles sont positifs ou si les anomalies détectées ont été corrigées.
Cette étape inspecte notamment l'état des nœuds, les ressources système, l'état des disques et l'environnement réseau.
Configurez la politique de mise à niveau et lancez l'opération : choisissez une méthode (sur place ou par remplacement de disque) et définissez la politique de mise à niveau par lots. Cela comprend la spécification du nombre maximal de nœuds par lot et la création automatique ou non de snapshots.
Contrôle post-mise à niveau : vérifiez que les versions du kubelet et du runtime conteneur sont à jour, et assurez-vous que l'ordonnancement des pods et les applications fonctionnent comme prévu.
4. Autres procédures
Changement d'image OS : pour mettre à niveau l'image du système d'exploitation d'un pool de nœuds ou changer de type d'OS (par exemple, passer d'Alibaba Cloud Linux 2 à Alibaba Cloud Linux 3), reportez-vous à Changer le système d'exploitation.
Composants du cluster : ACK met uniquement à niveau le plan de contrôle et les composants essentiels tels que kube-proxy. Mettez à niveau manuellement les autres composants du cluster via la page Add-ons pendant les heures creuses. Consultez la présentation des composants et notes de version pour connaître les exigences de compatibilité.
Considérations relatives à la mise à niveau
Plans de contrôle
La version Kubernetes d'un cluster ACK doit être mise à niveau séquentiellement parmi les versions prises en charge. Les retours en arrière ne sont pas possibles. Pour effectuer plusieurs mises à niveau successives, surveillez la stabilité des services de votre cluster après chaque opération avant d'entamer la suivante.
Avant de commencer, consultez Mise à niveau des clusters pour obtenir une vue d'ensemble. Examinez le guide des versions ainsi que les notes de version correspondantes. Assurez-vous de maîtriser les détails de chaque version, les API obsolètes et les précautions à prendre afin d'éviter les incompatibilités liées aux évolutions fonctionnelles.
Une mise à niveau du plan de contrôle n'affecte pas les applications en cours d'exécution. L'API Server redémarre de manière progressive durant l'opération. Si votre application dépend fortement de l'API Server, elle doit être capable de gérer les tentatives de reconnexion.
À partir de Kubernetes 1.24, Docker n'est plus pris en charge comme runtime conteneur intégré. Lors du passage de la version 1.22 à la version 1.24 ou supérieure, vous devez migrier le runtime conteneur des nœuds de Docker vers containerd.
Évitez toute opération d'exploitation et de maintenance (O&M) sur le cluster pendant la mise à niveau du plan de contrôle.
Pools de nœuds
-
Vérifications préalables
Les mises à niveau utilisent yum pour télécharger les paquets logiciels requis. Si vous avez modifié manuellement les configurations réseau des nœuds ou utilisé une image de système d'exploitation personnalisée, assurez-vous que yum fonctionne correctement. Exécutez yum makecache pour le vérifier.
ACK ne valide pas strictement les images OS personnalisées ; par conséquent, le succès de la mise à niveau ne peut être garanti.
Si vous avez apporté des modifications de configuration au cluster (activation de la partition SWAP, modification des paramètres kubelet ou runtime via CLI), la mise à niveau risque d'échouer ou vos configurations personnalisées pourraient être écrasées.
Après une mise à niveau vers la version 1.18, ACK applique par défaut la politique de réservation des ressources des nœuds. En l'absence de réservation et si l'utilisation des ressources est élevée, les pods risquent de ne pas être réordonnancés rapidement après éviction. Réservez des ressources pour vos nœuds : maintenez l'utilisation CPU à 50 % ou moins et la mémoire à 70 % ou moins.
Dans les clusters exécutant la version 1.24 ou antérieure, si les pods d'une charge de travail sont configurés uniquement avec une Startup Probe, ils passent brièvement à l'état NotReady après le redémarrage du kubelet. Déployez vos charges de travail avec plusieurs réplicas sur différents nœuds afin de garantir qu'un nombre suffisant de pods reste disponible en cas de redémarrage.
Conservez au moins 20 % d'espace disque libre pour éviter l'éviction de pods due à un manque de capacité lors de la mise à niveau.
-
Contraintes de mise à niveau des pools de nœuds
Seules les opérations de scale-out sont prises en charge lors de la mise à niveau d'un pool de nœuds. Le scale-in n'est pas possible.
Si vous possédez des nœuds workers non gérés n'appartenant pas à un pool, migrez-les. Pour plus d'informations, reportez-vous à Migrer des nœuds non gérés vers un pool de nœuds.
La mise à niveau des pools de nœuds Lingjun n'est pas prise en charge lors d'une mise à niveau de cluster ACK.
Lors d'une mise à niveau par remplacement de disque, ACK réinitialise les nœuds selon la configuration actuelle du pool (méthode de connexion, libellés, taints, image OS, version du runtime). Pour modifier ces paramètres, consultez Modifier un pool de nœuds. Toute autre modification apportée directement aux nœuds sera perdue.
Si un pod utilise un HostPath pointant vers le disque système, les données contenues dans ce répertoire seront perdues après une mise à niveau par remplacement de disque.
Pour les clusters en version 1.31 ou antérieure, la mise à niveau d'un pool de nœuds entraîne également celle du NVIDIA Device Plugin et la réinitialisation de ses configurations non standard.
-
Mise à l'échelle des nœuds et ordonnancement
Si la fonctionnalité de mise à l'échelle des nœuds est activée, cluster-autoscaler est automatiquement mis à jour vers la dernière version après une mise à niveau réussie afin de préserver le fonctionnement de l'Auto Scaling. Vérifiez ensuite que la version de cluster-autoscaler est correcte. Pour plus d'informations, consultez Activer la mise à l'échelle automatique des nœuds.
Durant la mise à niveau, les nœuds dont le Scaling Mode est défini sur Swift peuvent échouer car ils sont arrêtés. Si certains nœuds n'ont pas été mis à jour en raison du mode Swift une fois l'opération terminée, nous vous recommandons de les supprimer manuellement.
-
Réseau et disponibilité des services
Si un pod utilise l'adresse SLB d'un Service LoadBalancer pour accéder à un autre pod sur le même nœud, et que le paramètre externalTrafficPolicy du Service est réglé sur Local, la rotation des nœuds peut séparer les deux pods. Cela risque d'entraîner un échec de connexion réseau.
-
Lors d'une mise à niveau par remplacement de disque, ACK draine les nœuds. Les pods sont alors évacués vers d'autres nœuds actifs dans le respect du Pod Disruption Budget (PDB). Pour garantir la haute disponibilité, déployez vos charges de travail avec plusieurs réplicas sur différents nœuds et configurez un PDB pour les services critiques afin de contrôler le nombre de pods pouvant être interrompus simultanément.
Le délai d'attente par défaut pour le drainage d'un nœud est de 30 minutes. Si la migration des pods n'est pas terminée dans ce laps de temps, ACK interrompt la mise à niveau pour préserver la stabilité du service.
Méthodes de mise à niveau
Mise à niveau sur place et remplacement du disque système
Pour le plan de contrôle, ACK gère le processus pour les clusters gérés ACK et les clusters ACK Serverless. Les clusters dédiés ACK font l'objet d'une mise à niveau sur place.
Concernant les pools de nœuds, deux méthodes sont disponibles : la mise à niveau sur place et le remplacement du disque système.
-
Mise à niveau sur place : l'opération s'effectue directement sur les nœuds existants sans remplacer le disque système ni réinitialiser le nœud. Les données originales restent intactes. Les configurations liées à l'instance ECS (adresses IP, montages de disques) demeurent inchangées. Cependant, les paramètres des composants gérés par ACK (containerd, kubelet) peuvent être ajustés en fonction des différences entre versions.
Pour personnaliser les configurations containerd ou kubelet, consultez Personnaliser les configurations kubelet du pool de nœuds et Personnaliser les configurations containerd pour un pool de nœuds .
-
Mise à niveau par remplacement du disque système : cette méthode remplace le disque système et réinitialise le nœud. Bien que les adresses IP et les montages de disques de données restent identiques, toutes les données présentes sur le disque système sont supprimées. Activez les snapshots et sauvegardez le disque système avant de poursuivre.
Les disques de données attachés au nœud ne sont pas affectés.
Cas particuliers
Le remplacement du disque système est nécessaire dans les scénarios suivants :
Alternative : mise à niveau progressive via un nouveau pool de nœuds
Au lieu de mettre à niveau les nœuds existants, vous pouvez effectuer une mise à niveau progressive en créant un nouveau pool de nœuds avec la configuration cible. Migrez progressivement les applications en rendant l'ancien pool non ordonnançable ou en ajustant l'ordonnancement des charges de travail. Une fois la migration validée, supprimez l'ancien pool.
Les deux pools de nœuds sont facturés tant qu'ils coexistent ; supprimez rapidement l'ancien pool après la migration pour maîtriser les coûts.
FAQ
-
Comment mettre à niveau mon cluster manuellement ?
Reportez-vous à Mettre à niveau un cluster manuellement. Commencez par effectuer la pré-vérification, puis réalisez la mise à niveau et assurez-vous que le résultat correspond à vos attentes.
-
Quelles sont les bonnes pratiques pour la mise à niveau d'un cluster ?
Adoptez une fréquence régulière : suivez le guide des versions, la documentation et les notifications officielles pour maintenir un rythme de mise à jour constant. Cela garantit le maintien du support et de la sécurité.
Élaborez un plan : les mises à niveau impliquant des changements majeurs (comme la dépréciation d'API), préparez un plan détaillé adapté à la taille du cluster et aux besoins métier. Réservez une fenêtre de maintenance en heures creuses et validez l'opération dans un environnement de test avant de l'appliquer en production.
-
Utilisez les mises à niveau automatiques : la fonctionnalité de mise à niveau automatique des clusters permet à ACK de générer un plan, de lancer les pré-vérifications et d'exécuter la mise à jour dans la fenêtre de maintenance définie. Cela réduit considérablement la charge d'exploitation liée à la gestion des versions.
Vous pouvez également créer un cluster géré ACK en mode hébergement intelligent. La version du cluster sera alors automatiquement maintenue par ACK.
-
Combien de temps dure une mise à niveau de cluster ?
Plan de contrôle : pour les clusters gérés ACK et les clusters ACK Serverless, l'opération est gérée par ACK et prend environ 5 minutes. Pour un cluster dédié ACK, les nœuds maîtres sont mis à niveau séquentiellement, ce qui requiert environ 8 minutes par nœud.
Pool de nœuds : la durée dépend de la configuration des lots. Une mise à niveau sur place prend entre 5 et 10 minutes par lot. Un remplacement de disque système sans snapshot nécessite environ 8 minutes par lot, mais le temps réel varie selon le processus de drainage. Si vous optez pour la création de snapshots, le processus attendra leur achèvement, dont la durée dépend du volume de données.
-
Puis-je rester indéfiniment sur une même version sans mettre à niveau mon cluster ?
Non. Les versions obsolètes présentent des risques de sécurité susceptibles d'affecter non seulement vos clusters, mais aussi la sécurité globale d'Alibaba Cloud. ACK ne permet pas aux clusters de rester durablement dans un état obsolète et procède à des mises à niveau forcées pour les amener vers une version sûre et stable.
Nous vous recommandons de mettre à jour votre cluster rapidement. Pour plus d'informations, consultez Mettre à niveau un cluster manuellement. Vous bénéficierez ainsi des dernières fonctionnalités et d'un meilleur support technique. Avant l'opération, examinez les notes de version cibles pour comprendre les changements fonctionnels et les remarques importantes. Activez la mise à niveau automatique des clusters pour garantir une maintenance périodique et automatisée.
-
ACK permet-il de sauter des versions mineures lors d'une mise à niveau ?
Non. Vous devez mettre à niveau votre cluster une version mineure à la fois. De plus, avant de mettre à jour le plan de contrôle, assurez-vous que la version des nœuds correspond à celle du plan de contrôle.
-
Mon cluster est très ancien. Comment le mettre à niveau rapidement ?
Deux solutions s'offrent à vous.
Solution 1 : mettez à niveau le cluster une version mineure à la fois. Après chaque étape, vérifiez le bon fonctionnement de vos applications métier avant de poursuivre. Pour plus d'informations, consultez Mettre à niveau un cluster manuellement.
Solution 2 : créez un nouveau cluster exécutant la dernière version, migrez-y progressivement vos applications, puis décommissionnez l'ancien cluster. Pour savoir comment créer et configurer un cluster, reportez-vous à Créer un cluster géré ACK.
-
Comment passer de Docker à containerd lors d'une mise à niveau de la version 1.22 à 1.24 ?
Depuis la version 1.24, ACK ne prend plus en charge Docker comme runtime conteneur intégré. Vous devez migrer le runtime de vos nœuds de Docker vers containerd.
Vous pouvez changer de runtime dans le pool de nœuds d'origine via la fonctionnalité de mise à niveau, ou créer un nouveau pool de nœuds containerd et y migrer vos charges de travail. Pour plus d'informations, consultez Migrer le runtime conteneur des nœuds de Docker vers containerd.
-
Comment ACK garantit-il la stabilité durant la mise à niveau ?
Un cluster ACK se compose d'un plan de contrôle et de pools de nœuds.
Mise à niveau du plan de contrôle : ACK propose une pré-vérification qui inspecte les API obsolètes, la compatibilité des composants et des fonctionnalités, ainsi que l'état du plan de contrôle. Ces contrôles n'affectent pas le fonctionnement normal des applications. En cas d'échec, des suggestions de correction s'affichent dans la console. Pour plus d'informations, consultez Mettre à niveau un cluster manuellement.
-
Mise à niveau du pool de nœuds : cette opération inclut la mise à jour de kubelet et containerd. Une pré-vérification analyse l'état des nœuds, les ressources système, les disques et le réseau, sans impacter les applications en cours. Des suggestions de réparation apparaissent dans la console en cas de problème.
Vous pouvez également configurer une politique pour contrôler le rythme de mise à niveau (sélection des nœuds, taille des lots, pauses, etc.). Si les disques système contiennent des données métier critiques, créez des snapshots avant l'opération. Pour plus d'informations, consultez Mettre à niveau un pool de nœuds.
-
-
Les clusters avec des versions expirées fonctionnent-ils encore normalement ?
Oui. Cependant, les clusters obsolètes présentent des risques de sécurité et de stabilité. Mettez-les à niveau vers une version maintenue dès que possible.
Du fait de l'architecture gérée des clusters ACK, ces risques peuvent affecter la sécurité globale d'Alibaba Cloud. Par conséquent, ACK interdit le maintien prolongé de versions obsolètes et force la mise à niveau vers une version stable et sécurisée. Pour plus d'informations, consultez Mise à niveau obligatoire des versions obsolètes.
-
Le retour en arrière est-il possible après une mise à niveau ?
Non. Aucun retour en arrière n'est possible pour le plan de contrôle, le kubelet ou le runtime conteneur après une mise à niveau.
Lors de la mise à niveau d'un pool de nœuds, si des données métier importantes résident sur le disque système, créez un snapshot préalable pour pouvoir sauvegarder et restaurer les données du nœud.
-
Quelle opération effectuer en premier : mise à niveau ou migration vers un cluster géré ACK Pro ?
Terminez la migration du cluster avant d'entamer la mise à niveau. Une fois la stabilité des services confirmée, procédez à la mise à jour de version.
-
Que faire si la pré-vérification signale des API obsolètes ?
Pour Kubernetes 1.20 et versions ultérieures, ACK notifie les API obsolètes. Bien que cela ne bloque pas la mise à niveau, corrigez ces problèmes en amont pour garantir la compatibilité de vos applications avec la nouvelle version.
-
Comment résoudre l'avertissement « component version too low » lors des pré-vérifications ?
ACK met uniquement à niveau le plan de contrôle et certains composants clés comme kube-proxy. Identifiez les autres composants nécessitant une mise à jour via la page Add-ons de la console. Vous pouvez y consulter la liste des composants à mettre à niveau. Avant de poursuivre, vérifiez la présentation des composants et notes de version pour vous assurer de leur compatibilité. Planifiez ces mises à jour pendant les heures creuses pour minimiser l'impact sur les services.
-
Comment résoudre l'échec de mise à niveau avec l'erreur « the aliyun service is not running on the instance » ?
Cette erreur survient lorsque Cloud Assistant est indisponible, ce qui fait échouer la commande de mise à niveau. Démarrez ou redémarrez Cloud Assistant, puis réessayez l'opération. Pour plus d'informations, consultez Démarrer, arrêter ou désinstaller Cloud Assistant Agent.
-
Comment résoudre l'erreur « PLEG not healthy » sur un nœud ?
Cette erreur indique que le conteneur ou le runtime ne répond pas. Redémarrez le nœud, puis tentez à nouveau la mise à niveau.
-
Que faire en cas d'erreur « invalid object doesn't have additional properties » lors d'une mise à niveau ?
Après la mise à niveau d'un cluster, vous devez également actualiser votre version locale de kubectl. À défaut, vous risquez de rencontrer des erreurs telles que invalid object doesn't have additional properties lors de l'utilisation de kubectl, car sa version diffère de celle de l'API Server du cluster. Pour savoir comment installer ou mettre à jour kubectl, consultez Install and Set Up kubectl. Il est essentiel de synchroniser la version de kubectl avec celle de l'API Server du cluster pour éviter tout problème de compatibilité.