Forum aux questions - Azure Kubernetes Fleet Manager

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

Cet article décrit les questions fréquemment posées pour Azure Kubernetes Fleet Manager.

FAQ sur le service Fleet Manager

Fleet Manager est-il une ressource régionale ou mondiale ?

Fleet Manager est une ressource régionale. La prise en charge du basculement de région pour les cas d’utilisation de la récupération d’urgence se trouve dans la feuille de route.

Combien de clusters puis-je rejoindre Fleet Manager ?

Fleet Manager (avec ou sans cluster central) prend en charge l’intégration de jusqu’à 1 000 clusters Kubernetes. Les clusters membres peuvent être un mélange d’AKS et de Kubernetes avec Arc.

Si vous souhaitez que Fleet Manager prend en charge plus de 1 000 clusters, ajoutez des commentaires.

Quels clusters Kubernetes puis-je rejoindre en tant que membres ?

Fleet Manager permet aux utilisateurs autorisés d’ajouter n’importe quel cluster Kubernetes compatible AKS, AKS Automatic ou Arc dans n’importe quel abonnement et région Azure tant que l’abonnement Azure est associé au même locataire Microsoft Entra ID que Fleet Manager.

Fleet Manager prend-il en charge les identités managées ?

Oui, Fleet Manager prend en charge les identités managées affectées par le système et affectées par l’utilisateur. Pour plus d’informations, consultez la documentation sur l’utilisation d’identités managées avec Fleet Manager.

Que se passe-t-il quand je modifie l’identité du cluster d’un cluster joint ?

La modification de l’identité d’un cluster membre interrompt la communication entre Fleet Manager et ce cluster membre. Bien que l’agent membre utilise la nouvelle identité pour communiquer avec Fleet Manager, Fleet Manager doit toujours être informé de la nouvelle identité. Exécutez cette commande pour résoudre les problèmes suivants :

az fleet member create \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${MEMBER_NAME} \
    --member-cluster-id ${MEMBER_CLUSTER_ID}

Lien avec Kubernetes activé par Azure Arc

Fleet Manager prend en charge les clusters AKS hébergés par Azure et les clusters Kubernetes compatibles avec Azure Arc en tant que clusters membres.

Relation aux clusters Azure Kubernetes Service

Azure Kubernetes Service (AKS) simplifie le déploiement d’un cluster Kubernetes managé dans Azure en déchargeant la surcharge opérationnelle sur Azure. En tant que service Kubernetes hébergé, Azure gère des tâches critiques telles que l’analyse de l’intégrité et la maintenance. Étant donné que le plan de contrôle Kubernetes est géré par Azure, vous conservez uniquement les nœuds de l’agent. Vous exécutez vos charges de travail réelles sur les clusters AKS.

Azure Kubernetes Fleet Manager vous aide à résoudre les scénarios à grande échelle et à plusieurs clusters pour les clusters Azure Kubernetes Service. Azure Kubernetes Fleet Manager fournit une représentation de groupe pour vos clusters AKS et aide les utilisateurs à orchestrer les mises à jour de cluster, la propagation des ressources Kubernetes et l’équilibrage de charge multi-cluster. Les charges de travail utilisateur ne peuvent pas être exécutées sur le cluster Hub Fleet Manager.

Puis-je approvisionner de nouveaux clusters AKS à partir de Fleet Manager ?

La création et la gestion du cycle de vie des nouveaux clusters AKS sont sur notre feuille de route. Fournissez des commentaires si la prise en charge de la création de cluster est un scénario important pour vous.

Dois-je gérer les mises à jour du cluster Hub Fleet Manager ?

Non. Le cluster hub de Fleet Manager est une ressource gérée par Microsoft. Microsoft met automatiquement à jour le cluster hub vers la dernière version de Kubernetes ou de l’image de nœud dès qu’il est disponible.

Si vous tentez de mettre à jour ou de modifier le cluster hub (qui est un seul cluster AKS nommé hub), un ensemble de règles de refus empêche l’application de vos modifications.

Pourquoi mon cluster de hub Fleet Manager est-il passé de l’état « en échec » à l’état « en cours d’exécution » ?

