Aplicar automáticamente actualizaciones de configuración de máquinas virtuales en un MIG

En este documento se describe cómo aplicar automáticamente actualizaciones de configuración a las instancias de máquina virtual (VM) de un grupo de instancias gestionado (MIG).

Compute Engine mantiene las VMs de un MIG en función de los componentes de configuración que utilices: plantilla de instancia, configuración opcional de todas las instancias y configuración opcional con reconocimiento del estado.

Cada vez que actualizas la configuración de las VMs de un MIG cambiando esos componentes, Compute Engine aplica automáticamente la configuración actualizada a las VMs nuevas que se añaden al grupo.

Para aplicar una configuración actualizada a las máquinas virtuales, puedes configurar una actualización automática, también conocida como actualización proactiva. El MIG implementa automáticamente las actualizaciones de configuración en todas las VMs del grupo o en un subconjunto de ellas. Puedes controlar la velocidad del despliegue, el nivel de interrupción del servicio y, mediante una actualización Canary, el número de instancias que el MIG actualiza con la nueva configuración. Una vez que hayas especificado la nueva configuración, no tendrás que proporcionar más información y la actualización se completará automáticamente.

Si quieres aplicar una nueva configuración de forma selectiva solo a las instancias nuevas o a instancias específicas de un MIG, consulta Aplicar de forma selectiva actualizaciones de configuración de VM en un MIG. Para ayudarte a decidir, consulta Métodos para aplicar una nueva configuración a las VMs que ya tienes.

Antes de empezar

• Si vas a actualizar un MIG con reconocimiento del estado, consulta el artículo Aplicar, ver y quitar la configuración con reconocimiento del estado en grupos de instancias gestionados.
• Si aún no lo has hecho, configura la autenticación. La autenticación verifica tu identidad para acceder a Google Cloud servicios y APIs. Para ejecutar código o ejemplos desde un entorno de desarrollo local, puedes autenticarte en Compute Engine seleccionando una de las siguientes opciones:

  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. Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando:

     gcloud init

     Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

  2. Set a default region and zone.

  REST

  Para usar las muestras de la API REST de esta página en un entorno de desarrollo local, debes usar las credenciales que proporciones a la CLI de gcloud.

  Instala Google Cloud CLI. Después de la instalación, inicializa la CLI de Google Cloud ejecutando el siguiente comando:

  gcloud init

  Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

  Para obtener más información, consulta el artículo Autenticarse para usar REST de la documentación sobre autenticación de Google Cloud .

Limitaciones

• Si tienes un MIG con reconocimiento del estado y quieres usar actualizaciones continuas automatizadas, debes conservar los nombres de las instancias al sustituirlas o, lo que es lo mismo, definir el método de sustitución como RECREATE.

Iniciar una actualización continua básica

Una actualización continua básica es una actualización que se aplica gradualmente a todas las instancias de un MIG hasta que todas las instancias se hayan actualizado a la configuración más reciente. La actualización continua omite automáticamente las instancias que ya tienen la configuración más reciente.

Puedes controlar varios aspectos de una actualización continua, como el número de instancias que se pueden desconectar para la actualización, el tiempo que se debe esperar entre la actualización de las instancias, si la nueva plantilla afecta a todas las instancias o solo a una parte, etc.

A continuación, te indicamos algunos aspectos que debes tener en cuenta al hacer una actualización continua:

• Las actualizaciones se basan en la intención. Cuando envías la solicitud de actualización inicial, la API de Compute Engine devuelve una respuesta correcta para confirmar que la solicitud es válida, pero eso no indica que la actualización se haya realizado correctamente. Debe comprobar el estado del grupo para determinar si la actualización se ha implementado correctamente.

• La API Instance Group Updater es una API declarativa. La API espera que una solicitud especifique la configuración posterior a la actualización deseada del MIG, en lugar de una llamada de función explícita.

• Las actualizaciones automatizadas admiten hasta dos versiones de plantilla de instancia en tu MIG. Esto significa que puedes especificar dos versiones diferentes de la plantilla de instancia para tu grupo, lo que resulta útil para realizar actualizaciones canary.

