Appliquer automatiquement les mises à jour de configuration de VM dans un MIG

Ce document explique comment appliquer automatiquement des mises à jour de configuration aux instances de machine virtuelle (VM) d'un groupe d'instances géré (MIG).

Compute Engine gère les VM d'un MIG en fonction des composants de configuration que vous utilisez : modèle d'instance, configuration facultative sur toutes les instances et configuration avec état facultative.

Chaque fois que vous mettez à jour la configuration des VM d'un MIG en modifiant ces composants, Compute Engine applique automatiquement votre configuration mise à jour aux nouvelles VM ajoutées au groupe.

Pour appliquer une nouvelle configuration aux VM existantes, vous pouvez configurer une mise à jour automatique, également appelée mise à jour proactive. Le MIG déploie automatiquement les mises à jour de configuration sur l'ensemble ou un sous-ensemble des VM du groupe. Vous pouvez contrôler la vitesse de déploiement, le niveau d'interruption de votre service et, via une mise à jour de Canary, le nombre d'instances mises à jour par le MIG avec la nouvelle configuration. Une fois que vous avez spécifié la nouvelle configuration, il n'est pas nécessaire de fournir des entrées supplémentaires, et la mise à jour se termine automatiquement.

Si vous souhaitez appliquer une nouvelle configuration de manière sélective uniquement à des instances nouvelles ou spécifiques d'un MIG, consultez la section Appliquer de manière sélective les mises à jour de configuration de VM dans un MIG. Pour vous aider à faire votre choix, consultez la section Méthodes pour appliquer une nouvelle configuration aux VM existantes.

Avant de commencer

  • Si vous mettez à jour un MIG avec état, consultez la section Appliquer, afficher et supprimer la configuration avec état dans les MIG.
  • Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud.

Limites

  • Si vous disposez d'un MIG avec état et que vous souhaitez utiliser des mises à jour progressives automatiques, vous devez conserver les noms des instances lors de leur remplacement ou, de manière équivalente, définir la méthode de remplacement sur RECREATE.

Lancer une mise à jour progressive de base

Une mise à jour progressive de base est appliquée petit à petit à l'ensemble des instances d'un MIG jusqu'à ce que toutes les instances aient été mises à jour avec la dernière configuration prévue. La mise à jour progressive ignore automatiquement les instances qui se trouvent déjà dans leur dernière configuration.

Vous pouvez contrôler divers aspects d'une mise à jour progressive, comme le nombre d'instances pouvant être mises hors ligne pour la mise à jour, le délai d'attente entre les mises à jour, l'impact du nouveau modèle sur toutes les instances ou seulement une partie d'entre elles, etc.

Voici quelques éléments à garder à l'esprit lors d'une mise à jour progressive :

  • Les mises à jour sont basées sur l'intention. Lorsque vous effectuez la requête de mise à jour initiale, l'API Compute Engine renvoie une réponse positive pour confirmer que la requête était valide, mais cela n'indique pas que la mise à jour a abouti. Vous devez vérifier l'état du groupe pour déterminer si votre mise à jour a été déployée avec succès.

  • L'API Instance Group Updater est une API déclarative. Elle attend une requête pour spécifier la configuration de post-mise à jour souhaitée du groupe d'instances géré, plutôt qu'un appel de fonction explicite.

  • Avec les mises à jour automatiques, vous pouvez utiliser jusqu'à deux versions de modèles d'instance dans votre groupe d'instances géré. Cela signifie que vous pouvez spécifier deux versions différentes de modèles d'instance pour votre groupe, ce qui est utile pour effectuer des mises à jour Canary.

Pour démarrer une mise à jour progressive de base dans laquelle la mise à jour est appliquée à toutes les instances du groupe, suivez les instructions ci-dessous.

Console

  1. Dans la console Google Cloud, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le MIG que vous souhaitez mettre à jour.

  3. Cliquez sur Mettre à jour les VM.

  4. Sous Nouveau modèle, cliquez sur la liste déroulante et sélectionnez le nouveau modèle que vous souhaitez utiliser pour effectuer la mise à jour. La taille de la cible est automatiquement définie sur 100 %, ce qui indique que toutes vos instances seront mises à jour.

  5. Sous Mettre à jour la configuration, développez le menu de sélection et sélectionnez Automatique comme Type de mise à jour. Conservez les valeurs par défaut des autres options.

  6. Cliquez sur Mettre à jour les VM pour lancer la mise à jour.

gcloud

Exécutez la commande rolling-action start-update.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=INSTANCE_TEMPLATE_NAME
    [--zone=ZONE | --region=REGION]

Remplacez l'élément suivant :

  • INSTANCE_GROUP_NAME : nom du MIG
  • INSTANCE_TEMPLATE_NAME : nouveau modèle d'instance
  • ZONE : pour les groupes d'instances gérés zonaux, indiquez la zone
  • REGION : pour les groupes d'instances gérés régionaux, indiquez la région

REST

Appelez la méthode patch sur une ressource MIG régionale ou zonale.

Par exemple, pour un groupe d'instances géré régional, la requête suivante indique la configuration minimale nécessaire pour mettre à jour automatiquement 100 % des instances vers le nouveau modèle d'instance.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

Après avoir effectué une requête, vous pouvez surveiller la mise à jour pour savoir quand la mise à jour est terminée.

Pour les configurations avancées, incluez d'autres options de mise à jour. Sans indication contraire de votre part, les options maxSurge et maxUnavailable sont définies par défaut sur la valeur 1 multipliée par le nombre de zones affectées. Cela signifie qu'une seule instance est mise hors ligne dans chaque zone affectée et que le MIG ne crée qu'une instance supplémentaire par zone pendant la mise à jour.