Le cluster Hub Fleet Manager est un cluster AKS géré par Microsoft créé dans votre abonnement. Vous n’avez aucune action à effectuer sur le cluster central.

En cas de problème lors du déploiement ou du fonctionnement du cluster central, il peut passer à l’état Failed.

Fleet Manager réconcilie automatiquement le cluster hub dans le cadre d’opérations périodiques standard du service, ce qui peut faire passer le cluster hub à l’état Running.

Lorsqu’un cluster hub est à l’état Failed, il n’entraîne pas de coût, mais lorsqu’il passe à l’état Running, un coût est engendré.

Mises à jour de plusieurs clusters - FAQ automatisées ou manuelles

Quels clusters les mises à jour multi-cluster prennent-elles en charge ?

Quels sont les canaux de mise à jour AKS pris en charge par Fleet Manager ?

Fleet Manager prend en charge les canaux de mise à jour AKS suivants :

• Rapid : mises à jour pour la dernière version de Kubernetes prise en charge par AKS (N).
• Stable : mises à jour du canal stable Kubernetes (N-1) où « N » est la version Kubernetes prise en charge par AKS la plus récente.
• NodeImage : image de nœud VHD avec correctifs de bogues et de sécurité, selon un cycle de publication hebdomadaire.
• TargetKubernetesVersion (Kubernetes Patch) : met à niveau les clusters vers la dernière version corrective de la version cible spécifiée lorsque le correctif est disponible. Prend en charge les versions mineures kubernetes disponibles uniquement via AKS Long-Term Support (LTS).
• SecurityPatch (images de nœud Linux) : mises à jour du système d’exploitation des images de nœud qui fournissent des correctifs de sécurité gérés par AKS, appliqués au VHD existant utilisé par le nœud.

Canaux AKS actuellement non pris en charge :

• Non géré : mises à jour du système d’exploitation des images de nœud appliquées directement via le mécanisme de correctifs intégré au système d’exploitation (nœuds Linux uniquement). Il n’existe actuellement aucun plan pour Fleet Manager pour prendre en charge cette option.

La version mineure de Kubernetes cible dans mon profil de mise à niveau automatique n’est pas prise en charge par la communauté. Que puis-je faire ?

Vous pouvez:

• Permettre le support à long terme (LTS) dans le profil de mise à jour automatique et l'activer pour tous les clusters de votre flotte que vous souhaitez conserver sur la version mineure spécifique. Vérifiez que seuls les clusters LTS sont inclus dans la stratégie de mise à jour que vous utilisez.
• Mettez à jour le profil de mise à niveau automatique vers une nouvelle version mineure Kubernetes cible. Les clusters sont mis à jour vers le correctif le plus récent de la version mineure spécifiée de Kubernetes dès qu'elle est publiée.

Pour plus d’informations sur l’activation de LTS dans les profils de mise à niveau automatique, consultez Les mises à jour de version Kubernetes cibles. Pour plus d’informations sur l’activation de LTS sur des clusters managés, consultez prise en charge à long terme.

Que se passe-t-il si je laisse les mises à niveau automatiques du cluster AKS activées ?

Si vous laissez les mises à niveau automatiques du cluster AKS activées, Fleet Manager ou la mise à niveau automatique du cluster AKS effectue la mise à jour, selon celle qui s’exécute en premier.

Fleet Manager ne modifie pas la configuration des paramètres de mise à niveau automatique du cluster AKS.

Si vous souhaitez que Fleet Manager gère les mises à niveau automatiques, désactivez la mise à niveau automatique sur chaque cluster AKS membre.

Prise en charge de la fenêtre de maintenance du cluster AKS

Une fenêtre de maintenance définit quand un cluster peut être mis à niveau en toute sécurité.

Fleet Manager respecte les paramètres de la fenêtre de maintenance par cluster pour chaque cluster membre.

Quand une fenêtre de maintenance s’ouvre, les mises à niveau ne démarrent pas immédiatement. Les raisons sont les suivantes :

• Limites de concurrence : même si une fenêtre de maintenance s’ouvre, un cluster peut ne pas être mis à niveau en raison des paramètres d’accès concurrentiel de la stratégie.
• Interrogation régulière : Fleet Manager interroge les fenêtres de maintenance ouvertes toutes les 60 minutes, de sorte que la durée d’attente maximale est de 60 minutes à partir de la fenêtre ouverte.

