Définir des stratégies de mise à jour réutilisables à l’aide d’Azure Kubernetes Fleet Manager

1. Dans le portail Azure, accédez à votre ressource Azure Kubernetes Fleet Manager.

2. Dans le menu du service, sous Paramètres, sélectionnez Clusters membres>Ajouter.

   

3. Sélectionnez le cluster que vous souhaitez ajouter, puis sélectionnez Suivant : Vérifier + ajouter.

4. Entrez le nom du groupe de mises à jour auquel vous souhaitez affecter le cluster, puis sélectionnez Ajouter.

   

Affectez un cluster membre à un groupe de mises à jour lors de l’ajout du cluster membre à la flotte à l’aide de la commande az fleet member create avec le paramètre --update-group défini sur le nom du groupe de mises à jour.

az fleet member create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name member1 \
    --member-cluster-id $CLUSTERID \
    --update-group group-1a

1. Dans le portail Azure, accédez à votre ressource Azure Kubernetes Fleet Manager.

2. Dans le menu du service, sous Paramètres, sélectionnez Clusters membres.

3. Sélectionnez les clusters que vous souhaitez affecter à un groupe de mises à jour, puis sélectionnez Affecter un groupe de mises à jour

   

4. Entrez le nom du groupe de mises à jour auquel vous souhaitez affecter le cluster, puis sélectionnez Affecter.

   

Affectez un membre de flotte existant à un groupe de mises à jour à l’aide de la commande az fleet member update avec l’indicateur --update-group défini sur le nom du groupe de mises à jour.

az fleet member update \
 --resource-group $GROUP \
 --fleet-name $FLEET \
 --name member1 \
 --update-group group-1

1. Dans le portail Azure, accédez à votre ressource Azure Kubernetes Fleet Manager.

2. Dans le menu du service, sous Paramètres, sélectionnez Mise à jour multi-cluster>Stratégies, puis Créer.

3. Entrez un nom pour la stratégie.

4. La première fois que vous affichez la page, un diagramme d’explication de stratégie de mise à jour s’affiche pour vous aider à visualiser la façon dont les stratégies fonctionnent.

   

5. Sélectionnez Créer une étape et entrez :

   • Nom de l'étape - nommez l'étape - il doit être unique parmi tous les noms d’étape de la stratégie.
   • (Facultatif) Approbations intermédiaires : sélectionnez cette option si vous souhaitez attendre une approbation avant que cette étape commence ou une fois terminée. Pour plus d’informations, consultez Ajouter des approbations pour mettre à jour des groupes et des phases.
   • (Facultatif) Suspendre après l’étape : sélectionnez cette option si vous souhaitez définir une pause avant de passer à l’étape suivante.
   • (Facultatif) Durée de pause : sélectionnez une durée prédéfinie ou entrez une valeur personnalisée en secondes.

   

6. Affectez un ou plusieurs groupes de mises à jour à l’étape, puis sélectionnez Créer.

   Remarque

   Le nombre maximal de groupes de mises à jour dans chaque phase de mise à jour est de 50.

   

Pour ce scénario, nous créons des phases et des groupes pour qu’ils correspondent aux détails utilisés pour le processus du portail Azure.

1. Créez un fichier JSON pour définir les phases et les groupes pour l’exécution de mises à jour. Les étapes s’exécutent de manière séquentielle dans l’ordre dans lequel elles apparaissent dans le fichier JSON. Les groupes s’exécutent en parallèle à chaque étape, de sorte que l’ordre n’est pas important. Le fichier d’exemple suivant (example-stages.json) définit une stratégie avec deux étapes et inclut des paramètres maxConcurrency et maxAllowedFailures facultatifs :

   {
       "stages": [
           {
               "name": "stage-1",
               "maxConcurrency": "7",
               "maxAllowedFailures": "2",
               "groups": [
                   {
                       "name": "group-1",
                       "maxConcurrency": "3",
                       "maxAllowedFailures": "1"
                   },
                   {
                       "name": "group-2",
                       "maxConcurrency": "50%",
                       "maxAllowedFailures": "25%"
                   }
               ],
               "afterStageWaitInSeconds": 300
           },
           {
               "name": "stage-2",
               "maxConcurrency": "100%",
               "maxAllowedFailures": "0",
               "groups": [
                   {
                       "name": "group-3",
                       "maxConcurrency": "2",
                       "maxAllowedFailures": "0"
                   }
               ]
           }
       ]
   }
   

   maxConcurrency

   Le maxConcurrency champ est facultatif et contrôle le nombre de clusters pouvant être mis à niveau simultanément à l’étape ou au niveau du groupe. Utilisez une plus grande valeur pour mettre à niveau les clusters plus rapidement sur votre flotte, ou une valeur plus petite pour un déploiement plus contrôlé qui limite le rayon d’explosion si des problèmes se produisent.

   Dans cet exemple, stage-1 définit maxConcurrency à "7", ce qui permet à un maximum de "7" clusters de cette étape à être mis à niveau simultanément. Dans stage-1, group-1 limite la concurrence aux "3" clusters, ce qui signifie que jusqu'à "3" dans ce groupe peuvent être mis à niveau en même temps. group-2 autorise la mise à "50%" niveau simultanée de ses clusters (par exemple, si le groupe contient 4 clusters, jusqu’à 2 peuvent être mis à niveau en même temps).

   Les valeurs peuvent être un entier fixe (par exemple, "3") ou un pourcentage (par exemple). "100%" S’il est omis, le système applique les valeurs par défaut. Pour plus d’informations sur la façon dont ces valeurs sont résolues et leurs limites supérieures, consultez Concurrence maximale (préversion).

   maxAllowedFailures

   Le champ maxAllowedFailures est facultatif et détermine le nombre d’échecs de mise à niveau des clusters membres tolérés avant que le groupe ou l’étape ne soit marqué comme ayant échoué. Par défaut (lorsqu’il n’est pas défini ou "0"), une seule défaillance arrête l’exécution de la mise à jour entière.

   Ce paramètre évalue uniquement le nombre d’échecs. Elle n’applique pas un taux de réussite minimal. Un groupe ou une étape peut donc se terminer Completed même si certains ou tous les membres ont échoué, tant que le seuil d’échec n’a pas été dépassé lorsque la flotte a pris ses décisions de planification.

   Dans cet exemple, stage-1 définit maxAllowedFailures sur "2", en tolérant jusqu’à deux défaillances de membres sur l’ensemble de l’étape. Dans stage-1, group-1 tolère l’échec "1" et group-2 tolère l’échec "25%" de ses membres (par exemple, si le groupe contient 4 clusters, jusqu’à 1 échec est toléré). stage-2 définit maxAllowedFailures sur "0", ce qui signifie que toute défaillance arrête immédiatement l’exécution et est souvent utile pour les phases de production.

   Pour la plupart des déploiements, préférez les valeurs basées sur des pourcentages, car elles s’étendent mieux sur différentes tailles de groupe. Évitez de définir la valeur sur le nombre total de membres, sauf si vous souhaitez intentionnellement obtenir, pour ce segment, un comportement équivalant en pratique à « ne jamais échouer ».

   Les valeurs peuvent être un entier fixe (par exemple, "3") ou un pourcentage (par exemple). "25%" Pour plus d’informations sur la façon dont ces valeurs sont résolues, consultez Nombre maximal d’échecs autorisés (préversion).

2. Créez une stratégie de mise à jour à l’aide de la commande az fleet updatestrategy create avec l’indicateur --stages défini sur le nom de votre fichier JSON.

   az fleet updatestrategy create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name $STRATEGY \
    --stages example-stages.json