Estrategias de actualización de nodos

En este documento se describen las estrategias de actualización de nodos que puedes usar con tus clústeres de Google Kubernetes Engine (GKE).

En los clústeres de GKE Standard, puedes configurar una de las siguientes estrategias de actualización de nodos para cada grupo de nodos Standard:

  • Actualizaciones con compensación: los nodos se actualizan en una ventana de tiempo. Puedes controlar cuántos nodos se pueden actualizar a la vez y cómo afectan las actualizaciones a las cargas de trabajo.
  • Actualizaciones azul-verde: los nodos se mantienen disponibles para revertir los cambios mientras se validan las cargas de trabajo en la nueva configuración de nodos.
  • Actualizaciones azul-verde con autoescalado (Vista previa): las cargas de trabajo pueden ejecutarse durante más tiempo, mientras minimizas los costes de los nodos inactivos o infrautilizados.

GKE elige las siguientes estrategias para estos casos concretos:

  • En los clústeres de Autopilot, GKE usa actualizaciones de picos. Para obtener más información, consulta la sección Actualizaciones de aumento del documento Actualizaciones de clústeres de Autopilot.
  • En los grupos de nodos gestionados por Autopilot de los clústeres estándar, GKE usa las actualizaciones de picos. No puedes seleccionar otra estrategia ni cambiar la configuración.
  • En los nodos que usan VMs de inicio flexible, GKE usa actualizaciones de corta duración. Flex-start con aprovisionamiento en cola admite nuevas marcas que forman parte del lanzamiento de la vista previa de flex-start. Flex-start se basa en Dynamic Workload Scheduler.

Si eliges una estrategia de actualización para tu grupo de nodos estándar, podrás seleccionar el proceso que mejor se adapte a tus necesidades en cuanto a velocidad, interrupción de la carga de trabajo, mitigación de riesgos y optimización de costes. Para obtener más información sobre qué estrategia de actualización de nodos es la adecuada para tu entorno, consulta lo siguiente:

Con cada una de estas estrategias, puede configurar los ajustes de actualización para optimizar el proceso en función de las necesidades de su entorno. Para obtener más información, consulta Configurar la estrategia de actualización que hayas elegido. Asegúrese de que, para la estrategia que elija, tenga suficiente cuota, disponibilidad de recursos o capacidad de reserva para actualizar sus nodos con esa estrategia. Para obtener más información, consulta Asegurar recursos para las actualizaciones de nodos.

Sobreaprovisionamiento para actualizaciones

Las actualizaciones de oleada son la estrategia de actualización predeterminada y la más adecuada para las aplicaciones que pueden gestionar cambios incrementales. Las actualizaciones de oleada usan un método de actualización gradual de los nodos en un orden indefinido. Encuentra el equilibrio óptimo entre velocidad e interrupción para tu entorno eligiendo cuántos nodos nuevos y de aumento se pueden crear con maxSurge y cuántos nodos se pueden interrumpir a la vez con maxUnavailable.

Las actualizaciones de picos también funcionan con la herramienta de ajuste automático de escala de clústeres para evitar cambios en los nodos que se están actualizando.

Cuándo elegir actualizaciones de aumento de la demanda para tu entorno

Si la optimización de costes es importante para ti y tu carga de trabajo puede tolerar que se cierre en menos de 60 minutos, te recomendamos que elijas actualizaciones de picos para tus grupos de nodos.

Las actualizaciones de aumento son óptimas en los siguientes casos:

  • Si quieres optimizar la velocidad de las actualizaciones.
  • Si las cargas de trabajo toleran mejor las interrupciones, en cuyo caso se acepta una finalización correcta de hasta 60 minutos.
  • Si quieres controlar los costes minimizando la creación de nodos.

Cuándo usa GKE las actualizaciones de picos

Si está habilitada, GKE usa las actualizaciones de picos cuando se producen los siguientes tipos de cambios:

Otros cambios, como aplicar actualizaciones a etiquetas de nodos y taints de grupos de nodos existentes, no usan actualizaciones de oleada, ya que no requieren recrear los nodos.

Información sobre los ajustes de sobreaprovisionamiento para actualizaciones