Quelle est l’étendue des mises à niveau d’images de nœud cohérentes ?

La cohérence des nœuds est garantie uniquement pour tous les clusters contenus dans une seule exécution de mise à jour où vous choisissez l’option consistent image .

Il n’existe aucune garantie de cohérence pour les versions d’images de nœud entre les exécutions de mises à jour distinctes.

Comment puis-je savoir quelles images de nœud ont été utilisées dans une exécution de mise à jour ?

L’exécution de mise à jour répertorie les images de nœud sélectionnées utilisées pour l’exécution. Vous pouvez accéder à ces informations même si l’exécution de la mise à jour n’a pas démarré.

Plusieurs images de nœud peuvent être sélectionnées, car différents pools de nœuds fonctionnent sur tous les clusters sélectionnés pour la mise à jour.

Pour rechercher les images sélectionnées, utilisez cette commande Azure CLI :

az fleet updaterun show \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${UPDATE_RUN_NAME} \
    --query "status.nodeImageSelection.selectedNodeImageVersions"

Vous pouvez également utiliser l’option View JSON dans la page Vue d’ensemble de l’exécution de mise à jour dans le portail Azure pour afficher les données brutes d’une exécution de mise à jour.

Mon exécution de mise à jour est dans un état en attente depuis un certain temps. Que dois-je faire ?

Les exécutions de mises à jour de Fleet Manager peuvent être dans un état en attente pour de nombreuses raisons. Vous pouvez afficher l’état d’une exécution de mise à jour via le portail Azure, ou en suivant la documentation de surveillance.

Les deux raisons les plus courantes pour les états en attente longue sont les suivantes :

• Fenêtres de maintenance du cluster membre : si la fenêtre de maintenance d’un cluster membre n’est pas ouverte, l’exécution de la mise à jour entre dans un état suspendu. Cette pause bloque l’achèvement du groupe de mises à jour ou de l’étape jusqu’à ce que la fenêtre de maintenance suivante s’ouvre. Pour poursuivre l'exécution de la mise à jour, ignorez manuellement le cluster. Si vous ignorez le cluster, il n’est pas synchronisé avec le reste des clusters membres dans l’exécution de la mise à jour.

• Version de Kubernetes ou de l’image de nœud indisponible dans la région Azure : si la nouvelle version de Kubernetes ou de l’image de nœud n’est pas publiée dans la région Azure où se trouve un cluster membre, l’exécution de la mise à jour passe à l’état En attente. Vous pouvez vérifier le suivi des versions AKS pour voir l’état régional de la version. Même si vous pouvez ignorer le cluster membre, s'il existe d'autres clusters dans la même région Azure, ils ne peuvent pas également être mis à jour.

Mon processus de mise à niveau automatique a démarré, puis est immédiatement passé à un état en attente. Pourquoi?

Consultez la question précédente.

J’ai essayé de générer une exécution de mise à jour à partir de mon profil de mise à niveau automatique, mais je ne vois pas l’exécution de la mise à jour.

Lorsque vous générez manuellement une exécution de mise à jour à partir d’un profil de mise à niveau automatique, l’exécution de mise à jour résultante peut déjà exister.

Ce scénario peut survenir si le profil de mise à niveau automatique a généré automatiquement l’exécution de la mise à jour ou si l’exécution de la mise à jour a été générée manuellement.

Le nom de l’exécution de mise à jour générée est basé sur la spécification de mise à niveau automatique du profil de mise à niveau qui change uniquement lorsque des propriétés telles que l’image de nœud ou la version kubernetes sont mises à jour.

Vous voyez généralement ce problème dans le portail Azure où l'exécution de mise à jour existante n'est pas la dernière exécution de la mise à jour. Si vous rencontrez ce problème et que vous ne trouvez pas l'exécution de la mise à jour, utilisez la Azure CLI pour générer l'exécution pour afficher le nom de l'exécution de la mise à jour. Microsoft envisage de résoudre ce problème dans le portail Azure à l’avenir.

Si vous générez une exécution de mise à jour et qu’elle existe, l’exécution de mise à jour existante n’est pas modifiée.

