Placement de ressources Kubernetes d’un cluster hub vers des clusters membres
Cet article décrit les concepts du placement des ressources Kubernetes de clusters hubs vers des clusters membres en utilisant Azure Kubernetes Fleet Manager (Kubernetes Fleet).
Les administrateurs de plateforme doivent souvent déployer des ressources Kubernetes sur plusieurs clusters pour différentes 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 Kubernetes 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.
Kubernetes Fleet prend en charge ces ressources personnalisées via une solution open source native Cloud sur laquelle vous pouvez en savoir plus en lisant la documentation de Fleet open source.
Présentation de ClusterResourcePlacement
Un objet ClusterResourcePlacement est utilisé pour indiquer au planificateur de flotte comment placer un ensemble donné d’objets délimités à un cluster du cluster hub de flottes sur 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 placement pour sélectionner manuellement ou automatiquement des 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.
Le diagramme ci-dessous en fournit un exemple.
Encapsuler des ressources
ClusterResourcePlacement prend en charge l’utilisation de ConfigMap pour envelopper certains types de ressources Kubernetes pour qu’elles puissent être placées sur le cluster hub sans aucun effet secondaire involontaire sur le cluster hub. Pour obtenir la liste des types de ressources et comprendre le fonctionnement de cette fonctionnalité, consultez notre documentation sur les objets d’enveloppe.
Types de placements
Les types de placement suivants sont disponibles pour contrôler le nombre de clusters auxquels une ressource Kubernetes spécifiée doit être propagée :
- PickFixed place les ressources sur une liste spécifique de clusters membres par leur nom.
- PickAll place la ressource 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 les applications de création de rapports ou de supervision de cluster.
- PickN est l’option de placement la plus flexible ; elle permet de sélectionner des clusters en fonction de contraintes d’affinité ou de répartition de topologie, et elle est utile lors de la répartition de charges de travail sur plusieurs clusters appropriés pour garantir la disponibilité souhaitée.
Type de placement PickFixed
Si vous voulez déployer une charge de travail sur un ensemble connu de clusters membres, vous pouvez utiliser une stratégie de placement PickFixed pour sélectionner les clusters par leur nom.
clusterNames est la seule option de stratégie valide pour ce type de placement.
L’exemple suivant montre comment déployer l’espace de noms test-deployment sur des clusters membres cluster1 et cluster2.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-fixed
spec:
policy:
placementType: PickFixed
clusterNames:
- cluster1
- cluster2
resourceSelectors:
- group: ""
kind: Namespace
name: test-deployment
version: v1
Type de placement 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 ou sur un sous-ensemble de clusters correspondant à des critères que vous définissez.
Quand vous créez ce type de placement, les types d’affinité de clusters suivants peuvent être spécifiés :
- requiredDuringSchedulingIgnoredDuringExecution : cette stratégie étant requise lors de la planification, elle filtre les clusters en fonction des critères spécifiés.
L’exemple suivant montre comment déployer un espace de noms prod-deployment et tous ses objets sur tous les clusters étiquetés avec environment: production :
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickall
spec:
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
environment: production
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
Type de placement PickN
Le type de placement PickN est l’option la plus flexible ; elle permet le placement de ressources dans un nombre de clusters configurable en fonction des affinités et des contraintes de répartition de topologie.
Quand vous créez ce type de placement, les types d’affinité de clusters suivants peuvent être spécifiés :
- 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 sur des clusters qui ne correspondent pas aux critères, et les affinités préférées déterminent l’ordre des clusters valides.
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.
L’exemple suivant montre comment déployer une charge de travail 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-01
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 placements de clusters à travers les limites de la topologie pour répondre à des exigences de disponibilité. Par exemple, utilisez ces contraintes pour diviser les placements entre des régions ou des 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 entre plusieurs régions et tente de planifier sur des clusters membres avec des jours de mise à jour différents.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-02
spec:
resourceSelectors:
- ...
policy:
placementType: PickN
topologySpreadConstraints:
- maxSkew: 2
topologyKey: region
whenUnsatisfiable: DoNotSchedule
- maxSkew: 2
topologyKey: updateDay
whenUnsatisfiable: ScheduleAnyway
Pour plus d’informations, consultez les contraintes de répartition de topologie dans la documentation de Fleet open source.
Options des stratégies de placement
Le tableau récapitule les champs de stratégie de planification disponibles pour chaque type de placement.
| Champ Stratégie | PickFixed | PickAll | PickN |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
Sélection des clusters en fonction d’étiquettes et de propriétés
Étiquettes et propriétés disponibles pour sélectionner des clusters
Quand vous utilisez les types de placement PickN et PickAll, vous pouvez utiliser les étiquettes et les propriétés suivantes dans le cadre de vos stratégies.
Étiquettes
Les étiquettes suivantes sont ajoutées automatiquement à tous les clusters membres et peuvent être utilisées pour la sélection de clusters cibles dans les stratégies de placement des ressources.
| Étiquette | Description |
|---|---|
| fleet.azure.com/location | Région Azure du cluster (westus) |
| fleet.azure.com/resource-group | Groupe de ressources Azure du cluster (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Identificateur de l’abonnement Azure où se trouve le cluster. Au format UUID/GUID. |
Vous pouvez aussi utiliser les étiquettes personnalisées que vous appliquez à vos clusters.
Propriétés
Les propriétés suivantes sont disponibles pour être utilisées dans le cadre des stratégies de placement.
Les propriétés du processeur et de la mémoire sont représentées en tant qu’unités de ressource Kubernetes.
Les propriétés de coût sont des nombres décimaux qui représentent un coût à l’heure en dollars US pour le calcul Azure utilisé pour les nœuds au sein du cluster. Le coût est basé sur la tarification publique d’Azure.
| Nom de la propriété | Description |
|---|---|
| kubernetes-fleet.io/node-count | Nœuds disponibles sur le cluster membre. |
| resources.kubernetes-fleet.io/total-cpu | Nombre total d’unités de ressource de processeur du cluster. |
| resources.kubernetes-fleet.io/allocatable-cpu | Unités de ressource de processeur allouables du cluster. |
| resources.kubernetes-fleet.io/available-cpu | Unités de ressource de processeur disponibles du cluster. |
| resources.kubernetes-fleet.io/total-memory | Nombre total d’unités de ressource de mémoire du cluster. |
| resources.kubernetes-fleet.io/allocatable-memory | Unités de ressource de mémoire allouables du cluster. |
| resources.kubernetes-fleet.io/available-memory | Unités de ressource de mémoire disponibles du cluster. |
| kubernetes.azure.com/per-cpu-core-cost | Coût d’un cœur par processeur du cluster. |
| kubernetes.azure.com/per-gb-memory-cost | Coût de la mémoire par Gio du cluster. |
Spécification des critères de correspondance des sélections
Quand vous utilisez des propriétés de cluster dans les critères d’une stratégie, vous spécifiez :
Nom : nom de la propriété, qui est une des propriétés listées dans les propriétés de cet article.
Opérateur : un opérateur utilisé pour exprimer la condition entre la contrainte/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,EqouNe, 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 spécifiées dans la condition. Le non-respect des conditions répertoriées dans requiredDuringSchedulingIgnoredDuringExecution exclut ce cluster membre du placement des ressources.
Remarque
Si un cluster membre ne possède pas la propriété exprimée dans la condition, elle échouera automatiquement.
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
spec:
resourceSelectors:
- ...
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
Quand preferredDuringSchedulingIgnoredDuringExecution est utilisé, 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 le classement sont calculées en fonction de la valeur spécifiée.
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
AscendingouDescending. Quand l’ordreAscendingest utilisé, les clusters membres avec une valeur observée plus faible sont privilégiés. Lorsque l’ordreDescendingest utilisé, les clusters membres avec une valeur observée plus élevée sont préférés.
Ordre décroissant
Pour l’ordre de tri Décroissant, la pondération proportionnelle est calculée en utilisant la formule :
((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight
Par exemple, supposons que vous souhaitez classer les clusters en fonction de la propriété de la capacité processeur disponible dans l’ordre décroissant et que vous disposez d’une flotte de trois clusters avec le processeur disponible suivant :
| Cluster | Capacité processeur disponible |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
Dans ce cas, le trieur calcule les pondérations suivantes :
| Cluster | Capacité processeur disponible | Calcul | Poids |
|---|---|---|---|
cluster-a |
100 | (100 - 10) / (100 - 10) | 100 % |
cluster-b |
20 | (20 - 10) / (100 - 10) | 11,11 % |
cluster-c |
10 | (10 - 10) / (100 - 10) | 0 % |
Ordre croissant
Pour l’ordre de tri Croissant, la pondération proportionnelle est calculée en utilisant la formule :
(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight
Par exemple, supposons que vous souhaitez classer les clusters en fonction de leur coût par cœur de processeur dans l’ordre croissant et que vous disposez d’une flotte de trois clusters avec les coûts de cœur de processeur suivants :
| Cluster | Coût de cœur par processeur |
|---|---|
cluster-a |
1 |
cluster-b |
0.2 |
cluster-c |
0.1 |
Dans ce cas, le trieur calcule les pondérations suivantes :
| Cluster | Coût de cœur par processeur | Calcul | Poids |
|---|---|---|---|
cluster-a |
1 | 1 - ((1 - 0,1) / (1 - 0,1)) | 0 % |
cluster-b |
0.2 | 1 - ((0,2 - 0,1) / (1 - 0,1)) | 88,89 % |
cluster-c |
0.1 | 1 - (0,1 - 0,1) / (1 - 0,1) | 100 % |
Utilisation des 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 exempleNoSchedule.operator: l’opérateur de la tolérance, tel queExistsouEqual.
Chaque tolérance est utilisée pour tolérer une ou plusieurs répulsions 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 les tolérances d’un objet ClusterResourcePlacement une fois qu’il a été créé.
Pour plus d’informations, consultez la documentation sur les tolérances de Fleet open source.
Configuration de la stratégie de déploiement
Fleet utilise une stratégie de mise à jour propagée pour contrôler le déploiement des mises à jour sur plusieurs clusters.
Dans l’exemple suivant, le planificateur de flotte déploie séquentiellement les mises à jour sur chaque cluster, 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 du déploiement ne se propage pas en cascade jusqu’aux ressources enfants : ainsi par exemple, elle ne vérifie pas que les pods créés par un déploiement sont prêts.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Pour plus d’informations, consultez la documentation sur la stratégie de déploiement de Fleet open source.
Déterminer l’é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. 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.
Vous pouvez afficher ces informations via la commande kubectl describe crp <name>.
kubectl describe crp 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
Déclencheurs de modification du 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
ClusterResourcePlacementpeuvent déclencher la suppression et la replanification d’une charge de travail.- Les opérations de scale-out (augmentant
numberOfClusterssans aucune autre modification) placent les charges de travail seulement sur de nouveaux clusters et n’affectent pas les placements existants.
- Les opérations de scale-out (augmentant
- Modifications de clusters, y compris ce qui suit :
- Un nouveau cluster devenant éligible peut déclencher un placement si le nouveau cluster est conforme à la stratégie de placement, par exemple une stratégie
PickAll. - Un cluster avec un placement est supprimé de la flotte. Selon la stratégie, le planificateur tente de placer toutes les charges de travail affectées sur les clusters restants sans affecter les placements existants.
- Un nouveau cluster devenant éligible peut déclencher un placement si le nouveau cluster est conforme à la stratégie de placement, par exemple une stratégie
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.
Étapes suivantes
Azure Kubernetes Service