Usa los ajustes de actualización de picos para seleccionar el equilibrio adecuado entre velocidad e interrupción de tu grupo de nodos durante el mantenimiento del clúster. Puedes cambiar el número de nodos que GKE intenta actualizar a la vez modificando los parámetros de actualización simultánea de un grupo de nodos Estándar.

El comportamiento de la actualización de Surge se determina mediante los ajustes maxSurge y maxUnavailable, que determinan cuántos nodos se actualizan al mismo tiempo en una ventana de actualización gradual con los pasos descritos.

maxSurge: GKE crea un nuevo nodo de aumento antes de eliminar uno que ya exista

Define maxSurge para elegir el número máximo de nodos adicionales de aumento que se pueden añadir al grupo de nodos durante una actualización por zona, lo que aumenta la probabilidad de que las cargas de trabajo que se ejecutan en el nodo actual puedan migrar a un nuevo nodo inmediatamente. El valor predeterminado es 1. Para actualizar un nodo, GKE sigue estos pasos:

  1. Aprovisiona un nuevo nodo.
  2. Espera a que el nuevo nodo esté listo.
  3. Acordonar el nodo.
  4. Drena el nodo actual, respetando PodDisruptionBudget y GracefulTerminationPeriod durante un máximo de una hora. Al cabo de una hora, se expulsarán de forma forzosa los pods restantes para que se pueda continuar con la actualización.
  5. Elimina el nodo que ya tienes.

Para que GKE cree nodos de aumento, tu proyecto debe tener los recursos necesarios para crear nodos adicionales de forma temporal. Si no tienes capacidad adicional, GKE no empezará a actualizar un nodo hasta que los recursos estén disponibles. Para obtener más información, consulta Recursos para las actualizaciones de picos de demanda.

maxUnavailable: GKE inhabilita un nodo para volver a crearlo

Define maxUnavailable para elegir el número máximo de nodos que pueden no estar disponibles simultáneamente durante una actualización por zona. El valor predeterminado es cero. Es posible que las cargas de trabajo que se ejecutan en el nodo actual tengan que esperar a que se actualice el nodo actual si no hay otros nodos con capacidad. Para actualizar un nodo, GKE sigue estos pasos:

  1. Cordon el nodo actual.
  2. Drena el nodo actual, respetando los ajustes de PodDisruptionBudget y GracefulTerminationPeriod durante un máximo de una hora. Al cabo de una hora, se expulsarán de forma forzosa los pods restantes para que se pueda continuar con la actualización.
  3. Vuelve a crear el nodo con la nueva configuración.
  4. Espera a que el nodo esté listo.
  5. Desactiva el acordonamiento del nodo actualizado.

Cuando GKE vuelve a crear el nodo, libera temporalmente la capacidad del nodo si no procede de una reserva. Esto significa que, si la capacidad es limitada, corres el riesgo de perder la capacidad actual. Por lo tanto, si tu entorno tiene recursos limitados, utiliza este ajuste solo si usas nodos reservados. Para obtener más información, consulta Actualizar en un entorno con recursos limitados.

Ejemplo de uso de los ajustes de maxSurge y maxUnavailable

Por ejemplo, un clúster de GKE tiene un grupo de nodos de una sola zona con 5 nodos y la siguiente configuración de actualización gradual: maxSurge=2;maxUnavailable=1.

Durante una actualización de aumento con este grupo de nodos, en una ventana de tiempo, GKE crea dos nodos actualizados y afecta a un nodo como máximo a la vez. GKE elimina como máximo tres nodos después de que los nodos actualizados estén listos. Durante el proceso de actualización, el grupo de nodos incluirá entre cuatro y siete nodos.

Consideraciones sobre la configuración de sobreaprovisionamiento para actualizaciones

Ten en cuenta la siguiente información antes de configurar los ajustes de actualización de la facturación por demanda:

Ajustar la configuración de la actualización de subida de tensión para equilibrar la velocidad y las interrupciones

En la siguiente tabla se describen cuatro perfiles de actualización diferentes como ejemplos para ayudarte a entender las distintas configuraciones:

Descripción Configuración Caso práctico habitual
Equilibrado (predeterminado), más lento, pero menos disruptivo maxSurge=1 maxUnavailable=0 Mayoría de cargas de trabajo
Rápido, sin recursos de aumento, más disruptivo maxSurge=0 maxUnavailable=20 Grandes grupos de nodos después de que las tareas se hayan ejecutado hasta completarse
Rápido, con la mayoría de los recursos de aumento y menos disruptivo maxSurge=20 maxUnavailable=0 Grupos de nodos grandes
Más lento, disruptivo y sin recursos de aumento maxSurge=0 maxUnavailable=1 Grupo de nodos con limitaciones de recursos y reserva

Equilibrado (predeterminado)

La forma más sencilla de aprovechar las actualizaciones de picos es usar la configuración predeterminada, maxSurge=1;maxUnavailable=0. Con esta configuración, las actualizaciones se realizan lentamente, ya que solo se añade un nodo de pico a la vez, lo que significa que solo se actualiza un nodo a la vez. Los pods pueden reiniciarse inmediatamente en el nuevo nodo de sobrecarga. Esta configuración solo requiere que los recursos creen temporalmente un nodo nuevo.

Rápido y sin recursos adicionales

Si tienes un grupo de nodos grande y tu carga de trabajo no es sensible a las interrupciones (por ejemplo, un trabajo por lotes que se ha completado), usa la siguiente configuración para maximizar la velocidad sin usar recursos adicionales: maxSurge=0;maxUnavailable=20. Esta configuración no activa nodos de sobrecarga adicionales y permite actualizar 20 nodos al mismo tiempo.

Rápido y menos disruptivo

Si tu carga de trabajo es sensible a las interrupciones y ya has configurado PodDisruptionBudgets (PDB) y no usas externalTrafficPolicy: Local, que no funciona con el drenaje de nodos en paralelo, puedes aumentar la velocidad de la actualización con maxSurge=20;maxUnavailable=0. Esta configuración actualiza 20 nodos en paralelo, mientras que el PDB limita el número de pods que se pueden vaciar en un momento dado. Aunque las configuraciones de los PDBs pueden variar, si creas un PDB con maxUnavailable=1 para una o varias cargas de trabajo que se ejecuten en el grupo de nodos, solo se podrá desalojar un pod de esas cargas de trabajo a la vez, lo que limitará el paralelismo de toda la actualización. Esta configuración requiere que los recursos creen temporalmente 20 nodos.

Lento, pero sin recursos de aumento

Si no puedes usar ningún recurso adicional, puedes usar maxSurge=0;maxUnavailable=1 para recrear los nodos de uno en uno.

Controlar una actualización con compensación en curso

Con las actualizaciones de picos, mientras se lleva a cabo una actualización, puedes usar comandos para ejercer cierto control sobre ella. Para tener más control sobre el proceso de actualización, te recomendamos que utilices las actualizaciones azul-verde.

Cancelar (pausar) una actualización con compensación

Puedes cancelar una actualización de subida de tensión en curso en cualquier momento durante el proceso de actualización. Si cancelas la actualización, se pausará y GKE dejará de actualizar los nodos nuevos, pero no se revertirá automáticamente la actualización de los nodos que ya se hayan actualizado. Después de cancelar una actualización, puedes reanudarla o restaurar la versión anterior.

Cuando cancelas una actualización, GKE hace lo siguiente con cada uno de los nodos:

  • Los nodos que hayan iniciado la actualización la completarán.
  • Los nodos que no hayan iniciado la actualización no se actualizarán.
  • Los nodos que ya hayan completado la actualización correctamente no se verán afectados y no se revertirán.

Esto significa que el grupo de nodos puede acabar en un estado en el que los nodos ejecuten dos versiones diferentes. Si las actualizaciones automáticas están habilitadas en el grupo de nodos, se puede programar otra actualización automática para el grupo de nodos, lo que actualizaría los nodos restantes del grupo que ejecutan la versión anterior.

Consulta cómo cancelar una actualización de un grupo de nodos.

Reanudar una actualización con compensación

Si se ha cancelado una actualización de un grupo de nodos y se ha completado parcialmente, puedes reanudarla para completar el proceso de actualización del grupo de nodos. De esta forma, se actualizarán los nodos restantes que no se hayan actualizado en la operación original. Consulta cómo reanudar una actualización de un grupo de nodos.