Para iniciar una actualización continua básica en la que la actualización se aplique a todas las instancias del grupo, selecciona una de las siguientes opciones:

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

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

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

Después de enviar una solicitud, puedes monitorizar la actualización para saber cuándo ha terminado.

Para configuraciones avanzadas, incluye otras opciones de actualización. Si no se especifica lo contrario, las opciones maxSurge y maxUnavailable se multiplican de forma predeterminada por 1 y por el número de zonas afectadas. Esto significa que solo se desconecta una instancia en cada zona afectada y que la MIG crea solo una instancia adicional por zona durante la actualización.

Configurar las opciones de la actualización

Para las actualizaciones más complejas, puedes configurar opciones adicionales, como se describe en las siguientes secciones.

Actualizar tipo

Los grupos de instancias gestionadas admiten dos tipos de actualizaciones:

• Actualizaciones automáticas o proactivas
• Actualizaciones selectivas u oportunistas

Si quieres aplicar las actualizaciones automáticamente, define el tipo como proactive.

Si una actualización automática puede ser demasiado disruptiva, puedes optar por realizar una actualización oportunista. El MIG aplica una actualización oportunista solo cuando inicias manualmente la actualización en las instancias seleccionadas o cuando se crean nuevas instancias. Se pueden crear instancias cuando tú u otro servicio, como un escalador automático, cambia el tamaño del MIG. Compute Engine no inicia activamente solicitudes para aplicar actualizaciones oportunistas en instancias.

Para obtener más información sobre las actualizaciones automáticas y selectivas, consulta Métodos para aplicar una nueva configuración a máquinas virtuales ya creadas.

Número máximo de pods de compensación

Usa la opción maxSurge para configurar cuántas instancias nuevas puede crear el MIG por encima de su targetSize durante una actualización automática. Por ejemplo, si asignas el valor 5 a maxSurge, el MIG usa la nueva plantilla de instancia para crear hasta 5 instancias por encima del tamaño objetivo. Si asignas un valor de maxSurge más alto, se acelerará la actualización, pero se usarán más instancias, que se facturarán según la hoja de precios de Compute Engine.

Puedes especificar un número fijo o, si el grupo tiene 10 o más instancias, un porcentaje. Si define un porcentaje, Updater redondea al alza el número de instancias si es necesario.

Si no defines el valor maxSurge, se usará el valor predeterminado. En el caso de los MIGs zonales, el valor predeterminado de maxSurge es 1. En el caso de los MIGs regionales, el valor predeterminado es el número de zonas asociadas al grupo, que es 3 de forma predeterminada.

maxSurge solo funciona si tienes suficiente cuota o recursos para admitir los recursos adicionales.

Si la actualización no requiere que se sustituyan las máquinas virtuales, esta opción se ignora. Puedes forzar la sustitución de las VMs durante una actualización configurando la opción Acción mínima.

Número máximo de pods no disponibles

Usa la opción maxUnavailable para configurar cuántas instancias no están disponibles en cualquier momento durante una actualización automática. Por ejemplo, si asignas el valor 5 a maxUnavailable, solo se desconectarán 5 instancias a la vez para actualizarse. Usa esta opción para controlar el nivel de interrupción de la actualización en tu servicio y la velocidad a la que se implementa.

Este número también incluye las instancias que no están disponibles por otros motivos. Por ejemplo, si el grupo se está cambiando de tamaño, es posible que las instancias que se estén creando no estén disponibles. Estas instancias se tienen en cuenta en el número maxUnavailable.

Puede especificar un número fijo o, si el grupo tiene 10 instancias o más, un porcentaje. Si defines un porcentaje, el actualizador redondea hacia abajo el número de instancias, si es necesario.

Si no quieres que haya ninguna máquina no disponible durante una actualización, asigna el valor 0 al atributo maxUnavailable y un valor superior a 0 al atributo maxSurge. Con estos ajustes, Compute Engine elimina cada máquina antigua solo después de que se haya creado y esté en ejecución la nueva máquina de sustitución.