Configurer des options pour votre mise à jour

Pour des mises à jour plus complexes, vous pouvez configurer des options supplémentaires, comme décrit dans les sections suivantes.

Mettre à jour le type

Les groupes d'instances gérés sont compatibles avec deux types de mises à jour :

  • Mises à jour automatiques ou proactives
  • Mises à jour sélectives ou opportunistes

Si vous souhaitez appliquer automatiquement les mises à jour, définissez le type sur proactive.

Si une mise à jour automatique est potentiellement trop perturbatrice, vous pouvez également effectuer une mise à jour quand l'occasion se présente. Le MIG applique une mise à jour quand l'occasion se présente uniquement lorsque vous initiez manuellement la mise à jour sur des instances sélectionnées ou lorsque de nouvelles instances sont créées. Des instances peuvent être créées lorsque vous ou un autre service, tel qu'un autoscaler, redimensionne le MIG. Compute Engine n'initie pas activement les requêtes d'application de mises à jour quand l'occasion se présente sur des instances existantes.

Pour en savoir plus sur les mises à jour automatiques et sélectives, consultez la section Méthodes d'application d'une nouvelle configuration à des VM existantes.

Maximum surge

Utilisez l'option maxSurge pour configurer le nombre d'instances supplémentaires que le MIG peut créer par rapport à sa taille cible (targetSize) lors d'une mise à jour automatique. Par exemple, si vous définissez maxSurge sur 5, le MIG utilise le nouveau modèle d'instance pour créer jusqu'à cinq instances supplémentaires par rapport à votre taille cible. La définition d'une valeur maxSurge supérieure accélère votre mise à jour, au prix d'instances supplémentaires, facturées conformément à lagrille tarifaire de Compute Engine.

Vous pouvez spécifier soit un nombre fixe, soit un pourcentage si le groupe d'instances géré comporte 10 instances ou plus. Si vous définissez un pourcentage, le programme de mise à jour arrondit le nombre d'instances si nécessaire.

Si vous ne définissez pas de valeur maxSurge, la valeur par défaut est utilisée. Pour les MIG zonaux, la valeur par défaut de maxSurge est 1. Pour les MIG régionaux, la valeur par défaut est le nombre de zones associées au groupe, soit 3 par défaut.

maxSurge ne fonctionne que si vous avez suffisamment de quota ou de ressources pour accepter des ressources supplémentaires.

Si votre mise à jour ne nécessite pas le remplacement des VM, cette option est ignorée. Vous pouvez forcer le remplacement des VM lors d'une mise à jour en définissant l'option action minimale.

Nombre maximal d'instances indisponibles

Utilisez l'option maxUnavailable pour configurer le nombre d'instances indisponibles à tout moment au cours d'une mise à jour automatique. Par exemple, si vous définissez maxUnavailable sur 5, seules cinq instances seront mises hors ligne pour être mises à jour simultanément. Cette option permet de contrôler le niveau de perturbation de la mise à jour de votre service et le taux de déploiement de la mise à jour.

Ce nombre inclut également toute instance indisponible pour d'autres raisons. Par exemple, si le groupe est en cours de redimensionnement, les instances en cours de création peuvent être indisponibles. Ces instances sont comptabilisées dans la valeur maxUnavailable.

Vous pouvez spécifier un nombre fixe ou, si le groupe comporte 10 instances ou plus, sous forme de pourcentage. Si vous définissez un pourcentage, le programme de mise à jour arrondit le nombre d'instances si nécessaire.

Si vous ne souhaitez pas utiliser de machine indisponible lors d'une mise à jour, définissez la valeur maxUnavailable sur 0 et la valeur maxSurge sur une valeur supérieure à 0. Avec ces paramètres, Compute Engine supprime chaque ancienne machine uniquement après la création et l'exécution de la nouvelle machine de remplacement.

Si vous ne définissez pas de valeur maxUnavailable, la valeur par défaut est utilisée. Pour les MIG zonaux, la valeur par défaut est 1. Pour les MIG régionaux, la valeur par défaut est le nombre de zones associées au groupe, soit 3 par défaut.

Durée d'attente minimale

Utilisez l'option minReadySec pour spécifier le délai d'attente avant de considérer une instance nouvelle ou redémarrée comme mise à jour. Cette option permet de contrôler la vitesse à laquelle la mise à jour automatique est déployée. La minuterie démarre lorsque les deux conditions suivantes sont remplies :

Notez que pour que la vérification de l'état affiche le statut "sain", le programme de mise à jour attend les conditions suivantes :

  1. attend jusqu'à la durée spécifiée par la valeur autohealingPolicies.initialDelaySec du groupe d'instances géré pour que la vérification de l'état affiche la valeur HEALTHY.
  2. attend ensuite la durée spécifiée par minReadySec.

Si la vérification de l'état ne renvoie pas l'état HEALTHY dans le délai initialDelaySec, le programme de mise à jour déclare l'instance de VM comme étant non opérationnelle et arrête éventuellement la mise à jour. Pendant que l'instance de VM attend la vérification au cours du délai de initialDelaySec et de minReadySec, l'attribut currentAction de l'instance est VERIFYING. Toutefois, l'état de l'instance de VM sous-jacente reste RUNNING.

S'il n'y a pas de vérification d'état pour le groupe, le minuteur démarre lorsque l'état de l'instance est RUNNING.

La valeur maximale du champ minReadySec est de 3 600 secondes (1 heure).

