Définition d'une stratégie de déploiement pour Azure Kubernetes Fleet Manager pour le placement des ressources

S’applique à : ✔️ Fleet Manager avec cluster hub

Pendant la durée de vie d’un placement de ressources (limité au cluster ClusterResourcePlacement ou limité à l’espace de noms ResourcePlacement), des modifications peuvent être apportées, ce qui peut entraîner l’un des scénarios suivants :

• Les nouvelles charges de travail doivent peut-être être placées sur tous les clusters sélectionnés
• Les charges de travail déjà placées sur un cluster sélectionné peuvent être mises à jour ou supprimées
• Certains clusters sélectionnés précédemment ne sont plus sélectionnés, et les charges de travail doivent être supprimées de ces clusters
• Certains clusters viennent d'être récemment créés, et les charges de travail doivent leur être ajoutées.

La plupart des scénarios peuvent entraîner des interruptions de service lorsque des charges de travail s’exécutant sur des clusters membres peuvent devenir temporairement indisponibles, car Fleet Manager distribue des ressources mises à jour. Les clusters qui ne sont plus sélectionnés perdent toutes les ressources placées, ce qui entraîne une perte de trafic. Si un trop grand nombre de nouveaux clusters sont sélectionnés et que Fleet Manager place des ressources simultanément, les clusters peuvent devenir surchargés. Le modèle d’interruption exacte peut varier en fonction des ressources placées.

Pour réduire l’interruption, les API de placement des ressources de Fleet Manager permettent aux utilisateurs de configurer une stratégie de déploiement, similaire au déploiement Kubernetes natif, afin de passer d’un changement à l’autre le plus facilement possible.

Dans cet article, nous abordons les options de stratégie de déploiement disponibles pour les deux ClusterResourcePlacement et ResourcePlacement.

Comportement par défaut sans stratégie explicite

Les deux ClusterResourcePlacement et ResourcePlacement ne vous obligent pas à définir une stratégie de déploiement. Si vous ne le spécifiez pas, le comportement par défaut consiste à utiliser une stratégie RollingUpdate avec un maxSurge de 25%, un maxUnavailable de 25%et un unavailablePeriodSeconds de 10 secondes.

Stratégie de mise à jour continue

Une stratégie de mise à jour continue explicite peut être utilisée en ajoutant une spécification strategy à un ClusterResourcePlacement ou ResourcePlacement comme indiqué. Vous pouvez définir des paramètres qui contrôlent la façon dont le placement des ressources Fleet Manager est perturbant.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-example
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-namespace
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 2
    affinity:
      clusterAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/location: westus
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: rp-example
  namespace: test-namespace
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-app
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 50%

Paramètres de configuration

Les stratégies de mise à jour propagée peuvent être configurées avec les paramètres suivants :

• maxUnavailable : considère qu’un cluster n’est pas disponible si les ressources ne sont pas correctement appliquées au cluster et s’assure qu’à tout moment, il existe au moins (N - maxUnavailable) le nombre de clusters disponibles. Vous pouvez définir un nombre absolu ou un pourcentage. La valeur par défaut est 25% et zéro ne doit pas être utilisée. La définition de ce paramètre sur une valeur inférieure entraîne moins d’interruption lors d’une modification, mais entraîne un déploiement plus lent.

• maxSurge : garantit qu’à tout moment, il existe au maximum (N + maxSurge) le nombre de clusters disponibles. Vous pouvez définir un nombre absolu ou un pourcentage. La valeur par défaut est 25% et zéro ne doit pas être utilisée. La définition de ce paramètre sur une valeur inférieure entraîne moins de placements de ressources sur d’autres clusters par Fleet Manager, ce qui ralentit le processus de déploiement.

• non disponiblePeriodSeconds vous permet de définir une période avant que les ressources ne soient évaluées comme « prêtes ». La valeur par défaut est 60 secondes. Fleet Manager considère uniquement les ressources nouvellement appliquées sur un cluster comme étant « prêtes » unavailablePeriodSeconds secondes après que les ressources soient correctement appliquées à ce cluster. La définition d’une valeur inférieure pour ce paramètre entraîne des déploiements plus rapides. Toutefois, nous recommandons vivement aux utilisateurs de définir une valeur qui permet d’effectuer les tâches d’initialisation/préparation.

Détermination du nombre de clusters

Le gestionnaire de flotte utilise le type de placement pour déterminer le nombre de clusters de référence (N) à utiliser lors du calcul de maxUnavailable ou de maxSurge :

• PickFixed : nombre de clusterNames spécifiés
• PickAll : nombre de clusters sélectionnés
• PickN : valeur numberOfClusters .

