Mettre à jour en toute sécurité Kubernetes et les images de nœud dans plusieurs clusters

S’applique à : ✔️ Gestionnaire de flotte ✔️ Gestionnaire de flotte avec cluster hub

Les administrateurs de plateforme qui gèrent un grand nombre de clusters rencontrent souvent des problèmes de mise à jour intermédiaires pour plusieurs clusters (par exemple, la mise à niveau d’une image de système d’exploitation de nœud ou des versions Kubernetes) de manière sécurisée et prévisible. Pour relever ce défi, Azure Kubernetes Fleet Manager vous permet d’orchestrer les mises à jour sur plusieurs clusters à l’aide des exécutions de mises à jour.

Les exécutions de mise à jour se composent d’étapes, de groupes et de stratégies. Vous pouvez appliquer manuellement les exécutions de mises à jour pour les mises à jour ponctuelles ou automatiquement pour les mises à jour régulières en cours à l’aide de profils de mise à niveau automatique. Toutes les exécutions de mises à jour, manuelles et automatisées, respectent les fenêtres de maintenance de cluster.

Comprendre les exécutions de mise à jour

Une exécution de mise à jour représente une mise à jour appliquée à une collection de clusters AKS. Il se compose de l’objectif et de la séquence de mise à jour. L’objectif de mise à jour décrit les mises à jour souhaitées. Par exemple, la mise à niveau vers une version de Kubernetes spécifique ou l’application d’une image de nœud cohérente sur tous les clusters.

Pour obtenir les meilleurs résultats lors de l’utilisation des exécutions de mise à jour, il est important de comprendre les concepts suivants.

• Stratégie de mise à jour : décrit une séquence de mise à jour réutilisable composée d’étapes et de groupes de clusters. Un cluster apparaît dans un groupe à une étape en fonction des étiquettes de membre ou de groupe de mises à jour qu’il a affectées. Pour plus d’informations, consultez présentation des stratégies de mise à jour.

  • Étape de mise à jour : une stratégie de mise à jour est divisée en phases de mise à jour, qui sont appliquées séquentiellement. Par exemple, les clusters d’environnement de test se trouvent dans la première phase de mise à jour, tandis que les clusters d’environnement de production passent à une deuxième phase de mise à jour. Une phase de mise à jour contient un ou plusieurs groupes de mises à jour. Vous pouvez utiliser des contrôles supplémentaires tels que la concurrence maximale, les temps d’attente et les portes d’approbation pour plus de contrôle sur l’exécution de l’étape de mise à jour.

  • Groupe de mises à jour : chaque étape de mise à jour contient un ou plusieurs groupes de mises à jour, qui sélectionnent les clusters à mettre à jour. Affectez les clusters membres à des groupes de mise à jour en utilisant soit la propriété de groupe de mise à jour du cluster, soit la correspondance basée sur les étiquettes, actuellement en préversion, à l’aide des étiquettes de membre. Les groupes de mise à jour d’une étape de mise à jour se mettent à jour en parallèle.

  Remarque

  Le nombre maximal de groupes de mises à jour dans chaque phase de mise à jour est de 50.

  • Contrôles de flux supplémentaires : plus de contrôles sont disponibles pour offrir une flexibilité sur la rapidité avec laquelle une flotte de clusters peut être mise à jour :

    • Concurrence maximale (préversion) : utilisez la configuration de concurrence maximale pour modifier le nombre de clusters mis à niveau en parallèle. Vous pouvez configurer ce comportement au niveau étape et groupe.

    • Échecs maximum autorisés (préversion) : utilisez la configuration maximale des échecs autorisés pour contrôler le nombre d’échecs de mise à niveau du cluster membre tolérés avant l’arrêt de l’exécution de la mise à jour. Vous pouvez configurer ce comportement au niveau étape et groupe.

    • Portes : suspendez l’exécution de la mise à jour jusqu’à ce que leur condition soit remplie.

      • Portes d’approbation (préversion): peuvent être configurées avant ou après chaque étape ou groupe. Les approbations interrompent l’exécution de la mise à jour, permettant à vous ou aux automatisations que vous avez configurées de vérifier qu’il est approprié de continuer. Une fois que vous ou votre automatisation accordez l’approbation, l’exécution de la mise à jour se poursuit.

      • Portes de démarrage programmées (aperçu) : peuvent être configurées avant chaque étape ou groupe. Les points de contrôle de démarrage planifiés mettent en pause le processus de mise à jour jusqu’au jour et à l’heure spécifiés. La porte se termine automatiquement lorsque l’heure planifiée est atteinte, ou vous pouvez la terminer manuellement pour continuer à tout moment.