Le schéma suivant montre comment les options de taille cible, de disponibilité maximale, de surutilisation maximale et de temps d'attente minimal affectent vos instances. Pour en savoir plus sur la taille de la cible, consultez la section Mises à jour Canary.

Comment les options des règles de mise à jour affectent votre requête

Action minimale

Utilisez l'option d'action minimale pour minimiser les perturbations autant que possible ou pour appliquer une action plus perturbatrice que nécessaire. Par exemple, Compute Engine n'a pas besoin de redémarrer une VM pour modifier ses métadonnées. Toutefois, si votre application ne lit les métadonnées d'instance que lorsqu'une VM est redémarrée, vous pouvez définir l'action minimale sur "redémarrage" afin de récupérer les modifications de métadonnées.

Si votre mise à jour nécessite une action plus perturbatrice que celle définie avec cette option, Compute Engine effectue l'action nécessaire à l'exécution de la mise à jour. Par exemple, si vous spécifiez un redémarrage comme action minimale, le programme de mise à jour tente de redémarrer les instances pour appliquer la mise à jour. Néanmoins, si vous modifiez l'OS, ce qui ne peut pas être effectué en redémarrant l'instance, le programme de mise à jour remplace les instances du groupe par de nouvelles instances de VM.

Pour en savoir plus, y compris sur les options valides, consultez la section Contrôler le niveau de perturbation lors d'une mise à jour progressive.

Action autorisée la plus perturbatrice

Utilisez l'option d'action autorisée la plus perturbatrice pour empêcher une mise à jour si elle nécessite plus de perturbations que ce que vous pouvez vous permettre. Si une mise à jour ne peut pas être effectuée en raison de ce paramètre, la mise à jour échoue et vos VM conservent leur configuration précédente.

Pour en savoir plus, consultez la section Contrôler le niveau de perturbation lors d'une mise à jour progressive.

Méthode de remplacement

Par défaut, lorsque vous mettez à jour un MIG de manière proactive, le groupe supprime vos instances de VM et les remplace par de nouvelles instances avec de nouveaux noms. Si vous devez conserver les noms de vos instances de VM, utilisez l'option replacementMethod.

La conservation des noms d'instance existants peut être utile si certains de vos systèmes ou applications reposent sur l'utilisation de noms d'instance spécifiques. Par exemple, certaines applications (comme Memcached) s'appuient sur des noms d'instance, car elles ne disposent pas d'un service de découverte. Par conséquent, chaque fois que le nom d'une instance de VM est modifié, l'application perd la connexion à cette même VM.

Pour conserver les noms d'instance, définissez la méthode de remplacement sur RECREATE au lieu de SUBSTITUTE si vous mettez à jour le MIG avec gcloud CLI ou l'API Compute Engine. Si vous mettez à jour le MIG à partir de la console Google Cloud, vous pouvez également cocher la case Conserver les noms d'instances lors du remplacement des instances.

Méthodes de remplacement des instances gérées

Les valeurs replacementMethod possibles sont :

  • SUBSTITUTE (par défaut) Permet d'accélérer le remplacement des instances lors des mises à jour, car les nouvelles VM sont créées avant l'arrêt des anciennes. Toutefois, les noms d'instance ne sont pas préservés, car les anciennes instances les utilisent toujours.

  • RECREATE : permet de conserver les noms d'instance lors d'une mise à jour. Compute Engine libère le nom d'une instance lorsque l'ancienne VM est à l'arrêt. Une instance portant ce nom est ensuite créée. Pour utiliser ce mode, vous devez définir maxSurge sur 0.

Pour en savoir plus, consultez la section Conserver les noms d'instance.

Autres exemples de mise à jour

Voici quelques exemples de ligne de commande avec des options de configuration communes.

Effectuer une mise à jour progressive de toutes les instances de VM, mais créer jusqu'à cinq nouvelles instances supérieures à la taille de la cible à la fois

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=5 \
    [--zone=ZONE | --region=REGION]

Effectuer une mise à jour progressive avec trois machines indisponibles au maximum et un délai d'attente minimum de trois minutes avant de définir une nouvelle instance comme disponible

gcloud beta compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

Effectuer une mise à jour progressive de toutes les instances de VM, mais créer jusqu'à 10 % de nouvelles instances supérieures à la taille de la cible à la fois.

Par exemple, si vous avez 1 000 instances et que vous exécutez la commande suivante, le programme de mise à jour crée jusqu'à 100 instances avant de commencer à supprimer les instances qui exécutent le modèle d'instance précédent.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=10% \
    [--zone=ZONE | --region=REGION]

Mises à jour Canary

Une mise à jour Canary est une mise à jour appliquée à un sous-ensemble d'instances du groupe. Elle vous permet de tester de nouvelles fonctionnalités ou mises à niveau sur un sous-ensemble aléatoire d'instances pour éviter de déployer une mise à jour potentiellement perturbatrice. Si une mise à jour ne se déroule pas correctement, il vous suffit d'effectuer un rollback du sous-ensemble d'instances, ce qui minimise les perturbations pour vos utilisateurs.

Une mise à jour Canary est identique à une mise à jour progressive standard, sauf que le nombre d'instances à mettre à jour est inférieur à la taille totale du groupe d'instances. Comme pour une mise à jour progressive standard, vous pouvez configurer des options supplémentaires pour contrôler le niveau de perturbation de votre service.

Démarrer une mise à jour en version Canary

