Update a node pool - Container Service for Kubernetes - Centre de documentation Alibaba Cloud

Lorsque vous mettez à jour la version Kubernetes d’un cluster, commencez par mettre à jour le plan de contrôle, puis mettez à jour les pools de nœuds pendant les heures creuses. La mise à jour d’un pool de nœuds inclut celle du kubelet et du moteur d’exécution de conteneurs. Avant de lancer l’opération, ACK effectue une vérification préalable afin d’identifier et de signaler les risques potentiels, garantissant ainsi le bon déroulement du processus.

Remarques

Mise à l’échelle des nœuds
- Si la mise à l’échelle des nœuds est activée pour le cluster, le composant cluster-autoscaler est automatiquement mis à jour vers la dernière version après la mise à jour du cluster. Cela garantit le bon fonctionnement de la fonctionnalité de mise à l’échelle automatique. Après la mise à jour du cluster, vérifiez que le composant cluster-autoscaler exécute la version correcte. Pour plus d’informations, consultez la rubrique Activer la mise à l’échelle automatique des nœuds.
- Lors de la mise à jour d’un cluster, les nœuds dont le Scaling Mode est défini sur Swift peuvent ne pas être mis à jour car ils sont arrêtés. Si un nœud en mode Swift n’est pas mis à jour une fois la mise à jour du cluster terminée, nous vous recommandons de le supprimer manuellement.
Après avoir mis à jour un cluster vers Kubernetes 1.18, ACK configure par défaut la réservation de ressources au niveau des nœuds. Si aucune réservation de ressources n’est configurée et que l’utilisation des ressources des nœuds est élevée, les pods peuvent ne pas être replanifiés rapidement après leur éviction. Nous vous recommandons de réserver des ressources pour vos nœuds. Pour des performances optimales, l’utilisation du CPU ne doit pas dépasser 50 % et celle de la mémoire ne doit pas dépasser 70 %. Pour plus d’informations, consultez la rubrique Politique de réservation de ressources des nœuds.
Dans les clusters exécutant Kubernetes 1.24 ou une version antérieure, si un pod d’une charge de travail est configuré uniquement avec une sonde de démarrage (startup probe), le pod peut passer temporairement à l’état NotReady après le redémarrage du kubelet. Nous vous recommandons d’utiliser une stratégie de déploiement multi-réplicas pour répartir les charges de travail sur plusieurs nœuds. Cela garantit qu’un nombre suffisant de pods reste disponible lors du redémarrage d’un nœud.
Si un pod accède à un autre pod situé sur le même nœud via l’adresse IP de l’instance SLB exposée par un service LoadBalancer, et que la valeur externalTrafficPolicy du service est définie sur Local, les deux pods peuvent ne plus résider sur le même nœud après le remplacement de ce dernier. Cela peut entraîner des interruptions réseau.
Les images de système d’exploitation (OS) personnalisées ne sont pas rigoureusement validées par ACK. ACK ne peut garantir le succès de la mise à jour pour les clusters utilisant une image OS personnalisée.
Lors de la mise à jour d’un cluster, yum est utilisé pour télécharger les packages logiciels requis. Si vous avez modifié les configurations réseau de vos nœuds ou utilisé une image OS personnalisée, assurez-vous que yum fonctionne correctement sur les nœuds. Vous pouvez exécuter la commande yum makecache pour vérifier son état.
Si vous avez apporté des modifications de configuration personnalisées au cluster, telles que l’activation de la partition SWAP ou la modification des configurations du kubelet ou du moteur d’exécution de conteneurs depuis la ligne de commande, le processus de mise à jour peut échouer ou vos configurations personnalisées peuvent être écrasées.
Lorsque vous mettez à jour un nœud en remplaçant son disque système, ACK procède à la vidange (draining) du nœud. Les pods sont expulsés du nœud vers d’autres nœuds disponibles selon le PodDisruptionBudget (PDB) configuré. Pour assurer une haute disponibilité des services, nous vous recommandons d’utiliser une stratégie de déploiement multi-réplicas afin de répartir les charges de travail sur plusieurs nœuds. Vous devez également configurer un PDB pour les services critiques afin de contrôler le nombre de pods pouvant être perturbés simultanément.

