Présentation de l'Azure Kubernetes Fleet Manager pour le placement intelligent des ressources

S’applique à ✔️ Gestionnaire de flotte avec un cluster central

La gestion des ressources Kubernetes sur plusieurs clusters présente des défis importants pour les administrateurs de plateforme et les développeurs d’applications. À mesure que les organisations mettent à l’échelle leur infrastructure Kubernetes au-delà d’un seul cluster, elles rencontrent souvent des complexités liées à la distribution des ressources, à la cohérence et à la surcharge de gestion manuelle. L’approche traditionnelle de la gestion de chaque cluster crée indépendamment des silos opérationnels qui deviennent de plus en plus difficiles à maintenir à mesure que la taille de la flotte augmente.

Les administrateurs de plateforme doivent souvent déployer des ressources Kubernetes sur plusieurs clusters pour différentes raisons, notamment :

• 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 et potentiellement sujet à des erreurs de créer, de suivre et de mettre à jour manuellement les ressources Kubernetes sur plusieurs clusters.

Dans cet article, nous allons découvrir comment utiliser la fonctionnalité de placement des ressources intelligentes de Fleet Manager pour la gestion de la distribution des ressources Kubernetes à l'échelle des clusters et des espaces de noms entre les clusters membres d'une flotte.

La fonctionnalité de placement des ressources de Fleet Manager est basée sur le projet KUBeFleet CNCF.

Vue d’ensemble du processus de placement des ressources

Pour utiliser le placement intelligent des ressources de Fleet Manager, procédez comme suit :

1. Mettre en scène des ressources sur un cluster hub : utilisez le déploiement continu, GitOps ou une méthode similaire pour appliquer les manifestes pour les distributions de ressources sur le cluster Hub Fleet Manager.
2. Créez un placement de ressource : créez un manifeste de placement qui sélectionne la ressource et définit une stratégie pour choisir les clusters membres qui reçoivent la ressource.
3. Appliquer le placement des ressources sur le cluster hub : appliquez le manifeste de placement au cluster hub pour commencer à distribuer la ressource.
4. Fleet Manager planifie les ressources : Fleet Manager observe le placement des ressources et l’étendue sélectionnée, et effectue la distribution des ressources.
5. Observez la distribution via le placement des ressources : interrogez l’emplacement des ressources sur le cluster hub pour vérifier l’état de la ressource au fur et à mesure qu’elle est déployée.

Fleet Manager a une expérience de portail Azure pour le placement des ressources qui fournit une représentation visuelle plus visuelle du déploiement.

Composants de placement des ressources

Un placement de ressources, quelle que soit l’étendue (cluster ou espace de noms), se compose des composants suivants :

• Sélecteurs de ressources : sélectionnez les ressources à inclure via resourceSelectors.
• Stratégie de placement : définissez comment sélectionner des clusters via placementType en utilisant l’un des types PickAll, PickFixed ou PickN.
• Stratégie de déploiement : contrôlez la façon dont les ressources sont déployées sur des clusters sélectionnés en incluant une option facultative strategy.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll   

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Sélecteurs de ressources

Sélectionnez des ressources à l’aide d’une ou plusieurs resourceSelectors dans un placement. Chaque sélecteur de ressources peut spécifier :

• Groupe, version, type (GVK) : type de ressource Kubernetes à sélectionner.
• Nom : nom d’une ressource spécifique.
• Sélecteurs d’étiquettes : permet de faire correspondre les étiquettes à plusieurs ressources.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Stratégie de placement

Le placement des ressources de Fleet Manager prend en charge les types de stratégies de placement suivants pour contrôler la manière dont il sélectionne les clusters :

• PickFixed place les ressources sur des clusters membres à l’aide de leurs noms de cluster.
• PickAll place des ressources sur tous les clusters membres ou tous les clusters membres qui répondent à des critères. Cette stratégie est utile pour placer des charges de travail d’infrastructure, telles que la supervision de cluster ou les applications de création de rapports.
• PickN est l’option de placement la plus flexible. Il vous permet de sélectionner des clusters en fonction des contraintes d’affinité ou de topologie. Utilisez cette stratégie lors de la répartition des charges de travail sur plusieurs clusters similaires pour garantir la disponibilité.

Type de placement PickFixed

Permet PickFixed de sélectionner les clusters par nom. Fournissez des noms dans le clusterNames tableau.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Type de placement PickAll