Pour lancer une mise à jour Canary, spécifiez jusqu'à deux versions de modèle d'instance, généralement un nouveau modèle d'instance pour la version Canary et le modèle d'instance actuel pour les instances restantes. Par exemple, vous pouvez spécifier que 20 % de vos instances soient créées à partir de NEW_INSTANCE_TEMPLATE, tandis que les autres instances continuent de s'exécuter sur OLD_INSTANCE_TEMPLATE. Vous ne pouvez pas spécifier plus de deux modèles d'instance à la fois. Le NEW_INSTANCE_TEMPLATE peut être un modèle d'instance régional de la même région que celle de votre MIG ou un modèle d'instance global.

Vous devez toujours spécifier la taille de la cible (targetSize) pour la version Canary. Vous ne pouvez pas lancer une mise à jour Canary si vous omettez de définir la taille de la cible pour la version Canary. Par exemple, si vous avez spécifié que 10 % des instances doivent être utilisées pour la version Canary, les 90 % restants resteront intacts et utiliseront le modèle d'instance actuel.

Console

  1. Dans la console Google Cloud, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez mettre à jour.
  3. Cliquez sur Mettre à jour les VM.
  4. Cliquez sur Ajouter un second modèle et choisissez le nouveau modèle d'instance pour la mise à jour Canary.
  5. Sous Taille de la cible, entrez le pourcentage ou le nombre fixe d'instances que vous souhaitez utiliser pour analyser le nouveau modèle d'instance de la version Canary.
  6. Si vous le souhaitez, vous pouvez configurer d'autres options de mise à jour.
  7. Cliquez sur Mettre à jour les VM pour lancer la mise à jour.

gcloud

Utilisez la commande rolling-action start-update. Fournissez à la fois le modèle actuel et le nouveau modèle pour indiquer clairement le nombre d'instances devant utiliser chaque modèle :

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE_NAME \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

Remplacez l'élément suivant :

  • INSTANCE_GROUP_NAME : nom du groupe d'instances.
  • CURRENT_INSTANCE_TEMPLATE_NAME : modèle d'instance exécuté par le groupe d'instances.
  • NEW_TEMPLATE : nouveau modèle pour la mise à jour Canary.
  • SIZE : nombre ou pourcentage d'instances auxquelles vous souhaitez appliquer cette mise à jour. Vous devez appliquer la propriété target-size au modèle --canary-version. Vous ne pouvez définir un pourcentage que si le groupe d'instances contient 10 instances ou plus.
  • ZONE : pour les groupes d'instances gérés zonaux, indiquez la zone.
  • REGION : pour les groupes d'instances gérés régionaux, indiquez la région.

Par exemple, la commande suivante effectue une mise à jour Canary qui déploie example-template-B sur 10 % des instances du groupe :

gcloud compute instance-groups managed rolling-action start-update example-mig \
    --version=template=example-template-A \
    --canary-version=template=example-template-B,target-size=10%

REST

Appelez la méthode patch sur une ressource MIG régionale ou zonale. Dans le corps de la requête, incluez à la fois le modèle d'instance actuel et le nouveau modèle d'instance concerné par la mise à jour Canary. Exemple :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "targetSize": {
    "[percent|fixed]": NUMBER|PERCENTAGE # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME"
  }
 ]
}

Remplacez l'élément suivant :

  • NEW_TEMPLATE : nom du nouveau modèle que vous souhaitez utiliser pour la mise à jour Canary.
  • NUMBER|PERCENTAGE : nombre fixe ou pourcentage d'instances auquel vous souhaitez appliquer la mise à jour. Vous ne pouvez définir un pourcentage que si le groupe d'instances contient 10 instances ou plus. Sinon, indiquez un nombre fixe.
  • CURRENT_INSTANCE_TEMPLATE_NAME : nom du modèle d'instance actuel exécuté par le groupe.

Pour en savoir plus, consultez la section Configurer des options pour votre mise à jour.

Après avoir effectué une requête, vous pouvez surveiller la mise à jour pour savoir quand la mise à jour est terminée.

Déploiement d'une mise à jour Canary

Après avoir exécuté une mise à jour Canary, vous pouvez décider de la validation sur 100 % du groupe d'instances géré ou d'un rollback.

Console

  1. Dans la console Google Cloud, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez mettre à jour.
  3. Cliquez sur Mettre à jour les VM.
  4. Sous Nouveau modèle, mettez à jour la taille de la cible du modèle Canary et indiquez 100 % pour transférer le modèle à toutes vos instances. Vous pouvez également remplacer le modèle principal par le modèle Canary qui supprime le deuxième champ du modèle.
  5. Cliquez sur Mettre à jour les VM pour lancer la mise à jour.

gcloud

Si vous souhaitez valider la mise à jour Canary, effectuez la mise à jour en émettant une autre commande rolling-action start-update en définissant uniquement l'option version et en omettant la --canary-version.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    [--zone=ZONE | --region=REGION]

REST

Appelez la méthode patch sur une ressource MIG régionale ou zonale. Dans le corps de la requête, spécifiez le nouveau modèle d'instance en tant que version et omettez l'ancien modèle d'instance du corps de votre requête. Omettez la spécification de taille de la cible pour déployer la mise à jour sur 100 % des instances. Exemple :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE" # New instance template
   }
 ]
}

Surveiller les mises à jour

Une fois la mise à jour lancée, son déploiement sur toutes les instances concernées peut prendre un certain temps. Vous pouvez suivre la progression d'une mise à jour en vérifiant les éléments suivants :

État du groupe