Le délai d’expiration par défaut pour la vidange des nœuds est de 30 minutes. Si la migration des pods n’est pas terminée dans ce délai, ACK interrompt la mise à jour pour garantir la stabilité du service.
Lorsque vous mettez à jour un nœud en remplaçant son disque système, ACK réinitialise le nœud en se basant sur la configuration actuelle du pool de nœuds, telle que la méthode de connexion au nœud, les libellés, les taints, l’image OS et la version du moteur d’exécution de conteneurs. En général, vous mettez à jour la configuration d’un pool de nœuds en modifiant le pool de nœuds. Si vous avez modifié un nœud par d’autres méthodes, ces changements seront écrasés lors de la mise à jour.
Si un pod sur un nœud utilise un volume HostPath pointant vers le disque système, les données de ce répertoire sont perdues après une mise à jour par remplacement du disque système.
Lors de la mise à jour d’un pool de nœuds, seules les opérations de mise à l’échelle horizontale (scale-out) sont prises en charge. Les opérations de réduction (scale-in) ne sont pas prises en charge.
Si un nœud est un nœud non géré (un nœud de calcul qui n’est géré par aucun pool de nœuds), vous devez d’abord le migrer vers un pool de nœuds. Pour plus d’informations, consultez la rubrique Migrer des nœuds non gérés vers un pool de nœuds.
Lorsque vous mettez à jour un cluster ACK, vous ne pouvez pas mettre à jour les pools de nœuds Lingjun.
Lorsque vous mettez à niveau un pool de nœuds dans un cluster de version 1.31 ou antérieure, le processus met également à niveau le plug-in de périphérique NVIDIA et réinitialise toutes ses configurations non standard.

Fonctionnalités

La mise à jour d’un pool de nœuds inclut la mise à jour du kubelet et du moteur d’exécution de conteneurs.

Mise à jour du kubelet : met à niveau le kubelet sur les nœuds d’un pool de nœuds vers la même version que le plan de contrôle. Par défaut, ACK effectue une mise à jour sur place (in-place).
Mise à jour du moteur d’exécution de conteneurs : lorsqu’une nouvelle version du moteur d’exécution de conteneurs est publiée, vous pouvez mettre à niveau le moteur d’exécution sur vos nœuds vers la dernière version.
- Lorsque vous migrez le moteur d’exécution de conteneurs de Docker vers containerd, les nœuds du pool de nœuds sont mis à jour en remplaçant leur disque système. Cette opération efface tout le contenu du disque système. Avant de commencer la mise à jour, assurez-vous de sauvegarder toutes les données importantes du disque système. Pour plus d’informations, consultez la rubrique Migrer le moteur d’exécution de conteneurs des nœuds de Docker vers containerd.
- À l’exception des nœuds ContainerOS, ACK effectue par défaut une mise à jour sur place lorsque vous passez d’une version de containerd à une version plus récente. Le fichier /etc/containerd/config.toml sur le nœud est remplacé par une nouvelle version fournie par ACK.
  Important
  - Les nœuds ContainerOS ne prennent pas en charge les mises à jour sur place pour containerd. Vous ne pouvez les mettre à jour qu’en remplaçant le disque système. Pour la procédure de mise à niveau, consultez la rubrique Mettre à niveau une version de ContainerOS antérieure à 3,4 vers la dernière version.
  - Lors d’une mise à jour du moteur d’exécution de conteneurs, les sondes de pod et les hooks de cycle de vie peuvent échouer. Les pods peuvent également redémarrer sur place.
- Dans les clusters exécutant Kubernetes 1.24 ou une version antérieure, lorsque vous mettez à jour Docker vers une version plus récente, ACK met à jour les nœuds du pool de nœuds en remplaçant leur disque système par défaut. Cette opération efface tout le contenu du disque système. Avant de commencer la mise à jour, assurez-vous de sauvegarder toutes les données importantes du disque système.

Procédure

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Nodes > Node Pools.

Sur la page Node Pools, localisez le pool de nœuds que vous souhaitez mettre à jour et choisissez > Kubelet Update dans la colonne Actions. Configurez les paramètres comme décrit dans le tableau suivant.