La modification de ma stratégie de mise à jour n’a pas modifié les exécutions de mises à jour existantes qui l’ont utilisée. Pourquoi pas?

Lorsque vous créez une exécution de mise à jour, la stratégie est copiée dans l’exécution de la mise à jour afin que les modifications apportées à la stratégie n’affectent pas l’exécution des exécutions de mises à jour.

Comment empêcher une défaillance d’un seul cluster d’arrêter l’exécution de ma mise à jour entière ?

Utilisez le maxAllowedFailures paramètre sur vos phases et groupes de stratégie de mise à jour (disponible à partir de la version d’API 2026-06-02-preview). Ce paramètre vous permet d’indiquer combien de défaillances de clusters membres sont tolérées avant que le groupe ou l’étape ne soit marqué comme ayant échoué. Les valeurs peuvent être un entier fixe (par exemple, "3") ou un pourcentage (par exemple). "25%" Lorsqu’il n’est pas défini ou "0", une seule défaillance arrête l’exécution entière.

Pour plus d’informations, consultez Nombre maximal d’échecs autorisés (version préliminaire).

Pourquoi mon exécution de mise à jour ou mon groupe affiche-t-il « Terminé » alors que certains membres ont échoué ?

Lorsque vous définissez maxAllowedFailures, Fleet Manager évalue uniquement le nombre de mises à jour des membres ayant échoué. Elle n’applique pas un taux de réussite minimal. Une exécution de mise à jour, une étape ou un groupe peut donc se terminer Completed même si certains ou tous les membres ont échoué, tant que le seuil configuré n’est pas dépassé lorsque Fleet Manager prend ses décisions de planification.

Ce résultat est attendu et intentionnel, pas un bogue. Inspectez toujours FailureCount, les états, les états au niveau des membres et les causes d’échec avant de considérer le déploiement comme sain. Pour la plupart des stratégies de mise à jour, les seuils basés sur des pourcentages sont plus faciles à raisonner que les valeurs absolues.

Quelles règles et limitations dois-je savoir quand j’utilise maxAllowedFailures ?

Gardez les règles suivantes à l’esprit :

• La fonctionnalité est disponible à partir de la version d’API 2026-06-02-preview.
• Lorsque vous ne définissez pas maxAllowedFailures ou le définissez sur "0", Fleet Manager applique un comportement d’arrêt immédiat en cas d’échec et s’arrête après la première mise à jour de membre ayant échoué.
• Le seuil est évalué par rapport au nombre d’échecs uniquement. Elle n’applique pas un taux de réussite minimal.
• Une exécution, une étape ou un groupe peut s’afficher Completed même lorsque des échecs se produisent, tant que le seuil configuré n’est pas dépassé.
• FailureCount peut être supérieur à maxAllowedFailures lorsque les mises à jour s’exécutent en parallèle, car plusieurs mises à jour des membres peuvent échouer avant que Fleet Manager cesse de programmer d’autres tâches.
• Les seuils au niveau de l’étape et au niveau du groupe sont évalués indépendamment, et les échecs au niveau étape sont agrégés sur tous les groupes de la phase.
• Pour la plupart des déploiements, les seuils basés sur des pourcentages sont plus faciles à raisonner et à mettre à l’échelle mieux que les nombres fixes, en particulier dans les petits groupes.

Puis-je préapprouver une approbation ?

Non. Vous pouvez approuver une mise à niveau uniquement après avoir vérifié que les clusters membres sont prêts à être mis à niveau ou que la mise à niveau est terminée correctement. Si vous souhaitez préapprouver, envisagez de ne pas configurer d’approbation dans votre stratégie.

Les approbations expirent-elles ?

Non, les approbations attendent qu’elles soient approuvées. Vous ne pouvez pas configurer une fenêtre de temps pour les approbations.

Puis-je ignorer une approbation ?

Si vous souhaitez passer les mises à niveau du cluster membre en même temps que l'approbation conditionnelle, ignorez le groupe englobant ou l'étape. Si vous souhaitez poursuivre les mises à niveau, vous devez accorder l’approbation.

Comment supprimer une approbation ?