Si vous utilisez un pourcentage pour le paramètre, Fleet Manager le calcule également par rapport à N.

Stratégie de mise à jour intermédiaire

La stratégie de mise à jour intermédiaire fournit un contrôle précis sur les déploiements de ressources en organisant des clusters en étapes séquentielles avec des règles de progression configurables. Contrairement à la stratégie de mise à jour propagée, les mises à jour intermédiaires sont définies en externe à l’aide de ressources personnalisées distinctes qui fonctionnent ensemble pour orchestrer les déploiements.

Exemple de modèle de déploiement

Le diagramme suivant illustre un modèle de déploiement en trois étapes classique :

Ce modèle vous permet de :

• Déployer d’abord sur des clusters intermédiaires pour la validation initiale
• Attendre un temps spécifié avant de passer aux clusters de contrôle de validité
• Exiger une approbation manuelle avant le déploiement en production
• Contrôler l’ordre des mises à jour dans les étapes de contrôle de validité et de production

Quand utiliser des mises à jour intermédiaires

Les stratégies de mise à jour intermédiaire sont idéales lorsque vous avez besoin des éléments suivants :

• Déploiements basés sur l’environnement (dev → gestion intermédiaire → production)
• Délais de validation et portes d’approbation entre les étapes
• Classement déterministe des mises à jour de cluster en phases
• Modèles de déploiement réutilisables entre plusieurs placements de ressources

Pour les scénarios plus simples où les déploiements basés sur le pourcentage suffisent, envisagez plutôt d’utiliser la stratégie de mise à jour continue en ligne.

Fonctionnement des mises à jour intermédiaires

Les emplacements de cluster et d’étendue d’espace de noms offrent leurs propres types de ressources.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: my-app-placement
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by ClusterStagedUpdateRun, ClusterStagedUpdateStrategy.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateStrategy
metadata:
  name: three-stage-strategy
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
      maxConcurrency: 50%  # Update 50% of staging clusters at once
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
      maxConcurrency: 2  # Update 2 clusters concurrently
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order
      beforeStageTasks:
        - type: Approval
      maxConcurrency: 1  # Sequential updates (default)

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: my-app-placement
  namespace: my-app
spec:
  resourceSelectors:
    - group: "apps"
      kind: Deployment
      name: my-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: External  # Rollout is controlled by StagedUpdateRun, StagedUpdateStrategy.

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateStrategy
metadata:
  name: three-stage-strategy
  namespace: my-app
spec:
  stages:
    - name: staging
      labelSelector:
        matchLabels:
          environment: staging
      afterStageTasks:
        - type: TimedWait
          waitTime: 1h
      maxConcurrency: 50%  # Update 50% of staging clusters at once
    - name: canary
      labelSelector:
        matchLabels:
          environment: canary
      sortingLabelKey: name
      afterStageTasks:
        - type: Approval
      maxConcurrency: 2  # Update 2 clusters concurrently
    - name: production
      labelSelector:
        matchLabels:
          environment: production
      sortingLabelKey: order
      beforeStageTasks:
        - type: Approval
      maxConcurrency: 1  # Sequential updates (default)

Configuration de l’étape

Chaque étape de la stratégie peut spécifier :

• Sélecteur d’étiquette (labelSelector) pour déterminer quels clusters appartiennent à l’étape
• Ordre de tri (sortingLabelKey) pour les clusters au sein de l’étape à l’aide sortingLabelKey (facultatif : les clusters sont triés par ordre alphabétique si ce n’est pas spécifié)
• Exigence d’approbation des tâches avant phase (beforeStageTasks) (facultative - jusqu’à 1 tâche par étape)
• Tâches d’après phase (afterStageTasks) attente ou exigence d’approbation chronométrées (facultatif - jusqu’à 2 tâches par étape, maximum un de chaque type)
• Concurrence maximale (maxConcurrency) pour déterminer le nombre maximal de clusters à mettre à jour simultanément au sein de la phase (facultatif - peut être un nombre absolu compris entre 1 et le nombre de clusters de l’étape, ou un pourcentage compris entre 1 et 100, les résultats fractionnels sont arrondis avec un minimum de 1)

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterStagedUpdateRun
metadata:
  name: my-app-rollout
spec:
  placementName: my-app-placement # Required - ClusterResourcePlacement name the update run is applied to.
  # resourceSnapshotIndex: "0" # Optional - ClusterResourceSnapshot index of the selected resources to be updated across clusters. 
                               # Omit to use the latest snapshot, creating one if it doesn't already exist.
  stagedRolloutStrategyName: three-stage-strategy # Required - The name of the update strategy to use.
  state: Run # Optional - Controls the execution state of the update run.

