Share via

Propagation des ressources Kubernetes d’un cluster hub vers des clusters membres

  • Article

Cet article décrit les concepts de la propagation des ressources Kubernetes de clusters hubs vers des clusters membres à l’aide d’Azure Kubernetes Fleet Manager (Fleet).

Les administrateurs de plateforme doivent souvent déployer des ressources Kubernetes dans plusieurs clusters pour plusieurs raisons, par exemple :

  • Gestion du contrôle d’accès à l’aide de rôles et de liaisons de rôles sur plusieurs clusters.
  • Exécution d’applications d’infrastructure, telles que Prometheus ou Flux, qui doivent se trouver sur tous les clusters.

Les développeurs d’applications doivent souvent déployer des ressources Kubernetes dans plusieurs clusters pour plusieurs raisons, par exemple :

  • Déploiement d’une application de service vidéo dans plusieurs clusters de différentes régions, pour une expérience de visionnage avec une latence faible.
  • Déploiement d’une application de panier d’achat dans deux régions appairées pour que les clients puissent continuer leurs achats pendant une panne d’une région unique.
  • Déploiement d’une application de calcul par lots dans des clusters avec des pools de nœuds spot peu coûteux disponibles.

Il est fastidieux de créer, de mettre à jour, puis de suivre manuellement ces ressources Kubernetes sur plusieurs clusters. Fleet assure la propagation des ressources Kubernetes pour permettre une gestion à l’échelle des ressources Kubernetes. Avec Fleet, vous pouvez créer des ressources Kubernetes dans le cluster hub, puis les propager à des clusters membres sélectionnés via des ressources personnalisées Kubernetes : MemberCluster et ClusterResourcePlacement. Fleet prend en charge ces ressources personnalisées basées sur une solution multicluster open source native Cloud. Si vous souhaitez en savoir plus, veuillez consulter la documentation Fleet en amont.

Important

Les fonctionnalités d’évaluation d’Azure Kubernetes Fleet Manager sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions d’Azure Kubernetes Fleet Manager sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production.

Flux de travail de propagation des ressources

Diagramme montrant comment la ressource Kubernetes est propagée aux clusters membres.

Qu’est-ce qu’un MemberCluster ?

Une fois qu’un cluster rejoint une flotte, une ressource personnalisée MemberCluster correspondante est créée sur le cluster hub. Vous pouvez utiliser cette ressource personnalisée pour sélectionner des clusters cibles dans la propagation des ressources.

Les étiquettes suivantes permettent la sélection de clusters cibles dans la propagation des ressources et sont automatiquement ajoutées à tous les clusters membres :

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Si vous souhaitez en savoir plus d’informations, veuillez consulter les informations de référence sur l’API MemberCluster.

Qu’est-ce qu’un ClusterResourcePlacement ?

Un objet ClusterResourcePlacement est utilisé pour indiquer au planificateur Fleet comment placer un ensemble donné d’objets délimité à un cluster du cluster hub dans des clusters membres. Les objets délimités à un espace de noms tels que Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets et PersistentVolumeClaims sont inclus lorsque leur espace de noms contenant est sélectionné.

Avec ClusterResourcePlacement, vous pouvez :

  • Sélectionner les ressources Kubernetes délimitées au cluster à propager aux clusters membres.
  • Spécifiez des stratégies de sélection élective pour sélectionner manuellement ou automatiquement un sous-ensemble ou tous les clusters membres en tant que clusters cibles.
  • Spécifiez des stratégies de lancement pour déployer de façon sécurisée les mises à jour des ressources Kubernetes sélectionnées sur plusieurs clusters cibles.
  • Visualisez la progression de la propagation vers chaque cluster cible.

L’objet ClusterResourcePlacement prend en charge l’utilisation de ConfigMap pour envelopper l’objet et faciliter ainsi la propagation vers les clusters membres sans effets secondaires inattendus. Les méthodes de connexion sont les suivantes :

  • Groupe, version et type : sélectionnez, puis placez toutes les ressources du type donné.
  • Groupe, version, type et nom : sélectionnez, puis placez une ressource particulière d’un type donné.
  • Groupe, version, type et étiquettes : sélectionnez, puis placez toutes les ressources d’un type donné qui correspondent aux étiquettes fournies.

