Mettre à jour Kubernetes et les images de nœud sur plusieurs clusters membres

Article
10/21/2024

Les administrateurs de plateforme qui gèrent un grand nombre de clusters ont souvent des problèmes pour la préproduction des mises à jour de plusieurs clusters (par exemple la mise à niveau des versions relatives aux images de système d’exploitation de nœud ou à Kubernetes) de manière sécurisée et prévisible. Pour résoudre ces problèmes, Azure Kubernetes Fleet Manager (Fleet) vous permet d’orchestrer des mises à jour sur plusieurs clusters à l’aide d’exécutions de mises à jour.

Les exécutions de mises à jour se composent de phases, de groupes et de stratégies. Elles peuvent être appliquées manuellement, pour les mises à jour ponctuelles, ou automatiquement, pour les mises à jour régulières à l’aide de profils de mise à niveau automatique. Toutes les exécutions de mises à jour (manuelles ou automatisées) respectent les fenêtres de maintenance des clusters membres.

Présentation des exécutions de mises à jour

L’image suivante montre une exécution de mise à niveau contenant deux phases de mise à jour, chacune contenant deux groupes de mises à jour avec deux clusters membres. Une période d’attente est configurée entre la première et la deuxième phase.

Exécution de mise à jour : une exécution de mise à jour représente une mise à jour appliquée à une collection de clusters AKS, composée de l’objectif et de la séquence de mise à jour. L'objectif de la mise à jour décrit les mises à jour souhaitées (par exemple, mise à niveau vers la version 1.28.3 de Kubernetes). La séquence de mise à jour décrit l’ordre exact d’application de la mise à jour à plusieurs clusters membres. Elle est exprimée à l’aide de phases et de groupes. Si elle n'est pas spécifiée, toutes les grappes membres sont mises à jour une par une de manière séquentielle. Une exécution de mise à jour peut être arrêtée et démarrée.
Étape de mise à jour : les exécutions de mise à jour sont divisées en phases, qui sont appliquées de manière séquentielle. Par exemple, un premier index de mise à jour peut mettre à jour les clusters membres de l’environnement de test, et un deuxième index de mise à jour met ensuite à jour les clusters membres de l’environnement de production. Un temps d'attente peut être spécifié pour retarder l'application des étapes de mise à jour suivantes.
Groupe de mises à jour : chaque étape de mise à jour contient un ou plusieurs groupes de mises à jour, qui sont utilisés pour sélectionner les clusters membres à mettre à jour. Les groupes de mise à jour sont également utilisés pour ordonner l'application des mises à jour aux grappes membres. Dans un index de mise à jour, les mises à jour sont appliquées à tous les différents groupes de mises à jour en parallèle ; dans un groupe de mises à jour, les clusters membres sont mis à jour séquentiellement. Chaque cluster membre de la flotte ne peut faire partie que d’un groupe de mises à jour.
Stratégie de mise à jour : une stratégie de mise à jour décrit la séquence de mise à jour avec des phases et des groupes, et vous permet de réutiliser une configuration d’exécution de mise à jour au lieu de définir la séquence à plusieurs reprises dans chaque exécution. Une stratégie de mise à jour n’inclut pas les versions de Kubernetes ou les versions d’images de nœud souhaitées.

Pour le moment, les opérations de mise à jour prises en charge sur le cluster membre sont les mises à niveau. Vous pouvez choisir entre trois types d’améliorations :

Mettre à jour les versions de Kubernetes pour le plan de contrôle Kubernetes et les nœuds (ce qui inclut la mise à jour des images des nœuds).
Mettre à niveau les versions de Kubernetes uniquement pour le plan de contrôle des clusters.
Ne mettez à jour que les images des nœuds.

Vous pouvez spécifier la version cible de Kubernetes à mettre à niveau, mais vous ne pouvez pas spécifier la version exacte de l’image de nœud cible. En effet, la dernière version d’image de nœud disponible peut varier en fonction de la région Azure du cluster (consultez le suivi des versions AKS pour plus d’informations).

Les versions des images des nœuds cibles sont automatiquement sélectionnées en fonction de vos préférences :

Latest : utilisez les dernières images de nœud disponibles dans la région Azure d’un cluster au démarrage de la mise à niveau du cluster. Ainsi, différentes versions d’image peuvent être utilisées selon la région Azure dans laquelle se trouve un cluster, et le moment où sa mise à niveau démarre réellement.
Consistent : quand l’exécution de mise à jour démarre, elle sélectionne les versions d’image courantes et les plus récentes dans les régions Azure des clusters membres de cette exécution. Ainsi, les mêmes versions d’image cohérentes sont utilisées dans les clusters.