Restaurar una actualización con compensación

Si un grupo de nodos se actualiza parcialmente, puedes restaurarlo para que vuelva a su estado anterior. No puedes restaurar grupos de nodos después de que se hayan actualizado correctamente. Los nodos que no hayan iniciado una actualización no se verán afectados. Consulta cómo revertir una actualización de un grupo de nodos.

Si quieres volver a la versión anterior de un grupo de nodos después de haber completado la actualización, consulta Volver a una versión anterior de grupos de nodos.

Actualizaciones azul-verde

Las actualizaciones azul-verde son una estrategia de actualización alternativa a la estrategia de actualización de picos predeterminada. Con las actualizaciones azul-verde, GKE primero crea un nuevo conjunto de recursos de nodo (nodos "verdes") con la nueva configuración de nodo antes de desalojar las cargas de trabajo de los recursos originales (nodos "azules"). GKE conserva los recursos "azules", si es necesario, para revertir las cargas de trabajo hasta que se cumpla el tiempo de permanencia. Puedes ajustar el ritmo de las actualizaciones y el tiempo de absorción en función de las necesidades de tu entorno.

Con esta estrategia, tienes más control sobre el proceso de actualización. Si es necesario, puedes revertir una actualización en curso, ya que el entorno original se mantiene durante la actualización. Sin embargo, esta estrategia de actualización también requiere más recursos. Como el entorno original se replica, el grupo de nodos usa el doble de recursos durante la actualización.

Cuándo elegir actualizaciones azul-verde para tu entorno

Si tienes cargas de trabajo de producción de alta disponibilidad que necesitas poder revertir rápidamente en caso de que la carga de trabajo no tolere la actualización y se pueda aceptar un aumento temporal de los costes, te recomendamos que elijas las actualizaciones azul-verde para tus grupos de nodos.

Las actualizaciones azul-verde son óptimas en los siguientes casos:

  • Si quieres una implementación gradual en la que la mitigación de riesgos sea lo más importante y necesites una finalización correcta de más de 60 minutos.
  • si tus cargas de trabajo toleran menos las interrupciones.
  • Si se acepta un aumento temporal de los costes debido a un mayor uso de los recursos.

Las actualizaciones azul-verde continúan hasta completarse si superan una ventana de mantenimiento. Para obtener más información, consulta Cómo funcionan las estrategias de actualización de nodos con las ventanas de mantenimiento.

Cuándo usa GKE las actualizaciones azul-verde

En el caso de los nodos de GKE, hay diferentes tipos de cambios de configuración que requieren que se vuelvan a crear los nodos. Si está habilitada, GKE usa actualizaciones azul-verde cuando se producen los siguientes tipos de cambios:

Las actualizaciones con compensación se usan para cualquier otra actualización que requiera que se vuelvan a crear los nodos. Para obtener más información, consulta Cuándo se usan las actualizaciones de subida.

Fases de las actualizaciones azul-verde

Con las actualizaciones azul-verde, puedes personalizar y controlar el proceso de las siguientes formas:

En esta sección se explican las fases del proceso de actualización. Puedes usar los ajustes de actualización para configurar cómo funcionan las fases y los comandos para controlar el proceso de actualización.

Fase 1: Crear un grupo verde

En esta fase, se crea un nuevo conjunto de grupos de instancias gestionadas (MIGs), conocido como el grupo "verde", para cada zona del grupo de destino con la nueva configuración de nodos (nueva versión o tipo de imagen).

Se comprobará la Quota antes de empezar a aprovisionar nuevos recursos verdes.

En esta fase, el escalador automático del clúster de los MIGs originales (conocido como el grupo azul) dejará de aumentar o reducir la escala. El grupo verde solo puede aumentar en esta fase.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se pone en pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla. En esta fase, si revierte la versión, se eliminará el grupo verde.

Fase 2: Cordon blue pool

En esta fase, todos los nodos originales del grupo azul (los MIGs) se acordonarán (se marcarán como no programables). Las cargas de trabajo que ya tengas seguirán ejecutándose, pero las nuevas no se programarán en los nodos actuales.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se pone en pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla. En esta fase, la reversión desactivará el acordonamiento de la piscina azul y eliminará la verde.