Permet PickAll de distribuer des ressources sur tous les clusters membres ou tous les clusters qui correspondent à un critère que vous spécifiez.

Lorsque vous créez ce type de placement, spécifiez les types d’affinité de cluster suivants :

• requiredDuringSchedulingIgnoredDuringExecution : cette stratégie étant requise lors de la planification, elle filtre les clusters en fonction des critères spécifiés.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

Type de placement PickN

Permet PickN de distribuer des ressources sur un nombre configurable de clusters en fonction des affinités et des contraintes de répartition de topologie.

Lorsque vous créez ce type de placement, spécifiez les types d’affinité de cluster suivants :

• requiredDuringSchedulingIgnoredDuringExecution : cette stratégie étant requise lors de la planification, elle filtre les clusters en fonction des critères spécifiés.
• preferredDuringSchedulingIgnoredDuringExecution : cette stratégie étant préférable mais pas obligatoire lors de la planification, elle classe les clusters en fonction de critères spécifiés.

Vous pouvez définir à la fois des affinités requises et préférées. Les affinités requises empêchent le placement dans des clusters qui ne correspondent pas. Les affinités préférées fournissent l’ordre des clusters correspondants.

PickN avec affinités

L’utilisation des affinités avec une PickN politique de placement fonctionne comme pour l’utilisation des affinités avec la planification des pods dans un cluster Kubernetes unique.

L’exemple suivant montre comment déployer une ressource sur 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/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-critical-preferences
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-critical-preferences
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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 des contraintes de répartition topologique

Utilisez des contraintes de répartition de topologie pour forcer les placements entre les limites de topologie pour répondre aux exigences de disponibilité.

Vous pouvez configurer le comportement des contraintes de répartition de topologie à l’aide de la whenUnsatisfiable propriété :

• DoNotSchedule : si la contrainte ne peut pas être satisfaite, rejetez la requête de placement.
• ScheduleAnyway: si la contrainte ne peut pas être respectée, placez quand même les ressources.

L’exemple suivant montre comment répartir des ressources entre plusieurs régions Azure et tenter de planifier des clusters membres avec des jours de mise à jour différents à l’aide d’une étiquette updateDaypersonnalisée.

Lorsque la répartition entre les régions Azure ne peut pas être respectée, le placement échoue. Si la updateDay contrainte n’est pas remplie, le placement se produit toujours.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-locations-updates
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-locations-updates
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Pour plus d’informations, consultez la documentation KubeFleet sur les contraintes de répartition de topologie.

Sélectionner des clusters à l’aide d’étiquettes et de propriétés

Le placement intelligent des ressources de Fleet Manager fournit un ensemble de critères puissants que vous pouvez utiliser pour déterminer la manière de sélectionner des clusters lors de l’utilisation des types de placement PickN et PickAll. Dans cette section, vous allez apprendre à utiliser ces options pour créer des stratégies qui répondent à vos besoins.

Options des stratégies de placement

Le tableau suivant présente les champs de stratégie de planification disponibles pour chaque type de placement.

Étiquettes des clusters membres

Vous pouvez étiqueter la MemberCluster ressource sur le cluster hub comme n’importe quelle ressource Kubernetes.

En outre, Fleet Manager ajoute automatiquement les étiquettes en lecture seule suivantes à tous les clusters membres.

Propriétés du cluster

Utilisez les propriétés suivantes dans le cadre des stratégies de placement.

• Les unités de ressources Kubernetes représentent les propriétés processeur et mémoire. Pour plus d’informations, consultez Unités de ressources dans Kubernetes.

• Les propriétés de coût sont des décimales qui représentent un coût par heure en dollars AMÉRICAINs pour le calcul Azure que les nœuds au sein du cluster utilisent. Le coût est basé sur les tarifs publics d’Azure.

Critères de correspondance de sélection

Lorsque vous utilisez des propriétés de cluster dans un critère de stratégie, spécifiez :

• Nom : Nom de la propriété, qui est l’une des propriétés répertoriées dans les propriétés de cet article.