Si no defines el valor maxUnavailable, se usará el valor predeterminado. En el caso de los MIGs zonales, el valor predeterminado es 1. En los MIGs regionales, el valor predeterminado es el número de zonas asociadas al grupo, que es 3.

Tiempo de espera mínimo

Usa la opción minReadySec para especificar el tiempo que debe transcurrir antes de que se considere que una instancia nueva o reiniciada se ha actualizado. Usa esta opción para controlar la velocidad a la que se implementa la actualización automática. El temporizador se inicia cuando se cumplen las dos condiciones siguientes:

• El estado de la instancia es RUNNING.
• Si la comprobación del estado está habilitada, cuando la comprobación del estado devuelve HEALTHY.

Ten en cuenta que, para que la comprobación de estado devuelva un estado correcto, el actualizador espera a que se cumplan las siguientes condiciones:

1. Espera hasta el periodo de tiempo especificado por el valor autohealingPolicies.initialDelaySec del MIG para que la comprobación de estado devuelva HEALTHY.
2. Después, espera el periodo de tiempo especificado por minReadySec.

Si la comprobación del estado no devuelve HEALTHY en un plazo de initialDelaySec, el actualizador declara que la instancia de VM no está en buen estado y puede que detenga la actualización. Mientras la instancia de VM espera la verificación durante los periodos initialDelaySec y minReadySec, el currentAction de la instancia es VERIFYING. Sin embargo, el estado de la instancia de VM subyacente sigue siendo RUNNING.

Si el grupo no tiene comprobaciones del estado, el temporizador se inicia cuando el estado de la instancia es RUNNING.

El valor máximo del campo minReadySec es de 3600 segundos (1 hora).

En el siguiente diagrama se muestra cómo afectan a tus instancias las opciones de tamaño objetivo, máximo no disponible, máximo de aumento y tiempo de espera mínimo. Para obtener más información sobre el tamaño objetivo, consulta Actualizaciones canary.

Acción mínima

Usa la opción de acción mínima para minimizar las interrupciones lo máximo posible o para aplicar una acción más disruptiva de lo estrictamente necesario. Por ejemplo, Compute Engine no necesita reiniciar una VM para cambiar sus metadatos. Sin embargo, si tu aplicación solo lee los metadatos de la instancia cuando se reinicia una VM, puedes definir la acción mínima para que se reinicie y así recoger los cambios en los metadatos.

Si la actualización requiere una acción más disruptiva que la que has definido con esta marca, Compute Engine realizará la acción necesaria para ejecutar la actualización. Por ejemplo, si especificas que el reinicio es la acción mínima, Updater intentará reiniciar las instancias para aplicar la actualización. Sin embargo, si cambias el SO, lo que no se puede hacer reiniciando la instancia, la herramienta de actualización sustituye las instancias del grupo por nuevas instancias de VM.

Para obtener más información, incluidas las opciones válidas, consulta Controlar el nivel de interrupción durante una actualización gradual.

Acción permitida más disruptiva

Usa la opción de acción permitida más disruptiva para evitar una actualización si requiere más interrupciones de las que puedes permitirte. Si no se puede completar una actualización debido a este ajuste, la actualización fallará y tus VMs mantendrán su configuración anterior.

Para obtener más información, consulta Controlar el nivel de interrupción durante una actualización gradual.

Método de sustitución

De forma predeterminada, cuando actualizas un MIG de forma proactiva, el grupo elimina tus instancias de VM y las sustituye por instancias nuevas con nombres nuevos. Si necesitas conservar los nombres de tus instancias de VM, usa la opción replacementMethod.

Conservar los nombres de las instancias puede ser útil si tienes aplicaciones o sistemas que dependen de nombres de instancia específicos. Por ejemplo, algunas aplicaciones, como Memcached, dependen de los nombres de las instancias porque no tienen un servicio de descubrimiento. Por lo tanto, cada vez que cambia el nombre de una instancia, la aplicación pierde la conexión con esa VM específica.