Fase 3: Drenar el grupo azul

En esta fase, los nodos originales del grupo azul (MIGs) se vaciarán por lotes. Cuando Kubernetes anula un nodo, se envían solicitudes de desalojo a todos los pods que se ejecutan en el nodo. Los pódcasts se reprogramarán. Los pods que tengan infracciones de PodDisruptionBudget o un valor de terminationGracePeriodSeconds largo durante el drenaje se eliminarán en la fase Eliminar grupo azul cuando se elimine el nodo. Puedes usar BATCH_SOAK_DURATION y NODE_POOL_SOAK_DURATION, que se describen aquí y en la siguiente sección, para ampliar el periodo antes de que se eliminen los pods.

Puedes controlar el tamaño de los lotes con cualquiera de los siguientes ajustes:

  • BATCH_NODE_COUNT: el número absoluto de nodos que se van a vaciar en un lote.
  • BATCH_PERCENT: porcentaje de nodos que se van a vaciar en un lote, expresado como un decimal entre 0 y 1, ambos incluidos. GKE redondea a la baja al porcentaje de nodos más cercano, con un valor mínimo de 1 nodo, si el porcentaje no es un número entero de nodos.

Si alguno de estos ajustes se establece en cero, GKE omitirá esta fase y pasará a la fase Soak node pool (Grupo de nodos de prueba).

Además, puedes controlar el tiempo que se empapa cada lote con BATCH_SOAK_DURATION. Esta duración se define en segundos y el valor predeterminado es cero segundos.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla. Si el lote anterior ya se ha agotado y reanudas la actualización, es posible que el siguiente lote de nodos se procese inmediatamente sin respetar el BATCH_SOAK_DURATION de ese lote. Si vuelves a la versión anterior en esta fase, se detendrá el drenaje del grupo azul y se quitará la valla. Las cargas de trabajo se pueden reprogramar en el grupo azul (no es seguro) y el grupo verde se vacía y se elimina.

Fase 4: Poner a prueba el grupo de nodos

Esta fase se utiliza para que verifiques el estado de la carga de trabajo después de que se hayan vaciado los nodos del grupo azul.

El tiempo de remojo se define con NODE_POOL_SOAK_DURATION, en segundos. De forma predeterminada, se establece en una hora (3600 segundos). Si la duración total de la prueba de resistencia alcanza los 7 días (604.800 segundos), se inicia inmediatamente la fase de eliminación del grupo azul.

La duración total de la prueba de carga es la suma de NODE_POOL_SOAK_DURATION más BATCH_SOAK_DURATION multiplicado por el número de lotes, que se determina mediante BATCH_NODE_COUNT o BATCH_PERCENT.

En esta fase, puedes completar la actualización y saltarte el tiempo de prueba restante completando la actualización. De esta forma, se iniciará inmediatamente el proceso de eliminación de los nodos del grupo azul.

Si es necesario, puedes cancelar la actualización. Cuando cancelas una actualización azul-verde, la actualización se pausa en la fase en la que se encuentre. Una vez que la hayas cancelado, puedes reanudarla o restaurarla.

En esta fase, la herramienta de ajuste automático de escala del clúster puede aumentar o reducir la escala del grupo verde con normalidad.

Fase 5: Eliminar el grupo azul

Una vez transcurrido el tiempo de remojo, los nodos del grupo azul se eliminarán del grupo de destino. Esta fase no se puede pausar. Además, en esta fase no se usa la expulsión, sino que se intenta eliminar los pods. A diferencia del desalojo, la eliminación no respeta los PDBs y elimina los pods de forma forzosa. La eliminación limita la duración de un pódcast a terminationGracePeriodSeconds minutos. Después de este último intento de eliminar los pods restantes, los nodos del grupo azul se eliminan del grupo de nodos.

Cuando finalice esta fase, tu grupo de nodos solo tendrá nodos nuevos con la configuración actualizada (versión o tipo de imagen).

Cómo funciona la herramienta de escalado automático de clústeres con las actualizaciones azul-verde

