Vue d’ensemble du cluster hub Fleet Manager

Lorsqu’il est activé, le cluster hub Fleet Manager sert de point de gestion central pour la propagation des ressources Kubernetes entre les clusters membres en utilisant le placement des ressources.

Qu’est-ce que les clusters Hub Fleet Manager ?

Dans Azure Kubernetes Fleet Manager, les clusters hub jouent un rôle crucial dans la gestion de plusieurs clusters membres, mais ils sont facultatifs.

Le cluster hub facilite le placement des ressources et les espaces de noms gérés de la flotte via une version managée de KubeFleet.

Dans cette configuration, une flotte se compose des composants suivants :

• flotte-hub-agent : contrôleur Kubernetes qui crée et fait concorder toutes les ressources personnalisées (CR) liées à la flotte dans le cluster hub.
• flotte-membre-agent : contrôleur Kubernetes qui crée et fait concorder toutes les ressources personnalisées (CR) liées à la flotte dans les clusters membres. Ce contrôleur extrait les dernières ressources personnalisées du cluster hub et fait systématiquement concorder les clusters membres à faire correspondre à l’état souhaité.

Configuration du cluster hub

Un cluster hub Fleet Manager est un cluster Azure Kubernetes Service (AKS) entièrement managé qui a les propriétés suivantes :

• Nom et emplacement du cluster : le cluster hub est toujours nommé hub et est créé dans la même région Azure que Fleet Manager.
• Groupe de ressources Azure pour le cluster hub : la ressource AKS du cluster hub est créée dans un groupe de ressources managé avec le format de nommage FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}.
• Groupe de ressources Azure pour les ressources de cluster hub : comme n’importe quel cluster AKS, le cluster hub possède des ressources Azure telles qu’un groupe de machines virtuelles identiques de pool de nœuds agents et un réseau virtuel qui sont créés dans un groupe de ressources managé avec le format de nommage MC_FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}.
• Nœud du cluster hub : le cluster hub dispose d’un pool de nœuds avec un nœud unique exécutant Azure Linux. Le nœud n’exécute aucun pod et n’affecte pas les performances du cluster hub. Lors de la création d’un cluster hub à partir d’Azure CLI, vous pouvez choisir le type de référence SKU de machine virtuelle du nœud à l’aide du paramètre --vm-size.
• Configuration réseau : les clusters hub publics ont un serveur d’API public, avec une adresse IP publique associée. Lorsqu’il est configuré pour l’accès privé, le serveur d’API est accessible uniquement via un réseau virtuel Azure.

Restrictions relatives au cluster hub

Le cluster hub présente les restrictions suivantes qui garantissent son bon fonctionnement pour la propagation et la gestion des ressources :

• Appel de commandes désactivé : l’appel de commandes via Azure CLI (az aks command invoke) est désactivé pour les clusters hub.
• Authentification locale désactivée : l’accès via l’administrateur kubeconfig est désactivé, garantissant que l’authentification est exclusivement gérée par Microsoft Entra ID, ce qui améliore la sécurité en centralisant le contrôle des accès. Utilisez az fleet get-credentials pour obtenir le kubeconfig du cluster hub.
• Affectations de refus : les modifications apportées à la configuration Azure du cluster hub et aux ressources associées sont bloquées via les affectations de refus Azure. Les affectations de refus suivantes sont utilisées :
  • FLRG-DenyAssignments-{guid} : appliqué au groupe de ressources du cluster hub, empêchant les utilisateurs de modifier le cluster hub.
  • kubernetes.azure.com/{guid} (facultatif) : cette affectation de refus empêche les utilisateurs de modifier les ressources AKS du cluster hub (groupes de machines virtuelles identiques, réseaux), comme décrit dans Verrouillage du groupe de ressources des nœuds AKS.
• Ressources appliquées non instanciées : le cluster hub ne planifie pas les ressources Kubernetes appliquées sur le nœud du cluster hub. Certaines ressources Kubernetes doivent être appliquées à l’aide d’un objet enveloppe afin d’éviter les effets secondaires sur le cluster hub. Pour plus d’informations sur les objets d’enveloppe, consultez la documentation des objets d’enveloppe.

Restrictions d’accès aux ressources protégées

Les demandes d’API Kubernetes suivantes sont refusées :

• Toutes les demandes d’usurpation d’identité.
• Toutes les opérations autres que get, listet watch dans les espaces de noms avec des noms commençant par fleet- ou kube-.
• get, listet watch demandes de pods, de secrets, de comptes de service, de rôles et de liaisons de rôles dans les espaces de noms avec des noms qui commencent par fleet- ou kube-.
• Requêtes list et watch entre espaces de noms pour les pods, les secrets, les comptes de service, les rôles et les liaisons de rôle.
• Écrire des requêtes pour les rôles de cluster et les liaisons de rôles de cluster.
• Requêtes de lecture et d’écriture sur le sous-ressource nodes/proxy.
• Écrivez des demandes pour valider des stratégies d’admission, valider des liaisons de stratégie d’admission et valider des configurations de webhook avec des noms qui commencent par fleet-builtin-.
• Requêtes de suppression de collections pour les stratégies d’admission de validation, les liaisons de stratégies d’admission de validation et les configurations de webhooks de validation.