Vous devez choisir Latest pour utiliser des versions d’images plus récentes et de réduire les risques de sécurité, et choisir Consistent pour améliorer la fiabilité en utilisant et en vérifiant ces images dans les clusters dans les phases antérieures avant de les utiliser dans des clusters ultérieurs.

Maintenance planifiée

La mise à jour honore les fenêtres de maintenance planifiée que vous définissez au niveau du cluster Azure Kubernetes Service (AKS).

Au sein d'un cycle de mise à jour (pour les cycles de mise à jour de type une par une ou par étapes), le cycle de mise à jour donne la priorité à la mise à niveau des clusters dans l'ordre suivant :

Membre avec une fenêtre de maintenance continue ouverte.
Membre avec fenêtre de maintenance s’ouvrant au cours des quatre prochaines heures.
Membre sans fenêtre de maintenance.
Membre avec une fenêtre de maintenance fermée.

Mettre à jour les états d’exécution

Une exécution de mise à jour peut se trouver dans l’un des états suivants :

NotStarted : l’exécution de mise à jour n’a pas démarré.
Running : la mise à niveau est en cours d’exécution pour au moins un des clusters membres de l’exécution de mise à jour.
Pending :
- Cluster membre : un cluster membre peut être à l’état d’attente pour l’une des raisons suivantes, consultables dans le champ de message.
  - La fenêtre de maintenance n’est pas ouverte. Le message indique l’heure d’ouverture suivante.
  - La version cible de Kubernetes n’est pas encore disponible dans la région Azure du membre. Les liens de message vers le suivi des mises en production vous permettent de vérifier l’état de la version entre les régions.
  - La version cible de l’image de nœud n’est pas encore disponible dans la région Azure du membre. Les liens de message vers le suivi des mises en production vous permettent de vérifier l’état de la version entre les régions.
- Groupe : un groupe est à l’état Pending si tous les membres du groupe sont à l’état Pending, ou s’ils n’ont pas démarré. Lorsqu’un membre passe à Pending, l’exécution de la mise à jour tente de mettre à niveau le membre suivant dans le groupe. Si tous les membres sont Pending, le groupe passe à l’état Pending. Si un groupe est à l’état Pending, l’exécution de mise à jour attend la fin du processus pour tous les membres du groupe avant de passer à la phase d’exécution suivante.
- Phase : une phase est à l’état Pending si tous les groupes de cette phase sont à l’état Pending, ou s’ils n’ont pas démarré.
- Exécuter: une exécution est dans l'état Pending si l’étape en cours d’exécution est dans l'état Pending.
Skipped : tous les niveaux d’une exécution de mise à jour peuvent être ignorés. Cette action peut être lancée par le système ou par l’utilisateur.
- Membre :
  - Vous avez ignoré la mise à niveau d’un membre, d’un groupe ou d’une phase.
  - Le cluster membre est déjà à la version de Kubernetes cible (si le mode d’exécution de mise à jour est Full ou ControlPlaneOnly).
  - Le cluster membre se trouve déjà à la version de Kubernetes cible et tous les pools de nœuds se trouvent dans la version d’image du nœud cible.
  - Quand une image de nœud cohérente est choisie pour une exécution de mise à niveau, si la version d’image cible de l’un des pools de nœuds est introuvable, la mise à niveau est ignorée pour ce cluster. Par exemple, cela peut se produire quand un nouveau pool de nœuds avec une nouvelle référence SKU de machine virtuelle est ajouté après le démarrage d’une exécution de mise à jour.
- Groupe :
  - Tous les clusters membres ont été détectés comme Skipped par le système.
  - Vous avez lancé une action ignorer au niveau du groupe.
- Index:
  - Tous les groupes de l’index ont été détectés comme Skipped par le système.
  - Vous avez lancé une action ignorer au niveau de l’index.
- Exécuter :
  - Tous les index ont été détectés comme Skipped par le système.
Arrêté: tous les niveaux d’une exécution de mise à jour peuvent être arrêtés. Il existe deux possibilités d’entrer dans un état arrêté :
- Vous arrêtez l'exécution de la mise à jour, qui cesse alors de suivre toutes les opérations. Si une opération a déjà été lancée par l’exécution de mise à jour (par exemple si une mise à niveau de cluster est en cours), cette opération n’est pas abandonnée pour ce cluster individuel.
- Si une défaillance se produit au moment de l’exécution de mise à jour (par exemple les mises à niveau ont échoué sur l’un des clusters), l’ensemble de l’exécution de mise à jour passe à l’état d’arrêt. Aucune opération n’est tentée pour les clusters suivants dans l’exécution de mise à jour.
Failed : l’échec de la mise à niveau d’un cluster entraîne les actions suivantes :
- Marque le MemberUpdateStatus comme Failed sur le cluster membre.
- Marque tous les parents (groupe -> index -> exécuter) comme Failed avec un message d’erreur résumé.
- Empêche l’exécution de la mise à jour de progresser.