apiVersion: placement.kubernetes-fleet.io/v1
kind: StagedUpdateRun
metadata:
  name: my-app-rollout
  namespace: my-app
spec:
  placementName: my-app-placement # Required - ResourcePlacement name the update run is applied to.
  # resourceSnapshotIndex: "0" # Optional - ResourceSnapshot index of the selected resources to be updated across clusters.
                               # Omit or leave empty to use the latest snapshot, creating one if it doesn't already exist.
  stagedRolloutStrategyName: three-stage-strategy # Required - The name of the update strategy to use.
  state: Run # Optional - Controls the execution state of the update run. 

Spécification du déploiement

Le champ resourceSnapshotIndex contrôle la version de l’instantané de ressource à déployer. Vous avez plusieurs options :

• Omettez le champ pour utiliser l’instantané le plus récent, en créant un nouveau s’il n’existe pas déjà (illustré dans l’exemple).
• Spécifiez un index d’instantané de ressource existant (par exemple "2") pour cibler explicitement cette version.
• Spécifiez un index d’instantané de ressource plus ancien (par exemple) "0"pour déployer ou restaurer vers une version précédente.

Pour plus d’informations sur les captures instantanées de ressources, consultez Présentation des instantanés pour Azure instantanés de ressources Kubernetes Fleet Manager.

Comprendre les états d’exécution des mises à jour

Les exécutions de mises à jour intermédiaires utilisent un state champ pour contrôler leur comportement d’exécution. Il est essentiel de comprendre ces états et leurs transitions pour gérer efficacement les déploiements.

États disponibles

• Initialiser : configure l’exécution de la mise à jour sans exécuter le déploiement. Utilisez cet état pour préparer et valider la configuration de l’exécution de la mise à jour avant de commencer le déploiement.

• Lancer : exécute le déploiement progressif. Si vous démarrez une nouvelle version, cet état initialise et exécute l’exécution de la mise à jour. Si l’exécution de la mise à jour est déjà initialisée, elle exécute uniquement le déploiement. Utilisez cet état pour démarrer ou reprendre les exécutions de mise à jour.

• Arrêt : arrête normalement l’exécution de la mise à jour. Cet état permet aux clusters en cours d’effectuer leurs mises à jour avant d’arrêter l’ensemble du processus de déploiement.

Règles de transition d’état

Les transitions d’état suivantes sont prises en charge :

• Initialiser → Exécuter : démarrer l’exécution après l’initialisation
• Exécuter → Arrêter : arrêter une exécution de mise à jour en cours d’exécution
• Arrêter → Exécuter : reprendre une exécution de mise à jour arrêtée

Une fois l’exécution de mise à jour terminée, l’exécution de la mise à jour ne peut pas être redémarrée.

Progression de l’étape

Les processus Fleet Manager s’effectuent de manière séquentielle :

1. Toutes les tâches configurées avant l’étape s’exécutent
2. Tous les clusters d’une phase reçoivent des mises à jour en fonction de leur ordre de tri
3. Une fois que tous les clusters d’une phase sont correctement mis à jour, toutes les tâches configurées après étape s’exécutent
4. L’étape suivante commence uniquement une fois toutes les tâches d’étape précédentes terminées

Demandes d’approbation

Pour la progression basée sur l’approbation, Fleet Manager crée une ClusterApprovalRequest ressource (pour les placements délimités par un cluster) ou ApprovalRequest (pour les placements délimités par l’espace de noms) qui doit être approuvée avant de passer à l’étape suivante.

Une étape peut avoir une tâche de type approbation avant étape et une tâche de type approbation après étape. Pour vous aider à différencier la demande d’approbation pour quelles tâches intermédiaires, le nom de la demande d’approbation contiendra -before- pour avant les tâches intermédiaires ou -after- après les tâches intermédiaires.

Exemples de noms de demande d’approbation :

• my-update-run-before-canary - Tâche d’approbation avant étape pour l’étape « contrôle de validité » de l’exécution de la mise à jour « my-update-run »
• my-update-run-after-staging - Tâche d’approbation après étape pour l’étape « intermédiaire » de l’exécution de la mise à jour « my-update-run »

Principales différences entre les stratégies de cluster et d’étendue d’espace de noms

Étapes suivantes

• Déployez des ressources étendues au cluster sur plusieurs clusters.
• Déployer des ressources délimitées à l’espace de noms sur plusieurs clusters
• Placement intelligent des ressources Kubernetes entre clusters en fonction des propriétés des clusters membres.
• Comment utiliser ClusterStagedUpdateRun pour orchestrer les déploiements intermédiaires.
• Contrôle de l’éviction et de l’interruption du placement des ressources de cluster.