D’autres opérations prises en charge dans les espaces de noms gérés par le client restent disponibles.

Identifier les ressources et l’automatisation de Fleet Manager affectées

Une ressource Fleet Manager est potentiellement affectée si elle a un cluster hub activé. Utilisez Azure Resource Graph Explorer pour rechercher ces ressources :

Resources
| where type =~ "microsoft.containerservice/fleets"
| where isnotnull(properties.hubProfile)
| project id, name, subscriptionId, resourceGroup, location

Le fait d’avoir un cluster hub ne signifie pas nécessairement que vous devez prendre des mesures. Vous n’êtes affecté que si vos utilisateurs, scripts, contrôleurs ou pipelines CI/CD envoient l’une des demandes restreintes au cluster hub.

Passez en revue l’automatisation qui accède au cluster hub pour :

• Options d’usurpation d’identité ou en-têtes, y compris --as et --as-group.
• Demandes adressées à nodes/proxy.
• Accès aux espaces de noms avec des noms commençant par fleet- ou kube-.
• Requêtes de liste et de surveillance à l’échelle du cluster ou de --all-namespaces pour les ressources protégées.
• Modifications apportées aux rôles de cluster ou aux liaisons de rôles de cluster.
• Modifications apportées aux ressources de validation dont le nom commence par fleet-builtin-.
• Suppression de collections de ressources de validation.

Mettez à jour l’automatisation affectée

Avant le 31 janvier 2027 :

• Déplacez les ressources détenues par le client et l’automatisation hors des espaces de noms avec des noms commençant par fleet- ou kube-.
• Limiter les requêtes de liste et de surveillance concernant les pods, les secrets, les comptes de service, les rôles et les liaisons de rôles aux espaces de noms gérés par le client.
• Pour le placement des ressources, encapsulez les rôles de cluster et les liaisons de rôles de cluster dans un ClusterResourceEnvelope. Pour plus d’informations, consultez Utiliser des objets d’enveloppe pour placer des ressources en toute sécurité.
• Pour l'accès par programmation au cluster hub, utilisez une identité Microsoft Entra dédiée, attribuez-lui le rôle RBAC Fleet Manager le moins privilégié requis et n'utilisez pas l'usurpation d'identité.
• Arrêtez d’utiliser la sous-ressource nodes/proxy.
• Ne modifiez pas les ressources de validation avec des noms commençant par fleet-builtin-.
• Remplacer la suppression de collections de ressources de validation par des requêtes limitées aux ressources gérées par le client.
• Testez l’automatisation mise à jour avant la date d’application.

Si vous ne mettez pas à jour les automatisations concernées avant le 31 janvier 2027, leurs requêtes restreintes recevront des réponses indiquant un refus d’autorisation. Les scripts, contrôleurs, déploiements ou flux de travail opérationnels qui dépendent de ces requêtes risquent d’échouer ou de réessayer de manière répétée. Si vous n’utilisez aucune opération restreinte, aucune action n’est requise.

Exigences des clients

Pour que Fleet Manager crée et conserve les clusters hub à jour avec des derniers correctifs, assurez-vous que :

• Azure Policy ne bloque pas la création du cluster. Le cluster hub est un cluster AKS managé. Si vous ne pouvez pas créer de clusters AKS, vous ne pouvez pas créer de cluster Hub Fleet Manager.

• L’abonnement dispose d’un quota suffisant. Une instance de machine virtuelle supplémentaire du nœud du cluster hub est requise pendant le processus de mise à niveau du cluster. Pour plus d’informations sur l’augmentation du quota, consultez la documentation sur le quota.

• Le cluster hub dispose d’un accès Internet. La connectivité sortante est requise pour installer les mises à jour. Les hubs privés sur des réseaux avec un routage défini par l’utilisateur (UDR) ou des règles de pare-feu peuvent bloquer la connectivité sortante. Pour plus d’informations sur la connectivité sortante, consultez la documentation sur le réseau sortant AKS.

• Le serveur d’API peut atteindre les nœuds hub. Si les règles de groupe de sécurité réseau sur un cluster de hub privé avec intégration au réseau virtuel du serveur d’API limitent le trafic entre les sous-réseaux, autorisez le trafic entrant du sous-réseau du serveur d’API vers le sous-réseau du cluster sur le port TCP 10250. Sans cette règle, les opérations qui utilisent l’API kubelet, telles que la récupération des journaux ou l’exécution de exec, échouent. Pour toutes les règles requises, consultez les règles de sécurité du groupe de sécurité réseau pour l’intégration au réseau virtuel du serveur d’API.

• Il n’est pas nécessaire de gérer les mises à jour du cluster hub Fleet Manager. Microsoft met automatiquement à jour le cluster hub vers la dernière version de Kubernetes ou de l’image de nœud dès qu’elles sont disponibles depuis AKS. Les versions de mise à jour peuvent être suivies sur AKS Release Tracker.

Contenu connexe

• Placement intelligent des ressources Kubernetes entre clusters en fonction des propriétés des clusters membres.
• Accédez à l’API Kubernetes du cluster Hub Fleet Manager.
• Forum aux questions sur Fleet Manager.