Orchestration des mises à jour sur plusieurs clusters membres

Les administrateurs de plateforme qui gèrent un grand nombre de clusters rencontrent souvent des problèmes lors de la préproduction des mises à jour de plusieurs clusters (par exemple, mettre à niveau les versions des images du système d’exploitation du nœud, mise à jour des versions Kubernetes) de façon sûre et prévisible. Pour résoudre ce problème, Azure Kubernetes Fleet Manager (Fleet) vous permet d’orchestrer les mises à jour sur plusieurs clusters à l’aide d’exécutions de mise à jour, d’étapes, de groupes et de stratégies.

• 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 des mises à jour à plusieurs grappes membres, exprimé à l'aide d'étapes 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. Vous pouvez réutiliser une stratégie dans vos cycles de mise à jour au lieu de définir la séquence à chaque fois.

Actuellement, les opérations de mise à jour prises en charge sur le cluster sont les mises à niveau. Vous pouvez choisir entre deux 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).
• Ne mettez à jour que les images des nœuds.

Vous pouvez spécifier la version de Kubernetes cible vers laquelle effectuer la mise à niveau, mais vous ne pouvez pas spécifier les versions exactes de l’image de nœud cible, car les dernières versions d’image de nœud disponibles peuvent varier en fonction de la région du cluster (vérifiez le suivi des mises en production 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 d’un cluster au démarrage de la mise à niveau du cluster. Par conséquent, différentes versions d'images pourraient être utilisées en fonction de la région dans laquelle se trouve un cluster et de la date à laquelle sa mise à niveau commence réellement.
• Consistent : lorsque l’exécution de la mise à jour démarre, elle sélectionne les dernières versions d’image courantes dans les régions des clusters membres de cette exécution, de sorte que les mêmes versions d’image cohérentes sont utilisées entre 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 :

1. Membre avec une fenêtre de maintenance continue ouverte.
2. Membre avec fenêtre de maintenance s’ouvrant au cours des quatre prochaines heures.
3. Membre sans fenêtre de maintenance.
4. 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: état de l’exécution de la mise à jour avant son démarrage.

• En cours d’exécution: la mise à niveau est en cours pour au moins l’un des clusters de l’exécution de la mise à jour.

• En attente :

  • Cluster membre: un cluster membre peut être dans l’état en attente pour l’une des raisons suivantes et sont exposés sous le champ de message.
    • La fenêtre de maintenance n’est pas ouverte. Le message indique l’heure d’ouverture suivante.
    • La version de Kubernetes cible n’est pas encore disponible dans la région 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 de l’image de nœud cible n’est pas encore disponible dans la région 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 dans l’état Pending si tous les membres des groupes sont dans l’état Pending ou non démarrés. 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 dans l’état Pending, le groupe passe à l'état Pending. Tous les groupes doivent être dans l’état terminal avant de passer à l’étape suivante. Autrement dit, si un groupe est dans l’état Pending, l’exécution de la mise à jour attend qu’elle se termine avant de passer à la phase suivante pour l’exécution.
  • Étape: une étape est en Pending si tous les groupes sous cette étape sont dans l’état Pending ou non démarrés.
  • Exécuter: une exécution est dans l'état Pending si l’étape en cours d’exécution est dans l'état Pending.

• Ignoré: tous les niveaux d’une exécution de mise à jour peuvent être ignorés et cela peut être détecté par le système ou initié par l’utilisateur.

  • Membre :
    • Vous avez ignoré la mise à niveau pour un membre ou l’un de ses parents.
    • 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.
    • Lorsque l’image de nœud cohérente est choisie pour une exécution de mise à niveau, s’il n’est pas possible de trouver la version de l’image cible pour l’un des pools de nœuds, la mise à niveau est ignorée pour ce cluster. Par exemple, lorsqu’un nouveau pool de nœuds avec une nouvelle référence SKU de machine virtuelle est ajouté une fois qu’une exécution de mise à jour a démarré.
  • 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 la mise à jour (par exemple, une mise à niveau de cluster est en cours), cette opération n'est pas interrompue pour ce cluster individuel.
  • En cas d'échec pendant l'exécution de la mise à jour (par exemple, les mises à niveau ont échoué sur l'un des clusters), l'ensemble de l'exécution de la mise à jour entre dans un état d'arrêt et les opérations ne sont pas tentées pour les clusters suivants dans l'exécution de la mise à jour.

• Échec : un échec de 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.

Étapes suivantes

• Orchestrer les mises à jour entre plusieurs clusters membres.