Durante las fases de una actualización azul-verde, el grupo "azul" original no se amplía ni se reduce. Cuando se crea el nuevo grupo "verde", solo se puede aumentar su tamaño hasta la fase del grupo de nodos de prueba, en la que se puede aumentar o reducir. Si se revierte una actualización, el grupo "azul" original puede aumentar su capacidad durante este proceso si se necesita más.

Controlar una actualización azul-verde en curso

Con las actualizaciones azul-verde, mientras se lleva a cabo una actualización, puedes usar comandos para controlarla. De esta forma, tendrás un alto nivel de control sobre el proceso por si, por ejemplo, determinas que tus cargas de trabajo deben volver a la configuración de nodo anterior.

Cancelar (pausar) una actualización azul-verde

Si cancelas una actualización azul-verde, la pausarás en la fase en la que se encuentre. Este comando se puede usar en todas las fases, excepto en la fase de eliminación del grupo azul. Cuando se cancele, el grupo de nodos se pausará en un estado intermedio en función de la fase en la que se haya emitido la solicitud.

Consulta cómo cancelar una actualización de un grupo de nodos.

Una vez cancelada la actualización, puedes elegir entre dos opciones: reanudar o restaurar la versión anterior.

Reanudar una actualización azul-verde

Si has determinado que se puede continuar con la actualización, puedes reanudarla.

Si reanudas el proceso, la actualización continuará en la fase intermedia en la que se pausó. Para saber cómo reanudar la actualización de un grupo de nodos, consulta Reanudar la actualización de un grupo de nodos.

Revertir una actualización azul-verde

Si has determinado que la actualización no debería continuar y quieres restaurar el grupo de nodos a su estado original, puedes revertir el proceso. Para saber cómo revertir una actualización de un grupo de nodos, consulta Revertir una actualización de un grupo de nodos.

Con el flujo de trabajo de reversión, el proceso se invierte para devolver el grupo de nodos a su estado original. Se quitará el cordón de la piscina azul para que se puedan reprogramar las cargas de trabajo en ella. Durante este proceso, la herramienta de ajuste automático de escala del clúster puede aumentar la escala del grupo azul según sea necesario. La piscina verde se vaciará y se eliminará.

Si quieres volver a la versión anterior de un grupo de nodos después de haber completado la actualización, consulta Volver a una versión anterior de grupos de nodos.

Completar una actualización azul-verde

Durante la fase de prueba de resistencia, puedes completar una actualización si has determinado que la carga de trabajo no necesita más validación en la nueva configuración de nodos y que se pueden quitar los nodos antiguos. Si completas una actualización, se omitirá el resto de la fase de prueba de resistencia y se pasará a la fase de eliminación del grupo azul.

Para obtener más información sobre cómo usar el comando complete, consulta Completar una actualización de un grupo de nodos azul-verde.

Actualizaciones azul-verde con escalado automático

Las actualizaciones azul-verde con escalado automático son un tipo de estrategia de actualización diferente que maximiza el tiempo que transcurre antes de que se desalojen las cargas de trabajo que no toleran las interrupciones y, al mismo tiempo, minimiza los costes. Esta estrategia se deriva de las actualizaciones azul-verde estándar. Sin embargo, con las actualizaciones azul-verde autoescaladas, GKE no vacía los nodos con cargas de trabajo que estén marcadas como no seguras para desalojar hasta siete días después de que se hayan acordonado los nodos.

En la siguiente sección se explica cuándo debes elegir esta estrategia, en qué se diferencia su implementación de las actualizaciones azul-verde estándar y qué prácticas recomendadas debes seguir al usarla.

Para usar las actualizaciones azul-verde con escalado automático, consulta Configurar actualizaciones azul-verde con escalado automático.

Cuándo elegir actualizaciones azul-verde con escalado automático para tu entorno

Si tienes cargas de trabajo que necesitan el máximo tiempo antes de la expulsión, pero no es necesario reprogramarlas lo antes posible, te recomendamos que elijas actualizaciones azul-verde con escalado automático para tus grupos de nodos.

Las actualizaciones azul-verde con escalado automático funcionan bien si se dan las siguientes circunstancias:

  • Tienes cargas de trabajo por lotes que deben ejecutarse hasta completarse.
  • Quieres minimizar los costes en comparación con las actualizaciones azul-verde estándar minimizando el número de nodos inactivos o infrautilizados.
  • No necesitas Pods para garantizar la reprogramación inmediata ni la restauración inmediata a la configuración del nodo anterior.

