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 hub) prend en charge la jonction jusqu’à 100 clusters AKS.

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

Quels clusters AKS peuvent être joints en tant que membres ?

Fleet Manager permet aux utilisateurs ayant les autorisations appropriées d’ajouter n’importe quel cluster AKS dans n’importe quel abonnement Azure et région, tant que l’abonnement Azure est associé au même locataire Microsoft Entra ID que celui de 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 lorsque l’identité du cluster d’un cluster joint est modifiée ?

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 uniquement en charge la jonction de clusters AKS en tant que clusters membres.

La prise en charge de la jonction de clusters non AKS est sur notre feuille de route. Fournissez des commentaires si la prise en charge des clusters non AKS est importante pour vous.

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.

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

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

Canaux de mise à jour AKS pris en charge :

• 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 : disque dur virtuel d’image de nœud corrigé (bogue et sécurité) avec une planification de publication hebdomadaire.
• TargetKubernetesVersion (préversion) (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).

Canaux AKS actuellement non pris en charge :

• SecurityPatch : mises à jour du système d’exploitation d’images de nœud qui fournissent des correctifs de sécurité gérés par AKS appliqués au disque dur virtuel existant s’exécutant sur le nœud.
• Non géré : mises à jour du système d'exploitation de l'image de nœud appliquées directement via la fonctionnalité intégrée de mise à jour du système d'exploitation (nœuds Linux uniquement).

Si vous utilisez l’un des canaux que Fleet Manager ne prend pas en charge, nous vous recommandons de laisser ces canaux activés sur vos clusters AKS.

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 choisir de :

• 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, la mise à jour de ce cluster est effectuée par Fleet Manager ou la mise à niveau automatique du cluster AKS, 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, vous devez désactiver la mise à niveau automatique sur chaque cluster AKS membre individuel.

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

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

Les fenêtres de maintenance ne déclenchent pas de mises à jour, et les mises à jour ne commencent pas immédiatement dès qu'une fenêtre s'ouvre. Les fenêtres de maintenance définissent uniquement lorsque les mises à jour peuvent être appliquées à un cluster.

Pour plus d’informations, consultez la documentation relative aux fenêtres de maintenance de cluster AKS.

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ù l’option consistent image est choisie.

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 contient une liste des images de nœud sélectionnées utilisées dans le cadre d'un processus. Ces informations sont disponibles même si l’exécution de la mise à jour n’a pas démarré.

Il peut y avoir plus d’une image de nœud unique sélectionnée en fonction des différents pools de nœuds qui fonctionnent sur tous les clusters sélectionnés pour la mise à jour.

Vous trouverez les images sélectionnées à l’aide de 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 notre 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, la mise à jour peut être mise en pause. Cette pause peut bloquer l’achèvement du groupe de mises à jour ou de l’étape jusqu’à ce que la fenêtre de maintenance suivante s’ouvre. Si vous souhaitez continuer 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 d’image kubernetes ou de nœud non dans la région Azure : si la nouvelle version d’image kubernetes ou de nœud n’est pas publiée dans la région Azure dans laquelle un cluster membre existe, l’exécution de la mise à jour peut entrer un état en attente. Vous pouvez vérifier le suivi des versions AKS pour voir l’état régional de la version. Bien que vous puissiez ignorer le cluster membre, s’il existe d’autres clusters dans la même région Azure, ils ne pourront pas également effectuer la mise à 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.

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?

Lorsqu’une exécution de mise à jour est créée, une copie de la stratégie choisie est effectuée et stockée sur l’exécution de la mise à jour elle-même afin que les modifications apportées à la stratégie n’affectent pas l’exécution des exécutions de mises à jour.

Puis-je préapprouver une approbation ?

Non. Les approbations ne sont disponibles qu’une fois que vous pouvez vérifier que les clusters membres sont prêts à être mis à niveau ou que la mise à niveau est terminée avec succès. 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 qui supprime toutes les portes liées à l’exécution de la mise à jour.

Puis-je configurer une approbation après étape avec une attente après étape ?

Yes. L’attente de l’étape après commence en même temps que l’approbation. Les deux doivent être terminés avant la fin de l’exécution de la mise à jour.

Les approbations peuvent-elles être ajoutées 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 qui ont été créées à l’aide de la stratégie ne sont pas mises à jour.

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.

Faq sur les déploiements automatisés

Comment cela se compare-t-il aux déploiements automatisés AKS ?

Les déploiements automatisés AKS ne prennent en charge qu’un seul cluster AKS où la charge de travail déployée s’exécute. Les déploiements automatisés de Fleet Manager préparent les définitions de charges de travail sur le cluster central de Fleet Manager, afin de les rendre disponibles pour une propagation vers les clusters membres via le placement des ressources du cluster.

Les déploiements automatisés de Fleet Manager nécessitent également l’utilisation d’un registre de conteneurs Azure existant (ACR) et d’un espace de noms de cluster Fleet Manager Hub.

Puis-je me connecter au même référentiel Git plusieurs fois ?

Oui, vous pouvez vous connecter au même référentiel plusieurs fois pour vous permettre de déployer différentes ressources ou branches à partir du même référentiel.

Feuille de route

La feuille de route pour la ressource Azure Kubernetes Fleet Manager est disponible sur GitHub.

Étapes suivantes

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