Para conservar los nombres de las instancias, define el método de sustitución como RECREATE en lugar de SUBSTITUTE si actualizas el MIG con la CLI de gcloud o la API de Compute Engine. Si actualizas el MIG desde la Google Cloud consola, selecciona la casilla Conservar los nombres al sustituir las VMs.

Los valores replacementMethod válidos son los siguientes:

• SUBSTITUTE (predeterminado). Sustituye las instancias de VM más rápido durante las actualizaciones, ya que las nuevas VMs se crean antes de que se apaguen las antiguas. Sin embargo, los nombres de las instancias no se conservan porque las instancias antiguas siguen usando esos nombres.

• RECREATE. Conserva los nombres de las instancias durante una actualización. Compute Engine libera el nombre de la instancia cuando se apaga la VM antigua. A continuación, Compute Engine crea una instancia con el mismo nombre. Para usar este modo, debes definir maxSurge como 0.

Para obtener más información, consulta Conservar los nombres de las instancias.

Otros ejemplos de actualizaciones

A continuación, se muestran algunos ejemplos de líneas de comandos con opciones de configuración habituales.

Realiza una actualización gradual de todas las instancias de máquina virtual, pero crea hasta 5 instancias nuevas a la vez por encima del tamaño objetivo

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

Realiza una actualización continua con un máximo de 3 máquinas no disponibles y un tiempo de espera mínimo de 3 minutos antes de marcar una nueva instancia como 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]

Realiza una actualización gradual de todas las instancias de VM, pero crea hasta un 10% de instancias nuevas por encima del tamaño objetivo a la vez

Por ejemplo, si tienes 1000 instancias y ejecutas el siguiente comando, Updater crea hasta 100 instancias antes de empezar a eliminar las instancias que ejecutan la plantilla de instancia anterior.

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

Actualizaciones de Canary

Una actualización canary es una actualización que se aplica a un subconjunto de instancias del grupo. Con una actualización canary, puedes probar nuevas funciones o actualizaciones en un subconjunto aleatorio de instancias, en lugar de implementar una actualización que pueda causar interrupciones en todas tus instancias. Si una actualización no va bien, solo tienes que revertir el subconjunto de instancias, lo que minimiza las interrupciones para tus usuarios.

Una actualización canary es igual que una actualización continua estándar, excepto que el número de instancias que se deben actualizar es inferior al tamaño total del grupo de instancias. Al igual que en una actualización continua estándar, puedes configurar opciones adicionales para controlar el nivel de interrupción del servicio.

Iniciar una actualización canary

Para iniciar una actualización canary, especifica hasta dos versiones de plantilla de instancia. Normalmente, se trata de una plantilla de instancia nueva para la versión canary y la plantilla de instancia actual para el resto de las instancias. Por ejemplo, puedes especificar que el 20% de tus instancias se creen en función de NEW_INSTANCE_TEMPLATE mientras que el resto de las instancias sigan ejecutándose en OLD_INSTANCE_TEMPLATE. No puedes especificar más de dos plantillas de instancia a la vez. La NEW_INSTANCE_TEMPLATE puede ser una plantilla de instancia regional de la misma región que la de tu MIG o una plantilla de instancia global.

Siempre debe especificar un tamaño de destino (targetSize) para la versión canary. No puedes iniciar una actualización canary si omites el tamaño de destino de la versión canary. Por ejemplo, si has especificado que se debe usar el 10% de las instancias para las pruebas canary, el 90% restante no se modificará y usará la plantilla de instancia actual.

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

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%

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"
  }
 ]
}

Para ver más opciones, consulta Configurar opciones para la actualización.

Después de enviar una solicitud, puedes monitorizar la actualización para saber cuándo se ha completado.

Lanzar una actualización canary

Después de ejecutar una actualización canary, puedes decidir si quieres aplicar la actualización al 100% del MIG o revertirla.

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

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
   }
 ]
}

Monitorizar las actualizaciones

Después de iniciar una actualización, la nueva configuración puede tardar un tiempo en implementarse en todas las instancias afectadas. Para monitorizar el progreso de una actualización, comprueba lo siguiente:

• Para comprobar si todas las máquinas virtuales han alcanzado la versión de plantilla de destino, consulta el estado del grupo.
• Para comprobar que las máquinas virtuales específicas han alcanzado la versión de plantilla de destino, consulta las acciones actuales en las instancias.
• En el caso de los MIGs con estado, consulta también Verificar si se han aplicado las configuraciones por instancia.

Estado del grupo

A nivel de grupo, Compute Engine rellena un campo de solo lectura llamado status que contiene una versionTarget.isReachedmarca y una isStablemarca. Puedes usar la CLI de gcloud o REST para acceder a estas marcas. También puedes usar la Google Cloud consola para ver el número actual y previsto de instancias que se están actualizando.

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

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

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

Verificar si se ha completado el lanzamiento de una actualización

Para comprobar si se ha completado el lanzamiento de una actualización, consulta el valor del campo status.versionTarget.isReached de MIG:

• status.versionTarget.isReached indica que todas las instancias de VM se han creado o se están creando con la versión de destino.true

• status.versionTarget.isReached definido como false indica que al menos una VM aún no usa la versión de destino. En el caso de una actualización canary, false indica que el número de VMs que usan una versión de destino no coincide con su tamaño de destino.

Comprobar si un grupo de instancias gestionado es estable

status.isStable definido como false indica que los cambios están activos, pendientes o que el propio MIG se está modificando.

Si status.isStable se define como true, significa lo siguiente:

• Ninguna de las instancias de MIG está experimentando ningún tipo de cambio y el currentAction de todas las instancias es NONE.
• No hay cambios pendientes en las instancias del MIG.
• El MIG en sí no se modifica.

Recuerda que la estabilidad de un MIG depende de muchos factores, ya que se puede modificar de muchas formas. Por ejemplo:

• Envías una solicitud para implementar una nueva plantilla de instancia.
• Envías una solicitud para crear, eliminar, cambiar el tamaño o actualizar instancias del MIG.
• Una herramienta de ajuste automático de escala solicita cambiar el tamaño del MIG.
• Un recurso de reparación automática está sustituyendo una o varias instancias incorrectas del MIG.
• En un MIG regional, algunas de las instancias se están redistribuyendo.

En cuanto se hayan completado todas las acciones, status.isStable volverá a ser true en ese MIG.

Acciones actuales en las instancias

Usa Google Cloud CLI o REST para ver los detalles de las instancias de un grupo de instancias gestionadas. Los detalles incluyen el estado de la instancia y las acciones actuales que el grupo está realizando en sus instancias.

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

NAME: vm-instances-9pk4
ZONE: us-central1-f
STATUS:
HEALTH_STATE:
ACTION: CREATING
INSTANCE_TEMPLATE: my-new-template
VERSION_NAME:
LAST_ERROR:

NAME: vm-instances-h2r1
ZONE: us-central1-f
STATUS: STOPPING
HEALTH_STATE:
ACTION: DELETING
INSTANCE_TEMPLATE: my-old-template
VERSION_NAME:
LAST_ERROR:

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

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

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

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

Para ver una lista de los valores de campo instanceStatus válidos, consulta Ciclo de vida de las instancias de máquina virtual.

Si una instancia está experimentando algún tipo de cambio, el grupo de instancias gestionado asigna al campo currentAction de la instancia una de las siguientes acciones para ayudarte a monitorizar el progreso del cambio. De lo contrario, el campo currentAction se asigna a NONE.

Los valores posibles de currentAction son:

• ABANDONING. La instancia se está quitando del MIG.
• CREATING. Se está creando la instancia.
• CREATING_WITHOUT_RETRIES. La instancia se crea sin reintentos. Si no se crea en el primer intento, el MIG no intenta sustituirla de nuevo.
• DELETING. La instancia se está eliminando.
• RECREATING. Se está sustituyendo la instancia.
• REFRESHING. La instancia se elimina de sus grupos de destino actuales y se vuelve a añadir a la lista de grupos de destino actuales (esta lista puede ser igual o diferente de los grupos de destino actuales).
• RESTARTING. La instancia se está reiniciando mediante los métodos stop y start.
• RESUMING. La instancia se está reanudando tras haberse suspendido.
• STARTING. La instancia se está iniciando después de haberse detenido.
• STOPPING. Se está deteniendo la instancia.
• SUSPENDING. La instancia se está suspendiendo.
• VERIFYING. Se ha creado la instancia y se está verificando.
• NONE. No se está realizando ninguna acción en la instancia.

Restaurar una actualización

No hay ningún comando explícito para revertir una actualización a una versión anterior, pero, si decides revertir una actualización (ya sea una actualización totalmente confirmada o una actualización canary), puedes hacerlo enviando una nueva solicitud de actualización e introduciendo la plantilla de instancia a la que quieras volver.

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

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" # Old instance template
    }
  ]
}

Updater trata una solicitud de reversión del mismo modo que una solicitud de actualización normal, por lo que puedes especificar opciones de actualización adicionales.

Detener una actualización

No hay ningún método ni comando explícito para detener una actualización. Puedes cambiar una actualización de proactiva a oportunista. Si otros servicios, como el escalador automático, no cambian el tamaño del grupo, el cambio a oportunista detiene la actualización.

Para cambiar una actualización de proactiva a oportunista mediante la CLI de gcloud, ejecuta el siguiente comando:

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

Para detener la actualización por completo después de convertirla de proactiva a oportunista, sigue estos pasos:

1. Haz una solicitud para determinar cuántas instancias se han actualizado:

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

   La CLI de gcloud devuelve una respuesta que incluye una lista de instancias del grupo y sus estados actuales:

   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
   

   En este ejemplo, ya se han actualizado dos instancias.

2. A continuación, haz una solicitud para llevar a cabo una nueva actualización, pero indica el número de instancias que ya se han actualizado como tamaño de destino:

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

   Para Updater, esta actualización parece completada, por lo que no se actualizan otras instancias, lo que detiene la actualización.

Controlar la velocidad de una actualización continua

De forma predeterminada, cuando envías una solicitud de actualización, Updater realiza la actualización lo más rápido posible. Si no tienes claro si quieres aplicar una actualización por completo o estás probando los cambios de forma provisional, puedes controlar la velocidad de la actualización con los siguientes métodos.

1. Inicia una actualización canary en lugar de una actualización completa.
2. Asigna un valor minReadySec grande. Si se define este valor, el actualizador esperará este número de segundos antes de considerar que la instancia se ha actualizado correctamente y de pasar a la siguiente instancia.
3. Habilita la comprobación del estado para que Updater espere a que se inicie tu aplicación y envíe una señal de estado correcto antes de considerar que la instancia se ha actualizado correctamente y pasar a la siguiente instancia.
4. Define valores bajos para maxUnavailable y maxSurge. De esta forma, solo se actualiza un número mínimo de instancias a la vez.
5. Actualizar instancias de un MIG de forma selectiva en lugar de usar una actualización automática.

También puedes usar una combinación de estos métodos para controlar la frecuencia de tus actualizaciones.

Controlar el nivel de interrupción durante una actualización continua

En función de la naturaleza de una actualización, puede interrumpir el estado del ciclo de vida de una instancia. Por ejemplo, si quieres cambiar el disco de arranque de una instancia, tendrás que sustituirla. Puedes controlar el nivel de interrupción durante una actualización continua configurando las siguientes opciones:

• Acción mínima: usa esta opción para minimizar las interrupciones lo máximo posible o para aplicar una acción más disruptiva de lo necesario.

  • Para limitar las interrupciones al máximo, define la acción mínima como REFRESH. Si la actualización requiere una acción más disruptiva, Compute Engine realizará la acción necesaria para ejecutarla.
  • Para aplicar una medida más disruptiva de lo estrictamente necesario, define la acción mínima como RESTART o REPLACE. Por ejemplo, Compute Engine no necesita reiniciar una VM para cambiar sus metadatos. Sin embargo, si tu aplicación lee los metadatos de la instancia solo cuando se reinicia una VM, puedes definir la acción mínima como RESTART para recoger los cambios en los metadatos.