Elige las actualizaciones azul-verde estándar si necesitas minimizar el tiempo necesario para reprogramar las cargas de trabajo en los nuevos nodos y la posibilidad de restaurar la configuración del nodo anterior.

Las actualizaciones azul-verde con autoescalado, como las actualizaciones azul-verde estándar, continúan hasta completarse si superan una ventana de mantenimiento. Para obtener más información, consulta Cómo funcionan las estrategias de actualización de nodos con las ventanas de mantenimiento.

Fases de las actualizaciones azul-verde con escalado automático

Cuando GKE actualiza grupos de nodos con actualizaciones azul-verde autoescaladas, las fases son diferentes a las de las actualizaciones azul-verde estándar. Para ver las fases de la estrategia de actualización estándar, consulta las fases de las actualizaciones azul-verde.

Cuando se habilita la política de actualizaciones azul-verde con escalado automático, GKE realiza estos pasos durante una operación:

  1. GKE crea el grupo verde. Sin embargo, el grupo verde empieza con cero nodos. Cuando GKE expulsa pods del grupo azul en una fase posterior, la herramienta de adaptación dinámica del clúster aumenta el tamaño del grupo verde para ejecutar esos pods.
  2. GKE aisla el grupo azul.

  3. GKE espera un periodo que puedes configurar entre cero y siete días (el valor predeterminado es de tres días). Durante este tiempo, GKE hace lo siguiente:

  4. GKE vacía el grupo azul, vaciando los nodos restantes del grupo azul de 20 en 20 en paralelo. GKE respeta los ajustes de PodDisruptionBudget durante un máximo de 1 hora y los de terminationGracePeriodSeconds durante un máximo de 24 horas.

  5. GKE omite la fase de inmersión del grupo de nodos.

  6. GKE elimina el grupo azul.

Prácticas recomendadas para las actualizaciones azul-verde con escalado automático

En las siguientes secciones se describen las prácticas recomendadas para tu clúster, grupo de nodos y pods, con el objetivo de minimizar las interrupciones de las cargas de trabajo durante las actualizaciones azul-verde con escalado automático.

Configuración de clústeres y grupos de nodos

  • GKE respeta los límites de autoescalado al aumentar el tamaño del grupo verde. Define los parámetros --max-nodes o --total-max-nodes con valores lo suficientemente altos para que el escalador automático de clústeres pueda aumentar el tamaño del grupo verde cuando GKE vuelva a programar las cargas de trabajo del grupo azul al grupo verde. GKE no tiene en cuenta los parámetros --min-nodes ni --total-min-nodes al reducir la escala del grupo azul.
  • Configura el optimize-utilization perfil de autoescalado si quieres que GKE reduzca el número de nodos infrautilizados del grupo azul de forma más agresiva. Para obtener más información, consulta Perfiles de autoescalado.
  • No actualices los grupos de nodos creados con el aprovisionamiento automático de nodos para usar las actualizaciones azul-verde con escalado automático. Además, no configures tu clúster para que use actualizaciones azul-verde con autoescalado en los nuevos grupos de nodos aprovisionados automáticamente.

Configuración de pod

  • Para asegurarte de que los pods no se desalojen durante la pausa antes de vaciar el grupo azul, añade la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a esos pods. Esta anotación evita que el escalador automático de clústeres expulse el pod si el nodo del pod está infrautilizado.
  • Al igual que con las actualizaciones azul-verde estándar, para asegurarte de que los pods expulsados de los nodos del grupo azul solo se vuelvan a programar en los nodos del grupo verde, añade un nodeSelector para la etiqueta cloud.google.com/gke-nodepool:NODE_POOL_NAME a tu carga de trabajo. Si omite esta etiqueta y tiene otros grupos de nodos en su clúster, es posible que sus pods desalojados se programen en nodos de esos otros grupos de nodos.