Au niveau du groupe, Compute Engine insère un champ en lecture seule nommé status qui comprend les options versionTarget.isReached et isStable. Vous pouvez accéder à ces options à l'aide de gcloud CLI ou de REST. Vous pouvez également utiliser la console Google Cloud pour afficher le nombre actuel et le nombre prévu d'instances en cours de mise à jour.

Console

Vous pouvez surveiller la mise à jour progressive d'un groupe sur sa page d'informations.

  1. Dans Google Cloud Console, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré que vous souhaitez surveiller. La page de vue d'ensemble du groupe montre le modèle utilisé par chaque instance.
  3. Pour afficher les détails, cliquez sur l'onglet Détails.
  4. Sous Modèle d'instance, vous pouvez voir le nombre actuel et cible d'instances pour chaque modèle d'instance, ainsi que les paramètres de mise à jour.

gcloud

Exécutez la commande describe.

gcloud compute instance-groups managed describe INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Vous pouvez également utiliser la commande gcloud compute instance-groups managed wait-until avec l'option --version-target-reached pour attendre que l'option status.versionTarget.isReached soit définie sur true pour le groupe :

gcloud compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone=ZONE | --region=REGION]

REST

Appelez la méthode get sur une ressource MIG régionale ou zonale.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

Vérifier si un déploiement de mise à jour est terminé

Vérifiez si le déploiement d'une mise à jour est terminé en consultant la valeur du champ status.versionTarget.isReached du groupe d'instances géré :

  • Si le champ status.versionTarget.isReached est défini sur true, cela signifie que toutes les instances de VM sont créées ou en cours de création à l'aide de la version cible.

  • Si le champ status.versionTarget.isReached est défini sur false, cela signifie qu'au moins une VM n'utilise pas encore la version cible. Ou, dans le cas d'une mise à jour Canary, la valeur false indique que le nombre de VM utilisant une version cible ne correspond pas à la taille cible.

.

Vérifier si le groupe d'instances géré est stable

Vérifiez que toutes les instances d'un groupe d'instances géré sont en cours d'exécution et opérationnelles en consultant la valeur du champ status.isStable du groupe.

Si le champ status.isStable est défini sur false, cela signifie que les modifications sont actives, en attente, ou que le MIG est en cours de modification.

Si le champ status.isStable est défini sur true, on peut en déduire les éléments suivants :

  • Aucune des instances du groupe d'instances géré n'est en cours de modification, et le champ currentAction est défini sur NONE pour toutes les instances.
  • Aucune modification n'est en attente pour les instances du MIG.
  • Le MIG n'est pas en cours de modification.

N'oubliez pas que la stabilité d'un groupe d'instances géré dépend de nombreux facteurs, car un groupe d'instances géré peut être modifié de différentes façons. Exemple :

  • Vous pouvez demander le déploiement d'un nouveau modèle d'instance.
  • Vous pouvez demander à créer, supprimer, redimensionner ou mettre à jour des instances du groupe.
  • Un autoscaler peut demander le redimensionnement du groupe.
  • Une ressource d'autoréparation peut remplacer une ou plusieurs instances non opérationnelles dans le groupe.
  • Des instances d'un groupe d'instances géré régional peuvent être redistribuées.

Une fois toutes les actions terminées, le champ status.isStable est à nouveau défini sur true pour ce groupe d'instances géré.

Actions en cours sur les instances

Utilisez Google Cloud CLI ou REST pour afficher les détails des instances d'un groupe d'instances géré. Les détails incluent l'état de l'instance et les actions en cours effectuées par le groupe sur ses instances.

gcloud

Toutes les instances gérées

Pour vérifier l'état et les actions en cours de toutes les instances du groupe, utilisez la commande list-instances.

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

La commande renvoie une liste d'instances dans le groupe, avec leur état, les actions en cours et d'autres détails :

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING                 NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING                 NONE      my-old-template

La colonne HEALTH_STATE apparaît vide, sauf si vous avez configuré la vérification d'état.

Une instance gérée spécifique

Pour vérifier l'état et l'action en cours d'une instance spécifique du groupe, utilisez la commande describe-instance.

gcloud compute instance-groups managed describe-instance INSTANCE_GROUP_NAME \
    --instance INSTANCE_NAME \
    [--zone=ZONE | --region=REGION]

La commande renvoie des détails sur l'instance, y compris l'état, l'action actuelle et, pour les MIG avec état, l'état conservé :

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

REST

Appelez la méthode listManagedInstances sur une ressource MIG régionale ou zonale. Par exemple, pour afficher les détails des instances d'une ressource de MIG zonal, vous pouvez exécuter la requête suivante :

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

L'appel renvoie la liste des instances du groupe, y compris les paramètres instanceStatus et currentAction de chaque instance.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  }
 ]
}

Pour afficher la liste des valeurs valides du champ instanceStatus, consultez la section Cycle de vie des instances de VM.

Si une instance subit un certain type de modification, le groupe d'instances géré définit le champ currentAction de l'instance sur l'une des actions suivantes pour vous aider à suivre la progression de la modification. Dans le cas contraire, le champ currentAction est défini sur NONE.