• Acción permitida más disruptiva: usa esta opción para evitar una actualización si requiere más interrupciones de las que puedes permitirte. Si tu actualización requiere una acción más disruptiva que la que has definido con esta marca, la solicitud de actualización fallará. Por ejemplo, si asignas el valor RESTART a la acción permitida más disruptiva, no se podrá actualizar la imagen del disco de arranque porque esa actualización requiere sustituir la instancia, una acción más disruptiva que un reinicio.

Ambas opciones aceptan los siguientes valores:

La acción permitida más disruptiva no puede ser menos disruptiva que la acción mínima.

Cuando lanzas actualizaciones automáticamente, se aplican los siguientes valores predeterminados:

• La acción mínima predeterminada es REPLACE. Si quieres evitar interrupciones innecesarias, elige la acción mínima para que no sea tan disruptiva.
• La acción más disruptiva permitida de forma predeterminada es REPLACE. Si no puedes tolerar estas interrupciones, elige una acción permitida que sea menos disruptiva.

Puedes cambiar el comportamiento predeterminado mediante la API Compute Engine para definir los campos updatePolicy.minimalAction y updatePolicy.mostDisruptiveAllowedAction en tu recurso MIG. Por ejemplo, puedes llamar al método regionInstanceGroupManagers.patch. También puedes seleccionar las acciones permitidas para actualizar las VMs cuando actualices tu MIG desde la consola de Google Cloud . Para ver la configuración actual, consulta Obtener las propiedades de un MIG.

Una actualización falla si requiere una acción más disruptiva de lo que has permitido. Si esto ocurre, puedes volver a intentar la actualización con una acción permitida más disruptiva o actualizar la instancia de forma selectiva. Compute Engine realiza una validación de mejor esfuerzo para comprobar si las instancias se pueden actualizar con el límite de interrupción especificado. Sin embargo, debido a los cambios simultáneos en el sistema, la situación puede cambiar después de que empiece la actualización. Si falla una operación en una instancia concreta, lista los errores de la instancia para ver el error.

Reiniciar o reemplazar de forma progresiva

Un reinicio gradual detiene y reinicia todas las instancias, mientras que una sustitución gradual sustituye todas las instancias según la opción Método de sustitución. Puede que quieras realizar un reinicio gradual o una sustitución por los siguientes motivos:

• Se han corregido las fugas de memoria.
• Reinicia la aplicación para que se pueda ejecutar desde un equipo nuevo.
• Aplica una sustitución periódica como práctica recomendada para probar tus instancias.
• Actualiza la imagen del sistema operativo de tu instancia o vuelve a ejecutar las secuencias de comandos de inicio para actualizar tu software.

Cuando realizas un reinicio gradual o una sustitución de las instancias mediante laGoogle Cloud consola o la CLI de Google Cloud, se llevan a cabo las siguientes acciones subyacentes en el MIG. Sin embargo, si usas REST, debes definir estos campos en la solicitud para activar una operación de reinicio o sustitución.

• Si el updatePolicy.type es OPPORTUNISTIC, el MIG cambia el tipo a AUTOMATIC.
• El MIG actualiza el versions.name de cada instancia.

Para realizar un reinicio gradual o una sustitución, selecciona una de las siguientes opciones:

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

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

Después de completar una operación de reinicio o sustitución, puedes listar las VMs del MIG e inspeccionar el campo versions.name de cada VM para determinar cuáles se han reiniciado o sustituido.

Ejemplos adicionales de sustitución o reinicio

Realiza un reinicio gradual de todas las VMs, de dos en dos

El siguiente comando reinicia todas las VMs del grupo, de dos en dos. Ten en cuenta que no se ha especificado una nueva plantilla de instancia.

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

Realiza un reinicio gradual de todas las VMs lo más rápido posible

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

Realizar una sustitución gradual de todas las VMs lo más rápido posible

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