Paramètre		Description
Kubelet Update Information		Consultez la version actuelle du kubelet et sélectionnez la version cible.
Runtime Update Information		Consultez la version actuelle du moteur d’exécution et sélectionnez la version cible. Lorsque vous migrez le moteur d’exécution de conteneurs des nœuds de Docker vers containerd, les nœuds du pool de nœuds sont mis à jour en remplaçant leur disque système. Ce processus efface tout le contenu des disques système. Si votre cluster exécute Kubernetes 1.22 et que la version installée de containerd est la 1.6.34 (une version relativement récente), les mises à jour ne sont pas prises en charge.
Update Nodes		Spécifiez les nœuds à mettre à jour : tous les nœuds ou des nœuds spécifiques.
Méthode de mise à jour		Sélectionnez une méthode de mise à jour. Les options In-place Upgrade et Upgrade by Replacing System Disk sont prises en charge. Pour obtenir des informations sur la logique et le processus de mise à jour, consultez la section Informations de référence : Mises à jour sur place et mises à jour par remplacement du disque système. In-place Upgrade : met à jour les composants requis sur les nœuds existants. Cette méthode ne remplace pas le disque système ni ne réinitialise le nœud, et n’affecte pas les données présentes sur le nœud. Upgrade by Replacing System Disk : réinitialise le nœud en remplaçant son disque système. Les propriétés de l’instance du nœud, telles que son nom, son ID et son adresse IP, restent inchangées, mais toutes les données du disque système sont effacées. Les données sur les disques de données montés séparément ne sont pas affectées.
Ignore Warnings		Indique s’il faut poursuivre l’opération si la vérification préalable signale des avertissements. Par exemple, si un pod utilise un `hostPath` pointant vers le disque système.
Batch Update Policy	Maximum Number of Nodes per Batch	ACK met à jour les nœuds par lots en fonction du nombre maximal de nœuds concurrents que vous spécifiez. Pour plus d’informations sur le processus de mise à jour, consultez la section Informations de référence : Mises à jour sur place et mises à jour par remplacement du disque système.
	Automatic Pause Policy	Politique de pause pour le processus de mise à jour des nœuds.
	Interval Between Batches	Si vous définissez Automatic Pause Policy sur Do not set, vous pouvez spécifier un intervalle de temps entre les lots de mise à jour. La valeur varie de 5 à 120 minutes.
	Auto Snapshot	Si le disque système de votre nœud contient des données métier importantes, vous pouvez choisir de créer un snapshot pour le nœud avant de mettre à jour le pool de nœuds. Cela vous permet de sauvegarder et de restaurer les données du nœud. La création de snapshots entraîne des frais. Pour plus d’informations, consultez la rubrique Tarification des snapshots. La progression de la création est mise à jour en temps réel. Si le snapshot n’est plus nécessaire après la mise à jour, supprimez-le rapidement. Remarque Si vous sélectionnez Upgrade By Replacing System Disk comme méthode de mise à jour, nous vous recommandons d’activer Auto Snapshot. La création de snapshots entraîne des frais. Pour plus d’informations, consultez la rubrique Tarification des snapshots.

Une fois les configurations terminées, cliquez sur Precheck. Une fois la vérification préalable réussie, suivez les instructions à l’écran pour démarrer la mise à jour.

Remarque
Si la vérification préalable échoue ou renvoie des avertissements, consultez la rubrique Solutions pour les éléments de vérification ayant échoué ou affichez le Pre-check Report comme indiqué pour résoudre les problèmes.
Pendant la mise à jour, vous pouvez effectuer les opérations suivantes comme invité :
- Pause : la mise en pause d’une mise à jour de cluster est un état intermédiaire. Nous vous recommandons de ne pas effectuer d’autres opérations sur le cluster pendant cette période et de terminer le processus de mise à jour dès que possible. Si une mise à jour reste en pause pendant plus de sept jours, ACK termine automatiquement le processus et efface tous les événements et journaux associés.
  
  Après avoir mis la mise à jour en pause, vous ne pouvez pas revenir aux versions précédentes du kubelet et du moteur d’exécution de conteneurs sur les nœuds déjà mis à jour.