Remarque

Vous pouvez relancer une exécution de mise à jour à tout moment pour réappliquer les mises à niveau qui ont pu être ignorées ou qui ont échoué.

Présentation des profils de mise à niveau automatique (préversion)

Les profils de mise à niveau automatique sont utilisés pour déclencher automatiquement les exécutions de mises à jour quand de nouvelles versions de Kubernetes ou d’images de nœud sont disponibles pour AKS.

Important

Les fonctionnalités d’évaluation d’Azure Kubernetes Fleet Manager sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions d’Azure Kubernetes Fleet Manager sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production.

Dans un profil de mise à niveau automatique, vous pouvez configurer :

un Channel (Stable, Rapid, NodeImage) qui détermine le type de mise à niveau automatique appliqué aux clusters.
un UpdateStrategy qui configure la séquence de mise à niveau des clusters. Si aucune stratégie n’est fournie, les clusters sont mis à jour un par un de manière séquentielle.
le NodeImageSelectionType (Latest, Consistent) qui permet de spécifier la façon dont l’image de nœud est sélectionnée au moment de la mise à niveau de la version de Kubernetes.

Canal Stable

Le canal Stable correspond toujours à la dernière version de patch Kubernetes prise en charge par AKS sur la version mineure N-1, où N représente la dernière version mineure prise en charge.

Exemples :

La dernière version mineure de Kubernetes prise en charge est la 1.30. Les versions de patch de la plage de versions mineures 1.29 sont prises en compte pour les mises à jour du canal Stable.
Une nouvelle version mineure de Kubernetes, la version 1.31, est publiée. Les versions de patch de la plage de versions mineures 1.30 sont prises en compte pour les mises à jour du canal Stable. Tout cluster qui recevait des mises à jour de la 1.29 est mis à jour vers le patch le plus récent pour la 1.30.

Canal Rapid

Le canal Rapid correspond toujours à la version mineure la plus récente de Kubernetes prise en charge par AKS.

Exemples :

La dernière version mineure prise en charge est la 1.30. Les versions de patch de la plage de versions mineures 1.30 sont prises en compte pour les mises à jour du canal Rapid.
Une nouvelle version mineure de Kubernetes, la version 1.31, est publiée. La 1.30 passe au canal Stable. Tout cluster qui recevait des mises à jour de la 1.30 est mis à jour vers le patch le plus récent pour la 1.31, qui correspond désormais au canal Rapid.

Canal NodeImage

Les nœuds de clusters membres sont mis à jour à une cadence hebdomadaire avec un nouveau disque VHD incluant un patch, qui contient des correctifs de sécurité et des résolutions de bogues. La mise à jour du nouveau disque dur virtuel entraîne une interruption suite aux fenêtres de maintenance et aux paramètres de surtension. Aucun coût de disque dur virtuel supplémentaire n’est encouru si cette option est choisie.

Si vous utilisez ce canal, les mises à niveau sans assistance de Linux sont désactivées par défaut. Les mises à niveau d’images de nœud prennent en charge les versions correctives déconseillées tant que la version mineure de Kubernetes est prise en charge. Les images de nœud sont testées par AKS, complètement managées et appliquées avec des pratiques de déploiement sécurisées.

Les nœuds des différents systèmes d’exploitation sont mis à jour en fonction des versions d’image de nœud correspondant à ces systèmes d’exploitation.

Exemple :

Un cluster a des nœuds avec une valeur NodeImage AKSWindows-2022-containerd version 20348.2582.240716. Une nouvelle version 20348.2582.240916 de NodeImage est publiée, et les nœuds de cluster sont automatiquement mis à niveau vers la version 20348.2582.240916.

Comportement lié au fait d’ignorer les versions mineures

La mise à niveau automatique ne déplace pas les clusters entre les versions mineures de Kubernetes quand il existe plusieurs différences de versions mineures de Kubernetes (par exemple de 1.28 à 1.30). Quand les administrateurs disposent d’un ensemble diversifié de versions de Kubernetes, il est recommandé d’utiliser d’abord une ou plusieurs exécutions de mises à jour pour intégrer les clusters membres dans un ensemble de versions faisant l’objet d’un contrôle de version cohérent, afin que les mises à jour de canal Stable ou Rapid configurées garantissent la cohérence à l’avenir.