Les valeurs possibles du champ currentAction sont les suivantes :

  • ABANDONING : l'instance est en cours de suppression du groupe d'instances géré.
  • CREATING : l'instance est en cours de création.
  • CREATING_WITHOUT_RETRIES : l'instance est en cours de création sans nouvelle tentative. Si l'instance n'est pas créée lors de la première tentative, le groupe d'instances géré n'essaie pas de remplacer à nouveau l'instance.
  • DELETING : l'instance est en cours de suppression.
  • RECREATING : l'instance est en cours de remplacement.
  • REFRESHING : l'instance est supprimée de ses pools cibles actuels et rajoutée dans la liste des pools cibles actuels (cette liste peut être identique ou différente des pools cibles existants).
  • RESTARTING : l'instance est en cours de redémarrage à l'aide des méthodes stop et start.
  • RESUMING : l'instance est en cours de reprise, suite à sa suspension.
  • STARTING : l'instance est en cours de démarrage, suite à son arrêt.
  • STOPPING : l'instance est en cours d'arrêt.
  • SUSPENDING : l'instance est en cours de suspension.
  • VERIFYING : l'instance a été créée et est en cours de vérification.
  • NONE : aucune action n'est effectuée sur l'instance.

Restaurer une mise à jour

Aucune commande explicite ne permet de restaurer une version antérieure. Toutefois, vous pouvez effectuer un rollback d'une mise à jour intégrale ou Canary à l'aide d'une nouvelle requête de mise à jour en incluant le modèle d'instance que vous souhaitez restaurer.

gcloud

Par exemple, la commande gcloud CLI suivante restaure une mise à jour aussi rapidement que possible. Remplacez OLD_INSTANCE_TEMPLATE par le nom du modèle d'instance à restaurer.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=OLD_INSTANCE_TEMPLATE_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

REST

Appelez la méthode patch sur une ressource MIG régionale ou zonale.

Dans le corps de la requête, spécifiez l'ancien modèle d'instance en tant que version :

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/OLD_INSTANCE_TEMPLATE_NAME" # Old instance template
    }
  ]
}

Pour un groupe d'instances géré régional comportant moins de 10 instances, vous devez utiliser une valeur fixe pour maxUnavailable, et définir cette valeur sur le nombre d'instances du groupe.

Le programme de mise à jour traite une requête de rollback comme une requête de mise à jour standard afin que vous puissiez spécifier des options de mise à jour supplémentaires.

Arrêter une mise à jour

Il n'y a pas de méthode ou de commande explicite pour arrêter une mise à jour. Vous pouvez modifier une mise à jour pour qu'elle passe de type proactive à opportuniste. Si le groupe d'instances géré n'est pas redimensionné par d'autres services tels que l'autoscaler, rendre la mise à jour opportuniste arrêtera effectivement la mise à jour.

Pour passer d'une mise à jour proactive à opportuniste en utilisant gcloud CLI, exécutez la commande suivante :

gcloud compute instance-groups managed rolling-action stop-proactive-update INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Pour arrêter complètement la mise à jour après l'avoir convertie de proactive à opportuniste, procédez comme suit :

  1. Envoyez une requête pour déterminer combien d'instances ont été mises à jour.

    gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
   [--zone=ZONE | --region=REGION]

    gcloud CLI renvoie une réponse incluant la liste des instances du groupe et leur état actuel :

    NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template

    Dans cet exemple, deux instances ont déjà été mises à jour.

  2. Ensuite, envoyez une requête pour effectuer une nouvelle mise à jour, mais transmettez le nombre d'instances qui ont déjà été mises à jour en tant que taille cible :

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
   --version template=OLD_INSTANCE_TEMPLATE_NAME \
   --canary-version template=NEW_INSTANCE_TEMPLATE_NAME,target-size=2 \
   [--zone=ZONE | --region=REGION]

    Pour le programme de mise à jour, cette mise à jour est terminée. Aucune autre instance n'est donc mise à jour, et la mise à jour s'arrête.

Contrôler la vitesse d'une mise à jour progressive

Par défaut, lorsque vous effectuez une requête de mise à jour, le service effectue la mise à jour aussi rapidement que possible. Si vous n'êtes pas sûr de vouloir appliquer une mise à jour complète ou si vous testez provisoirement vos modifications, vous pouvez contrôler la vitesse de la mise à jour à l'aide des méthodes suivantes :

  1. Lancez une mise à jour Canary plutôt qu'une mise à jour complète.
  2. Définissez une valeur minReadySec élevée. En paramétrant cette valeur, le service attend ce nombre de secondes avant de considérer l'instance comme étant correctement mise à jour et de traiter l'instance suivante.
  3. Activez la vérification de l'état pour que le service attende que votre application démarre et confirme qu'elle est opérationnelle avant de considérer l'instance comme étant correctement mise à jour et de traiter l'instance suivante.
  4. Définissez des valeurs maxUnavailable et maxSurgefaibles. Cette action permet de garantir la mise à jour d'un nombre minimal d'instances à la fois.
  5. Mise à jour sélective des instances dans un groupe d'instances géré au lieu d'utiliser une mise à jour automatique.

Vous pouvez également utiliser une combinaison de ces méthodes pour contrôler la vitesse de mise à jour.

Contrôler le niveau de perturbation lors d'une mise à jour progressive