• Opérateur : opérateur qui exprime la condition entre la contrainte ou la valeur souhaitée et la valeur observée sur le cluster. Les opérateurs suivants sont actuellement pris en charge :

  • Gt (Supérieur à) : la valeur observée d’un cluster de la propriété donnée doit être supérieure à la valeur de la condition avant de pouvoir être choisie pour le placement des ressources.
  • Ge (Supérieur ou égal à) : la valeur observée d’un cluster de la propriété donnée doit être supérieure ou égale à la valeur dans la condition avant de pouvoir être choisie pour le placement des ressources.
  • Lt (Inférieur à) : la valeur observée d’un cluster de la propriété donnée doit être inférieure à la valeur dans la condition avant de pouvoir être choisie pour le placement des ressources.
  • Le (Inférieur ou égal à) : la valeur observée d’un cluster de la propriété donnée doit être inférieure ou égale à la valeur dans la condition avant de pouvoir être choisie pour le placement des ressources.
  • Eq (Égal à) : la valeur observée d’un cluster de la propriété donnée doit être égale à la valeur dans la condition avant de pouvoir être choisie pour le placement des ressources.
  • Ne (Non égal à) : la valeur observée d’un cluster de la propriété donnée ne doit pas être égale à la valeur dans la condition avant de pouvoir être choisie pour le placement des ressources.

  Si vous utilisez l’opérateur Gt, Ge, Lt, Le, Eqou Ne, la liste des valeurs dans la condition doit avoir exactement une valeur.

• Valeurs : une liste de valeurs, qui sont des valeurs possibles de la propriété.

Fleet évalue chaque cluster en fonction des propriétés que vous spécifiez dans la condition. Si un cluster ne répond pas aux conditions répertoriées ci-dessous requiredDuringSchedulingIgnoredDuringExecution, Fleet exclut le cluster du placement des ressources.

Voici un exemple de stratégie de placement pour sélectionner seulement des clusters avec cinq nœuds ou plus.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickall-five-nodes
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-five-nodes
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

Fonctionnement du classement des propriétés

Lorsque vous utilisez preferredDuringSchedulingIgnoredDuringExecution, un trieur de propriétés classe tous les clusters de la flotte en fonction de leurs valeurs dans un ordre croissant ou décroissant. Les pondérations utilisées pour l’ordre sont calculées en fonction de la valeur que vous spécifiez.

Un trieur de propriétés se compose des éléments suivants :

• Nom : nom de la propriété du cluster.
• Ordre de tri: l’ordre de tri peut être Ascending ou Descending. Lorsque vous utilisez l’ordre Ascending, les clusters membres présentant des valeurs observées plus faibles sont privilégiés. Lorsque vous utilisez l’ordre Descending, les clusters de membres avec une valeur observée plus élevée sont privilégiés.

Pour plus d’informations, consultez la documentation KubeFleet sur la planification basée sur les propriétés.

Configuration de la stratégie de déploiement

Le placement des ressources Fleet Manager utilise une stratégie par défaut RollingUpdate pour contrôler la façon dont les ressources sont distribuées aux clusters membres.

Dans l'exemple suivant, le placement est déployé séquentiellement sur chaque cluster membre, avec un délai d'attente d'au moins unavailablePeriodSeconds entre chaque cluster.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pick-all-rolling
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

L’état de déploiement est considéré comme réussi si toutes les ressources sont correctement appliquées au cluster. Cet état n’est pas un état de ressource enfant en cascade. Par conséquent, il ne vérifie pas que les pods créés sur un cluster membre par un déploiement sont prêts.

Pour plus d’informations, consultez la documentation sur les stratégies de déploiement.

Utilisation de tolérances

Vous pouvez appliquer des taints aux clusters membres, tout comme vous le faites aux nœuds d’un cluster.

Les placements de ressources prennent en charge l'utilisation de tolérances, chacune d'entre elles comprenant les 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 sert à tolérer un ou plusieurs marqueurs spécifiques appliqués à un MemberCluster. Une fois tous les marqueurs tolérés, Fleet Manager peut distribuer les ressources au cluster membre.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: test-ns
spec:
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-ns
      version: v1
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Pour plus d’informations, consultez la documentation sur les tolérances.

Utilisation des ressources d’enveloppe

Le cluster Hub Fleet Manager est également un cluster Kubernetes. Vous appliquez d’abord toute ressource que vous souhaitez distribuer au cluster hub. Cette approche peut conduire à :

1. Effets secondaires indésirables : les contrôleurs ValidatingWebhookConfigurations, MutatingWebhookConfigurations ou Admission Controllers s'activent sur le cluster hub, ce qui peut entraîner l'interception et l'altération des opérations de ce dernier.