Pour plus d’informations, consultez les informations de référence sur l’API ClusterResourcePlacement.

Lorsque vous créez le ClusterResourcePlacement, vous devez spécifier les types d’affinité suivants :

  • requiredDuringSchedulingIgnoredDuringExecution : étant donné que cette affinité est le type requis pendant la planification, elle filtre les clusters basés sur ces propriétés.
  • preferredDuringSchedulingIgnoredDuringExecution : étant donné que cette affinité est uniquement le type préféré, mais qu’il n’est pas requis pendant la planification, il fournit un classement par ordre de priorité préférentiel aux clusters basés sur des propriétés spécifiées par vous comme coût ou disponibilité de ressource.

Plusieurs types de placement sont disponibles pour contrôler le nombre de clusters vers lesquels la ressource Kubernetes doit être propagée :

  • PickAll place les ressources dans tous les clusters membres disponibles. Cette stratégie est utile pour placer des charges de travail d’infrastructure, telles que les applications de création de rapports ou de supervision de cluster.
  • PickFixed place les ressources dans une liste spécifique de clusters membres par nom.
  • PickN est l’option de sélection élective la plus flexible ; elle permet de sélectionner des clusters en fonction de contraintes de répartition de topologie ou de l’affinité et est utile lors de la répartition des charges de travail sur plusieurs clusters appropriés pour garantir la disponibilité souhaitée.

Stratégie de sélection élective PickAll

Vous pouvez utiliser une stratégie de placement PickAll pour déployer une charge de travail sur tous les clusters membres de la flotte (éventuellement en fonction d’un ensemble de critères).

L’exemple suivant montre comment déployer un espace de noms test-deployment et tous ses objets sur tous les clusters étiquetés avec environment: production :

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-1
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

Cette stratégie simple prend l’espace de noms test-deployment et toutes les ressources qu’il contient, et le déploie sur tous les clusters membres de la flotte avec l’étiquette environment donnée. Si vous désirez tous les clusters, supprimez entièrement le terme affinity.

Stratégie de sélection élective PickFixed

Si vous souhaitez déployer une charge de travail dans un ensemble connu de clusters membres, vous pouvez utiliser une stratégie de sélection élective PickFixed pour sélectionner les clusters par nom.

L’exemple suivant montre comment déployer l’espace de noms test-deployment dans des clusters membres cluster1 et cluster2 :

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-2
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

Stratégie de sélection élective PickN

La stratégie de placement PickN est l’option la plus flexible ; elle permet le placement de ressources dans un nombre configurable de clusters en fonction des affinités et des contraintes de répartition de topologie.

PickN avec affinités

L’utilisation d’affinités avec une sélection élective PickN fonctionne de manière similaire à l’utilisation d’affinités avec la planification des pods. Vous pouvez définir à la fois des affinités requises et préférées. Les affinités requises empêchent la sélection élective de clusters avec lesquels il n’existe aucune correspondance. Les affinités préférées permettent d’ordonner l’ensemble de clusters valides lorsqu’une décision de sélection élective est prise.

L’exemple suivant indique comment déployer une charge de travail dans trois clusters. Seuls les clusters qui ont l’étiquette critical-allowed: "true" sont des cibles de sélection élective valides et la préférence est donnée aux clusters avec l’étiquette critical-level: 1 :

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN avec contraintes de répartition de topologie

Vous pouvez utiliser des contraintes de répartition de topologie pour forcer la division des sélections électives de cluster à travers les limites de topologie, pour répondre aux exigences de disponibilité par exemple, en fractionnant des sélections électives sur plusieurs régions ou les boucles de mise à jour. Vous pouvez également configurer des contraintes de répartition de topologie pour empêcher la planification si la contrainte ne peut pas être satisfaite (whenUnsatisfiable: DoNotSchedule) ou pour planifier le mieux possible (whenUnsatisfiable: ScheduleAnyway).

L’exemple suivant montre comment répartir un ensemble donné de ressources sur plusieurs régions et tente de planifier sur des clusters membres avec des jours de mise à jour différents :

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Si vous souhaitez en savoir plus, veuillez consulter la documentation Fleet sur les contraintes de répartition de la topologie en amont.

Stratégie de mise à jour

Fleet utilise une stratégie de mise à jour propagée pour contrôler le déploiement des mises à jour sur plusieurs sélections électives de clusters.