• Profil de mise à niveau automatique : créez et démarrez automatiquement une exécution de mise à jour lorsque de nouvelles versions d’image Kubernetes ou node sont mises à disposition par AKS. Pour plus d’informations, consultez comprendre les profils de mise à niveau automatique.

Options d’exécution de la mise à jour

Les exécutions de mise à jour peuvent appliquer trois types de mises à niveau :

• Mettez à niveau les versions de Kubernetes pour le plan de contrôle et les nœuds. Cette mise à niveau inclut la mise à niveau de l’image de nœud.
• 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 de Kubernetes cible vers laquelle effectuer la mise à niveau, mais vous ne pouvez pas sélectionner les versions d’image de nœud cible. Le système sélectionne automatiquement les versions d’image de nœud cible en fonction de vos préférences :

• Dernière version : utilisez les dernières images de nœud disponibles dans la région Azure de chaque cluster au démarrage de la mise à niveau de ce cluster. Par conséquent, différentes versions d’image peuvent être utilisées dans l’ensemble du parc, selon la région Azure dans laquelle se trouve un cluster et le moment où sa mise à niveau commence réellement.
• Cohérent : au démarrage de l’exécution de la mise à jour, sélectionnez les versions d’image actuellement disponibles dans toutes les régions Azure où se trouvent les clusters de cette exécution. Par conséquent, les versions d’image cohérentes sont utilisées sur tous les clusters.

Choisissez Dernière version pour utiliser des versions d’images plus récentes et réduire les risques de sécurité. Choisissez Cohérence 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.

Mettre à jour les états d’exécution

Pour comprendre le cycle de vie d’une exécution de mise à jour, vous devez connaître chaque état, les actions que vous pouvez effectuer et la façon dont l’état est calculé.

État en attente

• Exécution de mise à jour : si l’étape actuelle est à l’état Pending.
• Étape de mise à jour : si tous les groupes de mise à jour de cette étape sont Pending ou n’ont pas démarré, ou si elle comporte une porte Pending.
• Groupe de mise à jour : si tous les clusters du groupe sont démarrés Pending ou non, ou s’ils ont une Pending porte. Lorsqu’un cluster passe à Pending, l’exécution de mise à jour tente de mettre à niveau le cluster suivant dans le groupe. Si tous les membres sont Pending, le groupe passe à Pending. Le processus de mise à jour attend que tous les groupes d’une étape soient terminés avant de passer à l’étape suivante.
• Cluster membre : pour l’une des raisons suivantes, que vous pouvez afficher 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 ou de l’image de nœud n’est pas encore disponible dans la région Azure du cluster. Le message renvoie vers le suivi des versions d’AKS pour vérifier l’état de la version.

État ignoré

• Exécution de la mise à jour : le système a détecté que toutes les étapes étaient Skipped.
• Étape de mise à jour : un utilisateur a marqué l’étape, ou tous les groupes de l’étape en tant que Skipped.
• Mettre à jour le groupe : un utilisateur a marqué le groupe ou tous les clusters du groupe en tant que Skipped.
• Cluster membre : pour l’une des raisons suivantes, que vous pouvez afficher dans le champ de message.
  • L’utilisateur a ignoré explicitement le cluster, le groupe ou l’étape.
  • Le cluster se trouve déjà à la version de Kubernetes cible (si le mode d’exécution de mise à jour est Full ou ControlPlaneOnly) et tous les pools de nœuds se trouvent à la version de l’image du nœud cible.
  • Lorsque l’image de nœud cohérente est sélectionnée et qu’il n’est pas possible de trouver la version de l’image cible pour l’un des pools de nœuds. Cette situation peut se produire lorsqu’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.

État d’échec

L’état d’échec se propage depuis les grappes, comme illustré. Un message d’erreur récapitulative affiche la cause de la mise à niveau du cluster ayant échoué.