- Cancel : annule la mise à jour. Après avoir cliqué sur Cancel, vous ne pouvez pas revenir aux versions précédentes du kubelet et du moteur d’exécution de conteneurs sur les nœuds déjà mis à jour.
Après la mise à jour, vous pouvez accéder à la page Nodes, cliquer sur le nom d’un nœud, puis sélectionner l’onglet Basic Information pour vérifier que les versions du kubelet et du moteur d’exécution de conteneurs sont correctes.

Mises à jour sur place et remplacements de disque système

Processus de mise à jour sur place et par remplacement

La section suivante décrit les processus de mise à jour sur place et de mise à jour par remplacement du disque système. ACK met à jour les nœuds d’un pool de nœuds par lots en fonction du nombre maximal de nœuds concurrents spécifié. Le nombre de nœuds dans chaque lot augmente de manière exponentielle (1, 2, 4, 8, etc.) jusqu’à atteindre le maximum spécifié. Ensuite, chaque lot suivant est traité avec le nombre maximal de nœuds. Par exemple, si vous définissez le nombre maximal de nœuds concurrents sur 4, un nœud est mis à jour dans le premier lot, deux nœuds dans le deuxième, et quatre nœuds dans le troisième et tous les lots suivants.

La figure ci-dessous illustre le processus de mise à jour par lots où le nombre maximal de nœuds concurrents est N. Le nombre de nœuds mis à jour dans chaque lot est de 1, 2, 4, 8, etc., jusqu’à N.

Logique de mise à jour sur place

ACK effectue une vérification préalable de la mise à jour. Si un problème critique lié aux conteneurs est détecté, tel qu’un échec de traitement des requêtes ttrpc ou un processus de conteneur ne répondant pas aux signaux, la mise à jour s’arrête.
Les états actuels des conteneurs et des pods sont enregistrés dans un répertoire temporaire tmp.
Le système met à niveau containerd, crictl et les fichiers de configuration associés vers les nouvelles versions fournies par ACK, puis redémarre containerd. Cette action n’affecte pas les conteneurs en cours d’exécution. Si vous avez précédemment modifié le fichier /etc/containerd/config.toml sur le nœud, la mise à jour écrase vos modifications.
Le système s’assure que le kubelet fonctionne correctement et que le nœud est prêt.

Logique de remplacement du disque système

Le nœud est vidé (drained). Si le nœud est programmable, le système le définit comme non programmable.
L’instance ECS est arrêtée.
Le disque système est remplacé. L’ID du disque système change, mais le type de disque cloud, l’adresse IP de l’instance et l’adresse MAC de l’interface réseau élastique restent inchangés.
Le nœud est réinitialisé.
Le nœud est redémarré et devient prêt. Parallèlement, le nœud est défini comme programmable.

Si vous avez défini un nœud comme non programmable avant le début de la vidange du nœud, il n’est pas automatiquement reconfiguré comme programmable une fois la mise à jour terminée.

FAQ

Puis-je restaurer un pool de nœuds après une mise à jour ?

Vous ne pouvez pas revenir aux versions précédentes du kubelet ou du moteur d’exécution de conteneurs après une mise à jour. Vous ne pouvez revenir qu’à la version précédente de l’OS. Lorsque vous restaurez l’OS, vous devez vous assurer que le pool de nœuds prend toujours en charge l’image d’origine.

Une mise à jour affecte-t-elle mes applications ?

Mise à jour sur place : les pods ne sont pas redémarrés et vos applications ne sont pas affectées.

Mise à jour par remplacement du disque système : les nœuds sont vidés (drained) pendant ce type de mise à jour. Si vos pods implémentent une logique d’arrêt gracieux et sont déployés avec plusieurs réplicas sur différents nœuds, vos applications ne sont pas affectées. Pour empêcher la mise à jour de plusieurs réplicas de la même application dans le même lot, vous pouvez définir manuellement le nombre maximal de nœuds concurrents sur une valeur inférieure au nombre de réplicas de pod.

Combien de temps prend chaque lot de mise à jour ?

Mise à jour sur place : moins de 5 minutes.