Selon la nature de la mise à jour, l'état du cycle de vie d'une instance peut être perturbé. Par exemple, la modification du disque de démarrage d'une instance nécessite le remplacement de l'instance. Vous pouvez contrôler le niveau de perturbation pendant une mise à jour progressive en définissant les options suivantes :

  • Action minimale : utilisez cette option pour minimiser autant d'interruptions que possible ou appliquer une action plus perturbatrice que nécessaire.

    • Pour limiter autant les interruptions que possible, définissez l'action minimale sur REFRESH. Si votre mise à jour nécessite une action plus perturbatrice, Compute Engine effectue l'action nécessaire à l'exécution de la mise à jour.
    • Pour appliquer une action plus perturbatrice que nécessaire, définissez l'action minimale sur RESTART ou REPLACE. Par exemple, Compute Engine n'a pas besoin de redémarrer une VM pour modifier ses métadonnées. Toutefois, si votre application ne lit les métadonnées d'instance que lorsqu'une VM redémarre, vous pouvez définir l'action minimale sur RESTART afin de récupérer les modifications de métadonnées.

  • Action la plus perturbatrice autorisée : utilisez cette option pour empêcher une mise à jour si elle nécessite plus de perturbations que ce que vous pouvez vous permettre. Si votre mise à jour nécessite une action plus perturbatrice que celle définie à l'aide de cette option, la demande de mise à jour échoue. Par exemple, si vous définissez l'action la plus perturbatrice autorisée sur RESTART, la tentative de mise à jour de l'image de disque de démarrage échoue, car cette mise à jour nécessite un remplacement de l'instance, une action plus perturbatrice qu'un redémarrage.

Ces deux options acceptent les valeurs suivantes :

ValeurDescriptionQuelles propriétés de l'instance peuvent être mises à jour ?
REFRESHNe provoque pas l'arrêt de l'instanceDisques supplémentaires, métadonnées d'instance, libellés, tags
RESTARTArrête l'instance, puis la redémarre.Disques supplémentaires, métadonnées de l'instance, libellés, tags, type de machine
REPLACE(Par défaut.) Remplace l'instance en fonction de l'option de méthode de remplacement.Toutes les propriétés de l'instance stockées dans le modèle d'instance ou la configuration par instance

Remarque : L'action autorisée la plus perturbatrice ne peut pas entraîner moins de perturbations que l'action minimale.

Lorsque vous déployez automatiquement les mises à jour, les valeurs par défaut suivantes s'appliquent :

  • L'action minimale par défaut est REPLACE. Si vous souhaitez éviter toute perturbation inutile, définissez l'action minimale pour qu'elle soit moins perturbatrice.
  • L'action la plus perturbatrice autorisée par défaut est REPLACE. Si vous ne pouvez pas tolérer de telles perturbations, définissez l'action la plus perturbatrice autorisée pour qu'elle soit moins perturbatrice.

Vous pouvez modifier le comportement par défaut en utilisant l'API Compute Engine pour définir les champs updatePolicy.minimalAction et updatePolicy.mostDisruptiveAllowedAction dans votre ressource de MIG, par exemple en appelant la méthode regionInstanceGroupManagers.patch. Vous pouvez également sélectionner les actions autorisées à mettre à jour les VM lorsque vous mettez à jour votre MIG à partir de la console Google Cloud. Pour afficher les paramètres actuels, consultez la section Obtenir les propriétés d'un MIG.

Une mise à jour échoue si elle nécessite une action plus perturbatrice que celle autorisée. Dans ce cas, vous pouvez réessayer d'effectuer la mise à jour avec une action autorisée plus perturbatrice, ou vous pouvez mettre à jour l'instance de manière sélective. Compute Engine optimise au mieux la validation pour déterminer si les instances peuvent être mises à jour avec la limite de perturbation spécifiée. Toutefois, en raison de modifications simultanées dans le système, la situation peut changer après le démarrage de la mise à jour. Si une opération sur une instance particulière échoue, répertoriez les erreurs d'instance pour afficher l'erreur.

Exécuter un remplacement ou un redémarage progressif

Un redémarrage progressif s'arrête et redémarre toutes les instances, tandis qu'un remplacement progressif remplace les instances en fonction de l'option de méthode de remplacement. Un redémarrage ou un remplacement progressif ne modifie rien d'autre dans le groupe, modèle d'instance inclus.

Un redémarrage ou un remplacement progressif est souhaitable pour de nombreuses raisons. Par exemple, vous souhaiterez peut-être redémarrer ou remplacer de temps en temps vos instances de VM pour l'une des raisons suivantes :

  • Effacer des fuites de mémoire.
  • Redémarrer votre application pour qu'elle puisse s'exécuter à partir d'une nouvelle machine.
  • Forcer un remplacement périodique, que nous recommandons pour tester vos VM.
  • Mettre à jour l'image du système d'exploitation de votre VM ou réexécuter les scripts de démarrage pour mettre à jour votre logiciel.

Utilisez la console Google Cloud, Google Cloud CLI ou REST pour effectuer un redémarrage ou un remplacement.

Console

  1. Dans la console Google Cloud, accédez à la page Groupes d'instances.

    Accéder à la page "Groupes d'instances"

  2. Sélectionnez le groupe d'instances géré comportant les VM que vous souhaitez redémarrer ou remplacer.
  3. Cliquez sur Redémarrer/Remplacer les VM.
  4. Sous Opération, sélectionnez Redémarrer ou Remplacer.
  5. Pour démarrer l'opération, cliquez sur Redémarrer les VM ou Remplacer les VM.

gcloud

Exécutez la commande restart ou la commande replace.

La commande suivante remplace toutes les instances du groupe d'instances géré, une par une :

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

La commande suivante redémarre chaque instance, une à la fois :

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

Vous pouvez personnaliser davantage chacune de ces commandes avec les mêmes options disponibles pour les mises à jour (par exemple : maxSurge et maxUnavailable).

REST

Appelez la méthode patch sur une ressource MIG régionale ou zonale.

Dans le champ updatePolicy.minimalAction, spécifiez RESTART ou REPLACE. Dans le champ versions.instanceTemplate, spécifiez le modèle actuel.