• Exécution de la mise à jour : au moins un cluster dans le groupe actuel a échoué.
• Étape de mise à jour : au moins un cluster d’un groupe a échoué à cette étape.
• Groupe de mises à jour : au moins un cluster dans le groupe a échoué.
• Cluster membre : la mise à niveau a échoué et l’état du cluster est défini sur Failed.

Lorsque vous configurez le nombre maximal d’échecs autorisés, le seuil d’échec affecte l’état du groupe de mises à jour, de l’étape de mise à jour et de l’exécution de la mise à jour. Il n’affecte pas l’état d’un cluster membre individuel. En cas d’échec de la mise à niveau d’un cluster membre, son état est toujours défini sur Failed.

• Si le nombre d’échecs pour le groupe ou l’étape dépasse le seuil configuré maxAllowedFailures , le groupe ou l’étape est marqué comme Failed avec un message d’erreur récapitulative et l’exécution de la mise à jour cesse de progresser. Si aucun maxAllowedFailures n’est configuré (ou s’il est réglé sur 0), un seul échec interrompt toute l’exécution.
• Si le nombre d’échecs est inférieur ou égal au seuil maxAllowedFailures, le processus de mise à jour poursuit la mise à niveau des membres suivants. Pour plus d’informations, consultez Échecs maximum autorisés.

État terminé

Un Completed état signifie que l’exécution de mise à jour a atteint un état de cycle de vie du terminal. Lorsque vous utilisez des défaillances maximales autorisées, Completed signifie que le seuil d’échec configuré n’a pas été dépassé lorsque Fleet Manager a décidé de continuer le travail de planification. Il ne garantit pas un taux de réussite minimal ou des résultats sains. Vérifiez toujours FailureCount, les États membres et les messages d’échec.

Fenêtres de maintenance planifiée

Les exécutions de mises à jour respectent les fenêtres de maintenance planifiée que vous définissez au niveau du cluster AKS.

Les clusters AKS prennent en charge deux fenêtres de maintenance distinctes : une pour les mises à niveau de Kubernetes (plan de contrôle) et une pour les mises à niveau d’images de nœud. Les fenêtres de maintenance définissent des périodes où les mises à jour peuvent être appliquées à un cluster, mais ne sont pas un déclencheur de mise à jour.

La mise à jour de Fleet Manager respecte les plages de maintenance AKS comme suit :

L’exécution de mise à jour hiérarchise la mise à niveau des clusters en fonction de la maintenance planifiée dans l’ordre suivant :

1. Cluster avec une fenêtre de maintenance continue ouverte.
2. Cluster avec une fenêtre de maintenance qui s’ouvre dans les quatre prochaines heures.
3. Cluster sans fenêtre de maintenance.
4. Cluster avec une fenêtre de maintenance close.

Vue d’ensemble des profils de mise à niveau automatique

Utilisez des profils de mise à niveau automatique pour déclencher automatiquement des opérations de mise à jour lorsque de nouvelles versions de Kubernetes ou d’image de nœud sont disponibles pour AKS.

Dans un profil de mise à niveau automatique, vous configurez :

• un canal (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (préversion)) qui détermine le type de mise à jour appliquée aux clusters.
• UpdateStrategy qui configure la séquence dans laquelle les clusters sont mis à niveau. Si vous ne fournissez pas de stratégie, les clusters mettent à jour un par un de manière séquentielle.
• NodeImageSelectionType (Latest, Consistent) pour spécifier la façon dont l’image de nœud est sélectionnée lors de la mise à niveau de la version kubernetes.

Canal Rapid

Le canal Rapid correspond toujours à la version mineure la plus récente de Kubernetes prise en charge par AKS. Les versions mineures du cluster changent automatiquement quand AKS publie une nouvelle version mineure Kubernetes.

Exemples :

• La dernière version mineure prise en charge est la 1.30. Toute version corrective de la série mineure 1.30 est prise 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 recevant précédemment des mises à jour de la version 1.30 est mis à jour vers le correctif le plus récent pour la version 1.31 qui est désormais le canal Rapide.

Canal Stable