Mise à jour par remplacement du disque système : généralement moins de 8 minutes si aucun snapshot n’est créé. Si vous choisissez de créer un snapshot, la mise à jour commence après la création du snapshot, et le temps total dépend du temps de création du snapshot. Le processus de mise à jour du pool de nœuds alloue 40 minutes pour la création du snapshot. Si le snapshot n’est pas terminé dans les 40 minutes, la mise à jour du nœud expire et échoue. À ce stade, l’opération de mise à jour sur le nœud n’a pas encore commencé. Si vous ne stockez pas de données métier sur le disque système, vous pouvez ignorer la création de snapshot pour réduire le temps de mise à jour.

Les données du nœud sont-elles perdues lors d’une mise à jour ?

Lorsque vous mettez à jour le moteur d’exécution de conteneurs en remplaçant le disque système, ne stockez pas de données importantes sur le disque système, ou assurez-vous de les sauvegarder au préalable. Les données sur les disques de données ne sont pas affectées pendant la mise à jour.

Impact sur l’IP du nœud après le remplacement du disque système

Lorsque le disque système est remplacé, son ID change, mais le type de disque cloud, l’adresse IP de l’instance et l’adresse MAC de l’interface réseau élastique restent inchangés. Pour plus d’informations, consultez la rubrique Remplacer le disque système (système d’exploitation).

Comment mettre à jour des nœuds non gérés ?

Les clusters créés avant la disponibilité de la fonctionnalité de pool de nœuds peuvent comporter des nœuds non gérés qui n’appartiennent à aucun pool de nœuds. Vous pouvez migrer ces nœuds non gérés vers un pool de nœuds, puis mettre à jour le pool de nœuds. Pour plus d’informations sur la migration des nœuds non gérés, consultez la rubrique Migrer des nœuds non gérés vers un pool de nœuds.

Nettoyage du répertoire Docker après le basculement vers containerd

En plus des fichiers gérés par le cluster Kubernetes, tels que les conteneurs, les images et les journaux, le répertoire Docker contient également des chemins de fichiers que vous avez créés. Si vous n’avez plus besoin du contenu du répertoire Docker, vous pouvez le supprimer manuellement du disque de données après avoir changé de moteur d’exécution.

Comment restaurer les données à partir d’un snapshot ?

Lorsque vous mettez à jour un pool de nœuds, vous pouvez créer un snapshot pour chaque nœud. Le snapshot est conservé pendant sept jours par défaut, mais vous pouvez le supprimer manuellement plus tôt. Dans de rares cas, tels qu’une perte de données après une mise à jour, vous pouvez utiliser l’une des méthodes suivantes pour restaurer vos données :

Si vous avez effectué une mise à jour sur place (par exemple, seule la version du kubelet a été mise à jour), vous pouvez restaurer le disque à l’aide du snapshot. Pour plus d’informations, consultez la rubrique Restaurer un disque cloud à l’aide d’un snapshot.
Si vous avez effectué une mise à jour par remplacement du disque système (par exemple, l’OS ou le moteur d’exécution de conteneurs a été mis à jour), vous pouvez créer un nouveau disque cloud à partir du snapshot pour restaurer les données. Pour plus d’informations, consultez la rubrique Créer un disque de données à partir d’un snapshot.

Rubriques connexes

Vous pouvez également activer les mises à niveau automatiques du cluster pour réduire la charge de travail liée aux opérations et à la maintenance. Pour plus d’informations, consultez la rubrique Mettre à niveau automatiquement un cluster.
Pour l’historique des modifications de containerd, consultez les notes de version de containerd.
Les pools de nœuds gérés par ACK fournissent un correctif automatique pour les vulnérabilités courantes du système d’exploitation (CVE). Pour plus d’informations, consultez la rubrique Correctif CVE automatique (recommandé).
Kubernetes 1.24 ne prend plus en charge Docker en tant que moteur d’exécution de conteneurs intégré. Vous devez migrer le moteur d’exécution de conteneurs des nœuds de Docker vers containerd. Pour plus d’informations, consultez la rubrique Migrer le moteur d’exécution de conteneurs des nœuds de Docker vers containerd.

Les outils en ligne de commande pour Docker et containerd sont différents. Pour une comparaison des commandes courantes, consultez la rubrique Comparaison des commandes courantes pour Docker et containerd.
Nous vous recommandons de mettre à jour votre image OS vers la dernière version dès que possible. Pour plus d’informations, consultez la rubrique Changer le système d’exploitation.