Limitaciones de las actualizaciones azul-verde con escalado automático

  • Puedes cancelar y reanudar las actualizaciones azul-verde con escalado automático. Sin embargo, no puedes revertir la actualización cancelada.
  • Cuando el grupo azul se acordona y se vacía, los pods pueden dejar de programarse temporalmente si el escalador automático de clúster no puede aumentar la escala del grupo verde debido a las cuotas y los límites o a la disponibilidad de recursos, ya que el grupo verde se crea con cero nodos.
  • Solo puedes actualizar grupos de nodos con actualizaciones azul-verde con escalado automático si el plano de control del clúster ejecuta la versión 1.34.0-gke.2201000 o una posterior y el escalador automático de clúster está habilitado.

Cuándo usa GKE las actualizaciones azul-verde con escalado automático

GKE usa actualizaciones azul-verde con escalado automático para los mismos tipos de cambios que las actualizaciones azul-verde estándar. Para obtener más información sobre los tipos de cambios para los que GKE usa la estrategia de actualización azul-verde estándar, consulta Cuándo usa GKE las actualizaciones azul-verde.

Cómo funciona la herramienta de adaptación dinámica de clústeres con las actualizaciones azul-verde con escalado automático

Para configurar las actualizaciones azul-verde con autoescalado, también debes configurar el autoescalador de clústeres.

Si usas actualizaciones azul-verde con escalado automático, la herramienta de escalado automático de clústeres hace lo siguiente:

  • Durante la fase en la que GKE espera a que se vacíe el grupo azul, este no se amplía y solo se reduce mediante el escalador automático de clústeres cuando los nodos se infrautilizan. La herramienta de ajuste automático de escala del clúster puede reducir el tamaño del grupo azul a cero sin tener en cuenta los parámetros --min-nodes ni --total-min-nodes. En el resto de las fases, el autoescalador de clúster no escala ni reduce verticalmente el grupo azul.
  • La herramienta de ajuste automático de escala de clústeres aumenta el tamaño del grupo verde desde cero nodos o lo reduce hasta el ajuste --min-nodes, según sea necesario en todas las fases de la estrategia de actualización.

Mejoras de corta duración (solo con inicio flexible y aprovisionamiento en cola)

Las actualizaciones de corta duración son una estrategia de actualización de nodos que se usa exclusivamente con nodos que utilizan máquinas virtuales de inicio flexible y nodos que utilizan el aprovisionamiento en cola (con la versión 1.32.2-gke.1652000 o posterior), ambos basados en Dynamic Workload Scheduler. Para obtener más información sobre los nodos que usan licencias de corta duración, consulta el artículo Acerca de la disponibilidad de GPUs con Dynamic Workload Scheduler.

GKE usa la estrategia de actualización de corta duración para los grupos de nodos y los grupos de nodos Standard en los clústeres de Autopilot.

Con esta estrategia, GKE actualiza estos nodos de tiempo de ejecución limitados sin interrumpir las cargas de trabajo. La estrategia funciona de la siguiente manera:

  1. Los nodos que ya tengas se ejecutarán hasta que se les asigne prioridad.
  2. Los nodos nuevos usan la nueva configuración de nodos.
  3. En un plazo máximo de siete días, los nodos pasarán de ejecutar la configuración actual a ejecutar la nueva.

GKE configura automáticamente esta estrategia para los nodos que usan máquinas virtuales de inicio flexible. Esta estrategia no tiene ajustes de configuración.

Cuándo usa GKE actualizaciones de corta duración

GKE configura automáticamente los nodos que usan VMs de inicio flexible para aplicar actualizaciones de corta duración. Los nodos que solo usan el aprovisionamiento en cola, pero que se ejecutan en clústeres con la versión 1.32.2-gke.1652000 de GKE o una posterior, también usan actualizaciones de corta duración.

En los grupos de nodos y los grupos de nodos estándar de los clústeres de Autopilot que usan actualizaciones de corta duración, GKE utiliza esta estrategia en situaciones en las que, de lo contrario, se usarían actualizaciones de aumento. Además de las actualizaciones de nodos (cambios de versión), GKE usa actualizaciones de corta duración para otros tipos de actualizaciones de nodos, de forma similar a como se usan las actualizaciones de picos. Para obtener más información, consulta Cuándo se usan las actualizaciones de aumento.

Siguientes pasos