Le canal stable est toujours la version mineure avant le canal Rapide . Parfois, les utilisateurs font référence à Stable en tant que « N-1 », où « N » est la dernière version mineure (canal rapide) prise en charge par Kubernetes. Les versions mineures du cluster changent automatiquement quand AKS publie une nouvelle version mineure Kubernetes.

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. Le canal stable prend en compte toute version corrective de la série mineure 1.30 comme mise à jour. Tout cluster recevant précédemment des mises à jour de la version 1.29 est mis à jour vers le correctif le plus récent pour la version 1.30.

canal de TargetKubernetesVersion

Le canal TargetKubernetesVersion vous permet de contrôler quand déplacer vos clusters vers la prochaine version mineure kubernetes. Vous devez spécifier la version de Kubernetes cible au format « {major} ». {minor} » (par exemple, « 1,33 »). Fleet Manager met automatiquement à niveau les clusters vers la dernière version corrective de la version de Kubernetes cible spécifiée lorsque le correctif est disponible. Fleet Manager ne passe pas à la version mineure suivante tant que la version cible de Kubernetes du profil de mise à niveau automatique n’est pas mise à jour.

Exemples :

• Vous créez un profil de mise à niveau automatique à l’aide du canal TargetKubernetesVersion et spécifiez une version Kubernetes cible de « 1.30 ». Une nouvelle version de correctif 1.30.5 est publiée. Une opération de mise à jour est automatiquement créée, ayant pour cible la version 1.30.5.
• Vous créez un profil de mise à niveau automatique à l’aide du canal TargetKubernetesVersion, spécifiez une version Kubernetes cible de « 1.29 » et activez LongTermSupport (LTS) dans le profil de mise à niveau automatique. La dernière version mineure prise en charge par la communauté est « 1.33 ». Une nouvelle version de correctif 1.29.5 est publiée. Une exécution de mise à jour est créée automatiquement avec la cible 1.29.5. Si l’exécution de mise à jour générée inclut des clusters sans LTS activé, elle échoue.

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 lorsqu’il existe plusieurs différences mineures de version Kubernetes (par exemple : 1.28 à 1.30). Lorsque les administrateurs disposent d’un ensemble diversifié de versions de Kubernetes, utilisez d’abord une ou plusieurs exécutions de mise à jour pour intégrer des clusters dans un ensemble de versions avec version cohérente afin que les mises à jour configurées Stable ou Rapid de canal garantissent la cohérence à l’avenir.

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 supplémentaire pour un disque dur virtuel (VHD) n’est encouru lorsqu’on choisit cette option. 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 sur différents systèmes d’exploitation sont mis à jour conformément aux versions d’image de nœud alignées sur ces systèmes d’exploitation.

Exemple :

• Un cluster a des nœuds avec un NodeImage de AKSWindows-2022-containerd de 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.

Comprendre les mises à niveau des images de nœud et les instantanés

Lorsqu’un cluster possède des pools d’agents créés à partir d’un instantané de pool de nœuds, le résultat de la mise à niveau de l’image de nœud dépend de la sélection de l’image de nœud dans l’exécution de mise à jour du Gestionnaire de flotte.

Canal SecurityPatch (préversion)

Mettez à jour les nœuds Linux du cluster membre avec uniquement des correctifs de sécurité à une cadence hebdomadaire. Canonical Ubuntu et Azure Linux mettent à disposition des correctifs de sécurité du système d’exploitation une fois par jour. Microsoft teste ces correctifs et les regroupe dans des mises à jour hebdomadaires des images de nœud.

Le canal de mise à niveau automatique SecurityPatch est moins perturbant, car il utilise le correctif en direct du système d’exploitation lorsque cela est possible, ce qui réduit la perturbation des nœuds tout en protégeant les nœuds contre les vulnérabilités connues. Lorsque la mise à jour corrective active n’est pas possible, une image de nœud pré-corrigée est déployée à la place.

Seuls les nœuds Linux sont mis à jour lors de l’utilisationSecurityPatch, et les nœuds basés sur Windows sont automatiquement ignorés.

Si vous avez besoin de correctifs de bogues fournis avec de nouvelles images de nœud (VHD) ou d’une expérience cohérente avec les nœuds Windows, choisissez plutôt le canal NodeImage.

Présentation des stratégies de mise à jour