Pour déclencher l'action, vous devez également mettre à jour le champ versions.name, par exemple en y ajoutant un horodatage. Vous pouvez ensuite répertorier les VM du MIG et inspecter le champ versions.name de chaque VM pour déterminer quelles VM ont été remplacées ou redémarrées.

Par exemple, pour un groupe d'instances géré zonal, la requête suivante indique la configuration minimale nécessaire pour redémarrer automatiquement toutes les instances.

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME",
   "name": "v2-1705499403"
  }
 ]
}

Autres exemples de remplacement/redémarrage

Exécuter un redémarrage progressif de toutes les VM, deux à la fois

Cette commande redémarre toutes les VM du groupe, deux par deux. Notez qu'aucun nouveau modèle d'instance n'est spécifié.

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

Effectuer un redémarrage progressif de toutes les VM aussi rapidement que possible

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Effectuer un remplacement progressif de toutes les VM aussi rapidement que possible

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Conservation des noms d'instance

Si vous souhaitez conserver les noms de vos instances de VM lors d'une mise à jour, définissez replacementMethod sur RECREATE. Vous devez également définir maxUnavailable sur une valeur supérieure à 0 et maxSurge sur 0. Si vous recréez des instances au lieu de les remplacer, la mise à jour est plus longue, mais les instances mises à jour conservent leur nom.

Si vous ne spécifiez pas de méthode de remplacement, la valeur actuelle updatePolicy.replacementMethod du MIG est utilisée. Si cette valeur n'est pas non plus définie, la valeur par défaut (substitute) est utilisée. Elle remplace les instances de VM par de nouvelles instances aux noms générés aléatoirement.

gcloud

Lors de l'exécution d'une commande rolling-action, incluez l'option --replacement-method=recreate.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --replacement-method=recreate \
    --version=template=NEW_TEMPLATE \
    --max-unavailable=5 \
    [--zone=ZONE | --region=REGION]

REST

Appelez la méthode patch sur une ressource MIG régionale ou zonale. Dans le corps de la requête, incluez le champ updatePolicy.replacementMethod :

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

Après avoir effectué une requête, vous pouvez surveiller la mise à jour pour savoir quand la mise à jour est terminée.

Mettre à jour un groupe d'instances géré régional

Un groupe d'instances géré régional contient des instances de VM réparties sur plusieurs zones au sein d'une région, par opposition à un groupe d'instances géré zonal, qui ne contient que des instances dans une même zone. Les groupes d'instances gérés régionaux vous permettent de répartir vos instances sur plusieurs zones pour améliorer la disponibilité de votre application et prendre en charge les cas extrêmes où une zone échoue ou un groupe entier d'instances cesse de répondre.

Effectuer une mise à jour dans un MIG régional revient à effectuer une mise à jour dans un MIG zonal, à quelques exceptions près décrites ci-dessous. Lorsque vous lancez une mise à jour dans un MIG régional, le programme de mise à jour met toujours à jour les instances de façon proportionnelle et uniforme dans chaque zone. Vous ne pouvez pas choisir quelles instances ou zones sont mises à jour en premier, ni choisir de mettre à jour les instances d'une seule zone.

Différences entre mise à jour d'un groupe d'instances géré régional et mise à jour d'un groupe d'instances géré zonal

Les groupes d'instances gérés régionaux possèdent les valeurs de mise à jour par défaut suivantes :

  • maxUnavailable=NUMBER_OF_ZONES
  • maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES est le nombre de zones associées au MIG régional. Par défaut, le nombre de zones d'un MIG régional est 3. Vous pouvez toutefois sélectionner un autre nombre.

Si vous utilisez des nombres fixes lorsque vous spécifiez une mise à jour, le nombre fixe doit être soit 0, soit supérieur ou égal au nombre de zones associées au groupe d'instances géré régional. Par exemple, si le groupe est réparti sur trois zones, vous ne pouvez pas définir maxSurge sur 1 ou 2, car le programme de mise à jour doit créer une instance supplémentaire dans chacune des trois zones.

Utiliser un nombre fixe ou un pourcentage dans les requêtes de mise à jour

Si vous spécifiez un nombre fixe dans vos requêtes de mise à jour, le nombre que vous spécifiez est divisé par le nombre de zones du MIG régional et réparti uniformément. Par exemple, si vous spécifiez maxSurge=10, le programme de mise à jour répartit ces 10 instances sur le nombre de zones de la région et crée de nouvelles instances en se basant sur ce nombre. Si le nombre d'instances ne peut pas être divisé uniformément entre les zones, le programme de mise à jour attribue de manière aléatoire les instances restantes dans l'une des zones. Ainsi, pour 10 instances réparties sur trois zones, deux des zones obtiennent trois instances et une autre en obtient quatre. La même logique est appliquée aux paramètres maxUnavailable et targetSize pour les mises à jour Canary.

Vous ne pouvez indiquer un pourcentage que si votre groupe d'instances géré contient au moins 10 instances de VM. Le traitement des pourcentages est légèrement différent selon la situation :

  • Si vous indiquez un pourcentage d'instances de VM pour une mise à jour Canary, le programme de mise à jour tentera de distribuer les instances régulièrement entre les zones. Le reste est arrondi par défaut ou par excès dans chaque zone, mais la différence totale n'est pas supérieure à une instance de VM par groupe. Par exemple, pour un groupe d'instances géré avec 10 instances et un pourcentage de taille de la cible de 25 %, la mise à jour est déployée sur deux à trois instances de VM.

  • Si vous spécifiez un pourcentage pour les options de mise à jour telles que maxSurge et maxUnavailable, les pourcentages sont arrondis indépendamment par zone.

Étape suivante