L’exemple suivant montre comment configurer une stratégie de mise à jour propagée à l’aide des paramètres par défaut :

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Le planificateur déploie les mises à jour sur chaque cluster de manière séquentielle, en attendant au moins unavailablePeriodSeconds entre les clusters. L’état de déploiement est considéré comme réussi si toutes les ressources ont été correctement appliquées au cluster. La vérification de l’état de lancement ne se propage pas en cascade jusqu’aux ressources enfants ; par exemple, cette fonction ne confirme pas que les pods créés par un déploiement sont prêts.

Si vous souhaitez en savoir plus, veuillez consulter la documentation Fleet sur la stratégie de lancement en amont.

État du placement

Le planificateur Fleet met à jour les détails et l’état des décisions de sélection élective sur l’objet ClusterResourcePlacement. Vous pouvez afficher ces informations via la commande kubectl describe crp <name>. La sortie comprend les informations suivantes :

  • Conditions qui s’appliquent actuellement à la sélection élective, y compris si la sélection élective a été correctement effectuée.
  • Une section sur l’état de la sélection élective pour chaque cluster membre, qui indique l’état du déploiement sur ce cluster.

L’exemple suivant montre un ClusterResourcePlacement qui a déployé l’espace de noms test et la mappe ConfigMap test-1 dans deux clusters membres via PickN. Le placement a été effectué avec succès, et les ressources ont été placées dans les clusters aks-member-1 et aks-member-2.

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

Modifications de placement

Le planificateur Fleet classe par ordre de priorité la stabilité des sélections électives de charges de travail existantes. Ce classement par ordre de priorité peut limiter le nombre de modifications qui entraînent la suppression et la replanification d’une charge de travail. Les scénarios suivants peuvent déclencher des modifications de sélection élective :

  • Les modifications de stratégie de sélection élective dans l’objet ClusterResourcePlacement peuvent déclencher la suppression et la replanification d’une charge de travail.
    • Les opérations de scale-out (augmentant numberOfClusters sans aucune autre modification) placent les charges de travail uniquement sur de nouveaux clusters et n’affectent pas les sélections électives existantes.
  • Modifications de clusters, y compris ce qui suit :
    • Un nouveau cluster devenant éligible peut déclencher une sélection élective en cas de conformité à la stratégie de sélection élective, par exemple une stratégie PickAll.
    • Si un cluster avec une sélection élective est supprimé de la flotte, il tentera de replacer toutes les charges de travail affectées sans affecter leurs autres sélections électives.

Les modifications de ressources uniquement (mise à jour des ressources ou mise à jour du ResourceSelector dans l’objet ClusterResourcePlacement) sont lancées progressivement dans les sélections électives existantes mais ne déclenchent pas la replanification de la charge de travail.

Tolérances

ClusterResourcePlacement les objets prennent en charge la spécification des tolérances, qui s’appliquent à l’objet ClusterResourcePlacement. Chaque objet de tolérance se compose des champs suivants :

  • key : la clé de la tolérance.
  • value : la valeur de la tolérance.
  • effect : l’effet de la tolérance, par exemple NoSchedule.
  • operator : l’opérateur de la tolérance, tel que Exists ou Equal.

Chaque tolérance est utilisée pour tolérer une ou plusieurs teintes spécifiques appliquées sur le ClusterResourcePlacement. Une fois que toutes les teintes sur un MemberCluster sont tolérées, le planificateur peut propager des ressources au cluster. Vous ne pouvez pas mettre à jour ou supprimer des tolérances d’un objet ClusterResourcePlacement une fois qu’il a été créé.

Si vous souhaitez en savoir plus, veuillez consulter la documentation Fleet en amont.

Accéder à l’API Kubernetes du cluster de la ressource de flotte

Si vous avez créé la ressource Azure Kubernetes Fleet Manager avec le cluster hub activé, vous pouvez l’utiliser pour contrôler de manière centralisée des scénarios tels que la propagation d’objets Kubernetes. Pour accéder à l’API Kubernetes du cluster de la ressource Fleet, suivez les étapes décrites dans Accéder à l’API Kubernetes du cluster de la ressource Fleet avec Azure Kubernetes Fleet Manager.

Étapes suivantes

Configurer la propagation des ressources Kubernetes d’un cluster hub vers des clusters membres.