Les administrateurs peuvent contrôler l’ordre dans lequel les clusters sont mis à jour en créant des stratégies de mise à jour réutilisables à l’aide de séries d’étapes de mise à jour et de groupes. Ils peuvent configurer quand les approbations et les pauses doivent se produire dans ces phases et groupes. L’intégralité de la configuration peut être enregistrée sous la forme d’une stratégie de mise à jour qui peut être gérée indépendamment des exécutions de mises à jour ou des profils de mise à niveau automatique, ce qui permet de réutiliser les stratégies en fonction des besoins.

Regrouper des clusters à l’aide d’étiquettes d’adhérents (aperçu)

Les étiquettes de membre peuvent être utilisées pour regrouper des clusters et configurer votre séquence de mise à jour avec des sélecteurs d’étiquettes de style Kubernetes. De cette façon, vous pouvez affecter plusieurs étiquettes à des clusters membres et les utiliser pour différentes stratégies au lieu d’être limité à un seul groupe de mises à jour par cluster. Vous pouvez regrouper des clusters dans votre stratégie avec leurs étiquettes membres en configurant memberSelector sur votre stratégie à deux niveaux :

• Niveau de l’étape : sélectionne les clusters pour l’ensemble de la phase. Quand aucun groupe n’est défini, tous les clusters correspondants forment un seul groupe implicite. Lorsque des groupes sont également configurés, le sélecteur défini au niveau de l’étape agit comme un préfiltre avant l’application de la correspondance au niveau du groupe.
• Niveau du groupe : sélectionne des clusters pour un groupe spécifique au sein d’une phase, ce qui permet d’activer des sous-ensembles parallèles avec différentes limites d’accès concurrentiel.

memberSelector utilise un sélecteur d’étiquette basé sur des chaînes analysé à l’aide de la syntaxe standard du sélecteur d’étiquette Kubernetes. Les opérateurs pris en charge sont les suivants : =, , ==!=, innotin, exists, et !exists.

Pour obtenir des instructions sur l’attribution d’étiquettes de membre et l’utilisation memberSelector dans une stratégie, consultez Créer une stratégie de mise à jour à l’aide de sélecteurs de membres.

Concurrence maximale (version préliminaire)

Maximum concurrency est un paramètre facultatif sur votre stratégie de mise à jour qui contrôle le nombre de clusters pouvant être mis à niveau simultanément. Vous pouvez définir Maximum concurrency à deux niveaux :

• Niveau d’étape : définit le nombre maximal de clusters pouvant être mis à niveau en même temps sur tous les groupes d’une phase. Agit comme un plafond global pour la scène.
• Niveau du groupe : définit le nombre maximal de clusters pouvant être mis à niveau simultanément au sein d’un groupe spécifique.

La concurrence maximale accepte deux formes de valeur :

• Entier fixe : par exemple, "3" limite la concurrence à trois clusters exactement.
• Pourcentage : par exemple, "25%" limite la concurrence à un pourcentage de clusters. Pour les paramètres au niveau de l'étape, le pourcentage est calculé à partir de tous les clusters de l’étape. Pour les paramètres au niveau du groupe, le pourcentage est calculé à partir des clusters de ce groupe. Les pourcentages sont calculés au moment de l’exécution, arrondis à la baisse et appliqués avec une valeur minimale résolue de 1.

Suggestions de contrôle de la concurrence