2. Risques de sécurité : les ressources RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) destinées aux clusters membres peuvent accorder ou restreindre des autorisations sur le cluster central.

3. Limitations des ressources : ResourceQuotas, FlowSchema ou LimitRanges définis pour les clusters membres prennent effet sur le cluster hub.

Pour éviter les effets secondaires inutiles, Fleet Manager fournit des ressources d’enveloppe personnalisées (ClusterResourceEnvelope et ResourceEnvelope) pour encapsuler les objets et éviter ces problèmes potentiels.

Vous appliquez la ressource d’enveloppe au cluster hub, mais les ressources qu’elle contient sont extraites et appliquées lorsqu’elles atteignent des clusters membres.

Pour plus d’informations, consultez la documentation sur les objets d’enveloppe.

Déterminer l’état du placement

Le placement des ressources dans Fleet Manager offre deux manières de visualiser l'état selon le niveau d’accès et les besoins de votre cluster hub.

kubectl describe resourceplacement place-cmap-1

kubectl describe clusterresourceplacement crp-1

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1
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

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-with-status-reporting
spec:
  statusReportingScope: NamespaceAccessible
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

kubectl describe clusterresourceplacementstatuses.v1beta1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app

Déclencheurs de modification du placement

Le planificateur Fleet Manager hiérarchise la stabilité des placements de ressources existants. Cette priorité limite le nombre de modifications qui suppriment et replanifient une ressource.

Les scénarios suivants peuvent déclencher des modifications de sélection élective :

• Les modifications de stratégie de placement dans le placement des ressources (ClusterResourcePlacement ou ResourcePlacement) peuvent déclencher la suppression et la réécriture d’une ressource.
  • Les opérations de scale-out (augmentant numberOfClusters sans aucune autre modification) placent uniquement les charges de travail sur de nouveaux clusters et n’affectent pas les placements existants.
• Modifications du cluster de membres, notamment :
  • Un nouveau cluster membre devenant éligible et respectant la stratégie de placement, par exemple, une stratégie PickAll.
  • Suppression d’un cluster membre de la flotte. Selon la stratégie, le planificateur tente de placer toutes les ressources affectées sur les clusters restants sans affecter les placements existants.

La mise à jour des ressources sélectionnées (par exemple, la modification d’un Deployment) ou la mise à jour de resourceSelector dans un placement de ressource amène Fleet Manager à déployer progressivement les placements existants, mais ne déclenche pas la replanification de la ressource (c’est-à-dire le changement des clusters sélectionnés).

Utilisation de ResourcePlacement et clusterResourcePlacement ensemble

Bien que ClusterResourcePlacement suppose que les espaces de noms représentent des limites d'application, les modèles d'utilisation dans le monde réel sont souvent plus complexes. Les organisations utilisent fréquemment des espaces de noms en tant que limites d’équipe plutôt que des limites d’application, ce qui entraîne plusieurs défis qui ResourcePlacement traitent directement :

Espaces de noms multi-applications : dans de nombreuses organisations, un espace de noms unique contient plusieurs applications indépendantes appartenant à la même équipe. Ces applications peuvent avoir :

• Différentes exigences de cycle de vie (une application peut nécessiter des mises à jour fréquentes alors qu’une autre reste stable).
• Différents besoins de placement de cluster (développement et applications de production).
• Exigences de mise à l’échelle et de ressources indépendantes.
• Exigences de conformité ou de gouvernance distinctes.

Décisions de planification individuelles : de nombreuses charges de travail, en particulier les travaux IA/ML, nécessitent des décisions de planification individuelles :

• Travaux IA : les charges de travail Machine Learning se composent souvent de travaux à courte durée de vie et nécessitant beaucoup de ressources qui doivent être planifiés en fonction de la disponibilité des ressources de cluster, de la disponibilité gpu ou de la localité des données.
• Charges de travail batch : différents travaux de traitement par lots dans le même espace de noms peuvent cibler différents types de cluster en fonction des exigences de calcul.

Contrôle complet de l’équipe d’application : ResourcePlacement fournit aux équipes d’application un contrôle direct sur leur positionnement des ressources sans nécessiter d’intervention de l’équipe de plateforme :