Comme dans la question précédente, si vous souhaitez procéder à une mise à niveau, vous devez accorder l’approbation. Si vous essayez de nettoyer la ressource de porte sous-jacente, vous devez supprimer l’exécution de mise à jour associée, ce qui supprime toutes les portes liées à l’exécution de la mise à jour.

Puis-je configurer une approbation après l’étape en même temps qu’une attente après l’étape ?

Yes. L’attente de la phase suivante commence au même moment que l’approbation. Les deux doivent être terminés avant la fin de l’exécution de la mise à jour.

Puis-je ajouter des approbations aux stratégies de mise à jour existantes ?

Yes. Vous pouvez modifier la stratégie existante pour inclure des approbations. Toutefois, les exécutions de mises à jour existantes que vous avez créées à l’aide de la stratégie ne sont pas mises à jour.

Comment les portes de démarrage planifiées interagissent-elles avec les fenêtres de maintenance de cluster AKS ?

Les portes de démarrage planifiées et les fenêtres de maintenance planifiée du cluster AKS sont des contrôles indépendants. Les deux conditions doivent être remplies avant qu’un cluster ne démarre la mise à niveau. Par exemple, si un jalon de démarrage planifié est franchi à 2 h 00, mais que la fenêtre de maintenance d’un cluster ne commence qu’à 6 h 00, le cluster attend jusqu’à 6 h 00 pour commencer sa mise à niveau.

Comment puis-je contrôler l’ordre des mises à jour du cluster dans une exécution de mise à jour ?

Les étiquettes de membre et les groupes de mises à jour sont deux façons différentes de sélectionner les clusters inclus dans chaque phase et groupe de votre stratégie de mise à jour. Chaque cluster membre peut être affecté à un groupe de mises à jour, mais peut avoir plusieurs étiquettes. Les étiquettes de membre (utilisant memberSelector) offrent une plus grande flexibilité et prennent en charge des scénarios de sélection complexes ; c’est donc la méthode recommandée pour sélectionner les membres d’une flotte dans les stratégies de mise à jour. Pour plus d’informations, consultez Clusters de groupe à l’aide d’étiquettes de membres.

Dois-je spécifier des groupes si j’ai défini un sélecteur de membre au niveau de l’étape ?

Non. Lorsque vous définissez memberSelector pour une étape sans définir de groupes, tous les clusters correspondants sont traités comme un seul groupe. La phase maxConcurrency contrôle le nombre de clusters mis à niveau simultanément. Vous devez uniquement définir des groupes dans une phase si vous souhaitez partitionner les membres correspondants en sous-ensembles parallèles avec différents paramètres d’accès concurrentiel.

Que se passe-t-il pour mettre à jour des groupes si je définisse un sélecteur de membre au niveau du groupe ?

Si vous définissez un memberSelector au niveau de groupe, le champ name du groupe est utilisé uniquement comme identificateur d’affichage pour la création de rapports d’état et l'enregistrement. memberSelector prend le pas sur le nom du groupe de mises à jour lors de la sélection de clusters pour le groupe.

Questions fréquentes (FAQ) sur le placement des ressources de cluster

Puis-je sélectionner des ressources à l’intérieur d’un espace de noms pour la propagation ?

Yes. Fleet Manager prend en charge le placement des ressources à l'échelle du cluster et à l'échelle de l'espace de noms :

• ClusterResourcePlacement : propage les ressources étendues au cluster et les espaces de noms entiers (y compris tout leur contenu) aux clusters membres. Pour plus d’informations, consultez Utilisation de ClusterResourcePlacement pour déployer des ressources délimitées au cluster.
• ResourcePlacement : fournit un contrôle granulaire pour sélectionner et propager des ressources spécifiques à un espace de noms (telles que ConfigMaps, Secrets, Déploiements) au sein d'un espace de noms. Pour plus d’informations, consultez Utilisation de ResourcePlacement pour déployer des ressources délimitées à l’espace de noms.

Feuille de route

La feuille de route Azure Kubernetes Fleet Manager est disponible sur GitHub. L’équipe accueille les demandes de fonctionnalités, les questions et les rapports de bogues.

Étapes suivantes

• Créer une flotte et joindre des clusters membres.
• Guides de résolution des problèmes pour Fleet Manager.