Si vous souhaitez effectuer une mise à niveau en toute sécurité (c'est-à-dire avec moins de vitesse mais moins de risques de se terminer par plusieurs clusters endommagés), définissez la concurrence maximale sur une valeur plus petite. Si vous souhaitez augmenter la vitesse (plus de vitesse, mais avec un risque accru de se terminer par plusieurs clusters défaillants) : définissez la concurrence maximale sur une valeur supérieure.

Interaction des limites de phase et de groupe

La concurrence maximale au niveau de l’étape agit toujours comme le plafond global. Même si des groupes individuels autorisent une concurrence plus élevée, la limite d’étape est prioritaire. La concurrence au niveau du groupe peut être inférieure à celle configurée en raison de la limite au niveau de l’étape, de la taille du groupe ou des conditions spécifiques aux membres.

Exemple 1 : Limites fixes

Résultat : jusqu’à quatre clusters total, avec un maximum de deux par groupe.

Exemple 2 : Groupes de limitation du débit par étape

Résultat : deux clusters seulement sont mis à niveau en même temps, car la limite d’étape est prioritaire.

Exemple 3 : Déploiement basé sur des pourcentages

Une phase comporte 20 clusters entre deux groupes : groupe A (huit clusters) et groupe B (12 clusters).

Résultat : jusqu’à cinq mises à niveau simultanées, réparties entre les groupes en fonction de leurs limites individuelles.

Nombre maximal d’échecs autorisés (préversion)

Maximum allowed failures est un paramètre de stratégie de mise à jour facultatif qui contrôle la façon dont Fleet Manager répond aux défaillances pendant les mises à jour multicluster.

Par défaut, les mises à jour suivent un modèle d’échec rapide : la défaillance d’un seul cluster interrompt les mises à jour suivantes. Lorsque vous configurez maximum allowed failures, l’exécution de la mise à jour devient tolérante aux défaillances et les mises à jour continuent entre les clusters jusqu’à ce que le seuil d’échec spécifié soit atteint.

Ce paramètre fournit un équilibre délibéré entre la détection précoce des erreurs et le maintien de l’élan de déploiement. Défini maximum allowed failures à deux niveaux :

• Niveau d’étape : définit le nombre maximal d’échecs de mise à niveau des membres tolérés sur tous les groupes d’une phase avant l’échec de l’étape.
• Niveau du groupe : définit le nombre maximal d’échecs de mise à niveau des membres tolérés au sein d’un groupe spécifique avant que le groupe ne soit marqué comme ayant échoué.

Maximum allowed failures accepte deux formes de valeur :

• Nombre entier fixe : par exemple, "3" autorise jusqu’à trois défaillances de clusters membres avant que le groupe ou l’étape ne soit considéré comme en échec.
• Pourcentage : par exemple, "25%" autorise les échecs jusqu’à 25% des clusters membres. Pour les paramètres au niveau de l'étape, le pourcentage est calculé à partir de tous les clusters de l’étape. Pour les paramètres au niveau du groupe, le pourcentage est calculé à partir des clusters de ce groupe. Les pourcentages sont calculés lors de la création de l'opération de mise à jour, avec arrondi à l'entier supérieur, par exemple, 25 % de 5 clusters donnent 2.

Fleet Manager évalue maxAllowedFailures uniquement en fonction du nombre de mises à jour des membres ayant échoué. Il n’évalue pas le taux de réussite et ne nécessite aucun nombre minimal de membres réussis. Lorsque ce paramètre est présent, Completed signifie que le seuil d’échec configuré n’a pas été dépassé au moment où Fleet Manager a pris ses décisions de planification. Completed ne signifie pas que le déploiement a été sain ou réussi.

Exemple : Terminé avec 0% réussite

Supposons qu’un groupe comporte quatre membres et que group.maxAllowedFailures soit défini sur "4". Si les quatre mises à jour des membres échouent, le groupe peut toujours être marqué Completed. Ce résultat est attendu et intentionnel, et non un bogue, car quatre défaillances sont égales à la tolérance configurée et ne dépasse donc pas le seuil. En d’autres termes, un groupe peut être Completed même lorsque 100% de ses membres ont échoué.

Utilisez uniquement un tel seuil lorsque ce comportement correspond à vos attentes de déploiement.

Choisir soigneusement les valeurs de seuil

• Les valeurs absolues sont faciles à comprendre, mais elles peuvent produire des résultats contre-intuitifs en petits groupes. Par exemple, l'autorisation de "2" échecs dans un groupe à deux membres signifie que le groupe peut se terminer Completed même si aucun membre n'a réussi.
• Les valeurs de pourcentage sont mieux mises à l’échelle sur différentes tailles de groupe, de sorte qu’elles sont recommandées pour la plupart des utilisateurs.
• Évitez de définir maxAllowedFailures sur une valeur égale au nombre total de membres, sauf si vous souhaitez intentionnellement obtenir un comportement de type « ne jamais échouer en raison de défaillances de membres ». Si ce comportement est intentionnel, 100% s’adapte généralement plus clairement qu’une valeur fixe.
• Soyez prudent avec les petits groupes, où une défaillance unique peut représenter un pourcentage important du déploiement.
• Réévaluez le seuil à mesure que votre flotte augmente. Une valeur qui se sent sûre pour cinq clusters peut être trop stricte ou trop permissive pour 500 clusters.

Comprendre FailureCount

Les champs FailureCount sont des champs de métriques de rapport. Ils comptent comme échecs de mise à jour des membres. Ils ne sont pas des ratios ou des pourcentages, et ils ne sont pas identiques au seuil d’application configuré.

• UpdateRun.FailureCount : nombre total de mises à jour des membres ayant échoué dans toutes les phases et tous les groupes de l'exécution.
• Stage.FailureCount : nombre total d'échecs de mise à jour des membres dans tous les groupes de cette étape.
• Group.FailureCount : nombre total de mises à jour des membres ayant échoué au sein de ce groupe.

Passez toujours en revue ces nombres en parallèle des statuts, des conditions et des messages d'échec au niveau des membres avant de déterminer si le résultat du déploiement est acceptable.

Pourquoi FailureCount peut dépasser maxAllowedFailures

maxAllowedFailures contrôle la prise de décision de Fleet Manager quant à la poursuite de la planification de nouveaux travaux. Il ne s’agit pas d’une borne supérieure stricte du nombre final de défaillances rapporté.

Si vous autorisez des mises à jour parallèles des membres en utilisant maxConcurrency, plusieurs membres peuvent échouer presque en même temps avant que Fleet Manager ne constate que le seuil est dépassé et cesse de planifier de nouvelles tâches. Par conséquent, il est possible et attendu que FailureCount soit supérieur à la valeur maxAllowedFailures configurée.

Comment les limites d’échec des étapes et des groupes interagissent

Les niveaux de groupe et d’étape maxAllowedFailures sont évalués indépendamment :

• Chaque groupe suit son propre nombre d’échecs par rapport à son propre seuil.
• Ces mêmes échecs de groupe se cumulent également dans la phase.FailureCount
• Si l’un ou l’autre seuil est dépassé, Fleet Manager cesse de planifier de nouveaux travaux pour ce segment.
• Les mises à jour de membres déjà démarrées peuvent malgré tout se terminer, ce qui peut augmenter la valeur finale de FailureCount signalée après la prise de la décision d'arrêt.

Le niveau maxAllowedFailures d’étape agit comme le plafond global de tolérance de défaillance dans une phase. Même si des groupes individuels autorisent un nombre d’échecs plus élevé, la limite d’étape est prioritaire. Si le nombre d’échecs d’un groupe dépasse sa propre maxAllowedFailuresvaleur, ce groupe est marqué comme ayant échoué, quel que soit le paramètre de niveau étape.

Exemple 1 : Limites de défaillance fixes

Résultat : Le groupe A tolère jusqu’à deux défaillances et le groupe B tolère jusqu’à trois. Si le nombre total d’échecs sur l’étape dépasse cinq, l’étape échoue.

Exemple 2 : Tolérance basée sur un pourcentage

Une étape comporte 19 clusters répartis en deux groupes : le groupe A avec 7 clusters et le groupe B avec 12 clusters.

Utilisations recommandées et non recommandées

Utilisez des seuils plus élevés ou exprimés en pourcentage lorsque vous mettez à niveau de grandes flottes, lorsque vous prévoyez quelques échecs temporaires, ou lorsque la progression du déploiement est plus importante qu’un comportement strict d’échec immédiat.

Utilisez 0 ou très peu de valeurs pour les déploiements critiques en matière de sécurité, les phases de production étroitement contrôlées ou toute situation où vous devez arrêter et inspecter après le premier échec.

Étapes suivantes

• Guide pratique : Mettre à jour plusieurs clusters en utilisant les exécutions de mise à jour d’Azure Kubernetes Fleet Manager.
• How-to : mettez automatiquement à niveau plusieurs clusters à l’aide de Azure Kubernetes Fleet Manager.
• Guide pratique : Surveiller les exécutions de mise à jour pour Azure Kubernetes Fleet Manager.
• Questions fréquentes (FAQ) sur les mises à jour de plusieurs clusters.