• Opérations en libre-service : Teams peut gérer ses propres stratégies de distribution des ressources.
• Cycles de déploiement indépendants : différentes applications au sein d’un espace de noms peuvent avoir des planifications de déploiement indépendantes.
• Fonctionnalités de remplacement granulaires : Teams peut personnaliser les configurations de ressources par cluster sans affecter d’autres applications dans l’espace de noms.

Cette approche granulaire garantit qu’elle ResourcePlacement peut s’adapter à diverses structures organisationnelles et modèles de charge de travail tout en conservant la simplicité et la puissance de l’infrastructure de planification de la flotte.

Principales différences entre ResourcePlacement et ClusterResourcePlacement

Le tableau suivant met en évidence les principales différences entre ResourcePlacement et ClusterResourcePlacement:

Les deux ResourcePlacement et ClusterResourcePlacement partagent les mêmes fonctionnalités principales pour tous les autres aspects non répertoriés dans le tableau des différences.

Exemple de scénario utilisant ResourcePlacement et ClusterResourcePlacement

ResourcePlacement fonctionne avec ClusterResourcePlacement (CRP) pour fournir une solution complète de gestion des ressources multicluster. Comprendre cette relation est cruciale pour une gestion efficace de la flotte.

Flux de travail classique :

1. Administrateurs de plateforme : utilisez ClusterResourcePlacement pour déployer des espaces de noms sur l’ensemble de la flotte.
2. Équipes d’application : utilisez ResourcePlacement pour gérer des ressources spécifiques au sein de ces espaces de noms définis.

Les exemples suivants montrent comment coordonner la CRP et la RP.

Administrateur de la plateforme : Créez l’espace de noms à l’aide de ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

Équipe d’application : Gérer des ressources spécifiques dans l’espace de noms à l’aide de ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Meilleures pratiques pour ResourcePlacement et ClusterResourcePlacement

Lorsque vous utilisez ResourcePlacementClusterResourcePlacement, suivez les bonnes pratiques suivantes :

• Établissez d’abord des espaces de noms : déployez toujours des espaces de noms via CRP avant de créer des ResourcePlacement objets.
• Surveiller les dépendances : utilisez la surveillance de la flotte pour vous assurer que les CRPs de niveau espace de noms sont en bon état avant de déployer les RPs dépendants.
• Coordonner les stratégies : alignez les stratégies de placement de CRP et de RP pour éviter les conflits. Par exemple, si CRP place l’espace de noms sur les clusters A, B et C, RP peut cibler n’importe quel sous-ensemble de ces clusters.
• Limites de l’équipe : Utilisez CRP pour les ressources gérées par la plateforme (espaces de noms, RBAC) et rp pour les ressources gérées par l’application (configurations d’application, secrets).

Cette approche coordonnée garantit qu'ResourcePlacement offre la flexibilité dont les équipes ont besoin tout en maintenant l'infrastructure de base gérée par les opérateurs de plateforme.

Sélection, placement et déploiement des ressources

ResourcePlacement utilise les mêmes modèles de placement que ClusterResourcePlacement:

• Stratégie de placement : PickAll, PickFixedet les PickN stratégies fonctionnent de manière identique pour les deux API.
• Stratégie de déploiement : contrôlez la propagation des mises à jour entre les clusters avec les mêmes mécanismes de mise à jour propagée.
• État et observabilité : surveillez la progression du déploiement à l’aide kubectl describe resourceplacement <name> -n <namespace>de .
• Fonctionnalités avancées : utilisez des tolérances, des remplacements de ressources, des contraintes de répartition de topologie et des règles d’affinité.

La principale différence réside dans l’étendue de la sélection des ressources . Bien que ClusterResourcePlacement sélectionne généralement des espaces de noms entiers avec leur contenu, ResourcePlacement fournit un contrôle précis sur des ressources limitées à un espace de noms.

:::zone-end

Étapes suivantes

• Utilisez le placement des ressources Fleet Manager pour déployer des charges de travail sur plusieurs clusters.
• Utilisation de ResourcePlacement pour déployer des ressources délimitées à l’espace de noms.
• Placement intelligent des ressources Kubernetes entre clusters en fonction des propriétés des clusters membres.
• Gestion de l’éviction et des perturbations lors du placement des ressources.
• Définition d’une stratégie de déploiement pour un placement de ressources.
• FAQ sur le placement des ressources Fleet Manager.