Conservar los nombres de las instancias

Si necesitas conservar los nombres de tus instancias de VM durante una actualización, asigna el valor RECREATE al campo replacementMethod. También debes definir maxUnavailable como un valor superior a 0 y maxSurge como 0. Si vuelves a crear las instancias en lugar de sustituirlas, la actualización tardará más en completarse, pero las instancias actualizadas conservarán sus nombres.

Si no especificas ningún método de sustitución, se usará el valor updatePolicy.replacementMethod actual de la MIG. Si no se define, se usará el valor predeterminado de substitute, que sustituye las instancias de VM por instancias nuevas con nombres generados aleatoriamente.

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]

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"
    } ]
}

Después de enviar una solicitud, puedes monitorizar la actualización para saber cuándo ha terminado.

Actualizar un grupo de instancias gestionado regional

Un MIG regional contiene instancias de VM que se distribuyen en varias zonas de una región, a diferencia de un MIG zonal, que solo contiene instancias en una zona. Los MIGs regionales te permiten distribuir tus instancias en más de una zona para mejorar la disponibilidad de tu aplicación y para dar respuesta a casos extremos en los que una zona falla o un grupo entero de instancias deja de responder.

Actualizar un MIG regional es lo mismo que actualizar un MIG zonal, con algunas excepciones que se describen a continuación. Cuando inicias una actualización de un MIG regional, Updater siempre actualiza las instancias de forma proporcional y uniforme en cada zona. No puedes elegir qué instancias de qué zonas se actualizan primero ni actualizar las instancias de una sola zona.

Diferencias entre actualizar grupos de instancias gestionados regionales y zonales

Los MIGs regionales tienen los siguientes valores de actualización predeterminados:

• maxUnavailable=NUMBER_OF_ZONES
• maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES es el número de zonas asociadas al MIG regional. De forma predeterminada, el número de zonas de un MIG regional es 3. Pero puedes seleccionar otro número.

Si usas números fijos al especificar una actualización, el número fijo debe ser 0 o igual o superior al número de zonas asociadas a la MIG regional. Por ejemplo, si el grupo se distribuye en tres zonas, no puedes definir maxSurge en 1 ni en 2, ya que el actualizador tiene que crear una instancia adicional en cada una de las tres zonas.

Usar un número fijo o un porcentaje en las solicitudes de actualización

Si especificas un número fijo en tus solicitudes de actualización, el número que indiques se dividirá entre el número de zonas del MIG regional y se distribuirá de forma uniforme. Por ejemplo, si especificas maxSurge=10, Updater divide 10 entre el número de zonas de la región y crea instancias en función de ese número. Si el número de instancias no se divide de forma equitativa entre las zonas, el actualizador añade las instancias restantes a una zona aleatoria. Por lo tanto, en el caso de 10 instancias en tres zonas, dos de las zonas obtienen 3 instancias y una zona obtiene 4 instancias. Se aplica la misma lógica a los parámetros maxUnavailable y targetSize para las actualizaciones canary.

Solo puedes especificar un porcentaje si tu MIG contiene 10 o más instancias de VM. Los porcentajes se gestionan de forma ligeramente diferente en función de la situación:

• Si especificas un porcentaje de instancias de VM para una actualización canary, el actualizador intentará distribuir las instancias de forma uniforme entre las zonas. El resto se redondea hacia arriba o hacia abajo en cada zona, pero la diferencia total no es superior a una instancia de VM por grupo. Por ejemplo, en un MIG con 10 instancias y un porcentaje de tamaño objetivo del 25%, la actualización se implementa en 2 o 3 instancias de VM.

• Si especificas un porcentaje para las opciones de actualización, como maxSurge y maxUnavailable, los porcentajes se redondean de forma independiente por zona.

Siguientes pasos

• Consulta información sobre instancias y grupos de instancias gestionados.
• Crear plantillas de instancia
• Consulta cómo usar familias de imágenes y una sustitución continua para actualizar la imagen del SO en todas las VMs de un MIG.