Estrategias de actualización de nodos

En este documento, se analizan 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 de Standard:

  • Actualizaciones de aumento: Los nodos se actualizan en una ventana progresiva. Puedes controlar cuántos nodos se pueden actualizar a la vez y qué tan perjudiciales son las actualizaciones para las cargas de trabajo.
  • Actualizaciones azul-verde: Los nodos existentes se mantienen disponibles para la reversión mientras las cargas de trabajo se validan en la configuración de nodo nuevo.
  • Actualizaciones azul-verde con ajuste de escala automática (versión preliminar): Las cargas de trabajo pueden ejecutarse durante más tiempo, mientras minimizas el costo de los nodos inactivos o subutilizados.

GKE elige las siguientes estrategias para estas situaciones específicas:

  • En los clústeres de Autopilot, GKE usa actualizaciones de aumento. Para obtener más información, consulta la sección Actualizaciones repentinas del documento sobre las actualizaciones de clústeres de Autopilot.
  • Para los grupos de nodos administrados por Autopilot en los clústeres de Standard, GKE usa actualizaciones de aumento. No puedes seleccionar otra estrategia ni cambiar la configuración.
  • En el caso de los nodos que usan VMs de inicio flexible, GKE usa actualizaciones de corta duración. El inicio flexible con aprovisionamiento en cola admite nuevas marcas que forman parte del lanzamiento de la versión preliminar del inicio flexible. El inicio flexible cuenta con la tecnología del programador dinámico de cargas de trabajo.

Si eliges una estrategia de actualización para tu grupo de nodos estándar, puedes seleccionar el proceso con el equilibrio adecuado entre velocidad, interrupción de la carga de trabajo, mitigación de riesgos y optimización de costos. Para obtener más información sobre qué estrategia de actualización de nodos es adecuada para tu entorno, consulta lo siguiente:

Con cada una de estas estrategias, puedes establecer la configuración de la actualización para optimizar el proceso según las necesidades de tu entorno. Para obtener más información, consulta Configura la estrategia de actualización que elegiste. Asegúrate de que, para la estrategia que elijas, tengas suficiente cuota, disponibilidad de recursos o capacidad de reserva para actualizar tus nodos con esa estrategia. Para obtener más información, consulta Garantiza recursos para las actualizaciones de nodos.

Actualizaciones de aumento

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

Las actualizaciones de aumento también funcionan con el escalador automático del clúster para evitar que se realicen cambios en los nodos que se están actualizando.

Cuándo elegir actualizaciones de aumento para tu entorno

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

Las actualizaciones de aumento son óptimas para las siguientes situaciones:

  • si desea optimizar la velocidad de las actualizaciones.
  • Si las cargas de trabajo son más tolerantes a las interrupciones y aceptan una finalización ordenada hasta 60 minutos.
  • si quieres controlar los costos mediante la minimización de la creación de nodos nuevos.

Cuándo GKE usa actualizaciones de aumento

Si está habilitado, GKE usa actualizaciones de aumento cuando se producen los siguientes tipos de cambios:

Otros cambios, incluida la aplicación de actualizaciones a etiquetas de nodo y taints de grupos de nodos existentes, no usan actualizaciones de aumento, ya que no requieren que se vuelvan a crear los nodos.

Comprende la configuración de la actualización de aumento

Usa la configuración de actualización de aumento para seleccionar el equilibrio adecuado entre velocidad e interrupción para el grupo de nodos durante el mantenimiento del clúster mediante la configuración de aumento. Para cambiar la cantidad de nodos que GKE intenta actualizar a la vez, modifica los parámetros de actualización de aumento en un grupo de nodos Standard.

El comportamiento de la actualización de aumento se determina según los parámetros de configuración maxSurge y maxUnavailable, que determinan cuántos nodos se actualizan al mismo tiempo en una ventana progresiva con los pasos descritos.

maxSurge: GKE crea un nodo de aumento nuevo antes de quitar uno existente

Establece maxSurge para elegir la cantidad máxima de nodos adicionales de aumento que se pueden agregar 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 existente puedan migrar a un nodo nuevo de inmediato. El valor predeterminado es uno. Para actualizar un nodo, GKE sigue estos pasos:

  1. Aprovisiona un nodo nuevo.
  2. Espera a que el nodo nuevo esté listo.
  3. Acordona el nodo existente.
  4. Desvía el nodo existente y respeta la configuración de PodDisruptionBudget y GracefulTerminationPeriod durante un máximo de una hora. Después de una hora, se expulsan de forma forzosa los Pods restantes para que pueda continuar la actualización.
  5. Borra el nodo existente.

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 comenzará a actualizar un nodo hasta que los recursos estén disponibles. Para obtener más información, consulta Recursos para actualizaciones de aumento.

maxUnavailable: GKE inhabilita un nodo existente para volver a crearlo

Establece maxUnavailable para elegir la cantidad máxima de nodos que pueden no estar disponibles de forma simultánea durante una actualización, por zona. El valor predeterminado es cero. Es posible que las cargas de trabajo que se ejecutan en el nodo existente deban esperar a que se actualice el nodo existente si ningún otro nodo tiene capacidad. Para actualizar un nodo, GKE sigue estos pasos:

  1. Acordona el nodo existente.
  2. Desvía el nodo existente y respeta la configuración de PodDisruptionBudget y GracefulTerminationPeriod para hasta una hora. Después de una hora, se expulsan de forma forzada los Pods restantes para que pueda continuar la actualización.
  3. Vuelve a crear el nodo existente con la nueva configuración.
  4. Espera a que el nodo existente esté listo.
  5. Desacordona el nodo actualizado existente.

Cuando GKE vuelve a crear el nodo existente, libera temporalmente su capacidad si esta no proviene de una reserva. Esto significa que, si hay capacidad limitada, corres el riesgo de perder la capacidad existente. Por lo tanto, si tu entorno tiene recursos limitados, usa este parámetro de configuración solo si usas nodos reservados. Para obtener más información, consulta Actualiza en un entorno con recursos restringidos.

Ejemplo de uso de la configuración de maxSurge y maxUnavailable

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

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

Consideraciones para la configuración de actualizaciones de aumento

Ten en cuenta la siguiente información antes de configurar los parámetros de configuración de la actualización de aumento:

  • Los nodos que crea la actualización de aumento están sujetos a tus Google Cloud cuotas de recursos, disponibilidad de recursos y capacidad de reserva, para grupos de nodos con afinidad de reserva específica. Si tu entorno tiene recursos limitados, consulta Actualiza en un entorno con recursos restringidos.
  • La cantidad de nodos que GKE actualiza de forma simultánea es la suma de maxSurge y maxUnavailable. La cantidad máxima de nodos actualizados de forma simultánea es 20. Las actualizaciones de aumento también funcionan con el escalador automático del clúster para evitar que se realicen cambios en los nodos que se están actualizando.
  • GKE actualiza los grupos de nodos multizonales una zona a la vez. Los parámetros de actualización de aumento solo se aplican hasta la cantidad de nodos que hay en la zona. La cantidad máxima de nodos que se pueden actualizar en paralelo no será mayor que la suma de maxSurge más maxUnavailable ni mayor que la cantidad de nodos de la zona.
  • Si tu grupo de nodos usa VMs Spot, GKE crea nodos de aumento con VMs Spot, pero no espera a que las VMs Spot estén listas antes de acordonar y desviar los nodos existentes. Para obtener más información, consulta Actualiza grupos de nodos Standard con VMs Spot.

Ajusta la configuración de actualización de aumento para equilibrar la velocidad y la interrupción

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

Descripción Configuración Caso de uso típico
Equilibrado (predeterminado), más lento, pero con interrupciones mínimas maxSurge=1 maxUnavailable=0 La mayoría de las cargas de trabajo
Rápido, sin recursos de aumento, interrupciones máximas maxSurge=0 maxUnavailable=20 Grupos de nodos grandes después de que los trabajos deben ejecutarse hasta completarse
Rápido, con la mayoría de los recursos de aumento y menos interrupciones maxSurge=20 maxUnavailable=0 Grupos de nodos grandes
El más lento, con interrupciones y sin recursos de aumento maxSurge=0 maxUnavailable=1 Grupo de nodos con recursos limitados y reserva

Equilibrado (predeterminado)

La forma más sencilla de aprovechar las actualizaciones de aumento es usar la configuración predeterminada, maxSurge=1;maxUnavailable=0.. Con esta configuración, las actualizaciones avanzan lentamente, con solo un nodo de aumento agregado a la vez, lo que significa que solo se actualiza un nodo a la vez. Los Pods pueden reiniciarse de inmediato en el nodo de aumento nuevo. Esta configuración solo requiere los recursos para crear de forma temporal un nodo nuevo.

Rápido sin recursos de aumento

Si tienes un grupo de nodos grande y tu carga de trabajo no es sensible a la interrupción (por ejemplo, un trabajo por lotes que se ejecutó hasta completarse), usa la siguiente configuración para maximizar la velocidad sin usar ningún recurso adicional:maxSurge=0;maxUnavailable=20. Esta configuración no genera nodos de aumento adicionales y permite que se actualicen 20 nodos al mismo tiempo.

Rápido con menos interrupciones

Si tu carga de trabajo es sensible a las interrupciones, ya configuraste PodDisruptionBudgets (PDB) y no usas externalTrafficPolicy: Local, que no funciona con desvíos de nodos paralelos, puedes aumentar la velocidad de la actualización mediante maxSurge=20;maxUnavailable=0. Esta configuración actualiza 20 nodos en paralelo, mientras que el PDB limita la cantidad de pods que se pueden desviar a la vez. Aunque las configuraciones de los PDB pueden variar, si creas un PDB con maxUnavailable=1 para una o más de las cargas de trabajo que se ejecutan en el grupo de nodos, solo se puede expulsar un pod de esas cargas de trabajo a la vez, lo que limita el paralelismo de toda la actualización. Esta configuración requiere los recursos para crear de forma temporal 20 nodos nuevos.

Lento, pero sin recursos de aumento

Si no puedes usar recursos adicionales, puedes usar maxSurge=0;maxUnavailable=1 para recrear un nodo a la vez.

Controla una actualización de aumento en progreso

Con las actualizaciones de aumento, mientras una actualización está en curso, puedes usar comandos para ejercer cierto control sobre ella. Para obtener más control sobre el proceso de actualización, recomendamos usar actualizaciones azul-verde.

Cancela (pausa) una actualización de aumento

Puedes cancelar una actualización de aumento en curso en cualquier momento durante el proceso de actualización. La cancelación detiene la actualización, lo que evita que GKE actualice nodos nuevos, pero no revierte de forma automática la actualización de los nodos ya actualizados. Después de cancelar una actualización, puedes reanudarla o revertirla.

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

  • Los nodos que comenzaron la actualización la completan.
  • Los nodos que no comenzaron la actualización no se actualizan.
  • Los nodos que ya completaron de forma correcta la actualización no se ven afectados y no se revierten.

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

Obtén más información sobre cómo cancelar una actualización de grupo de nodos.

Reanuda una actualización de aumento

Si una actualización del grupo de nodos se canceló y se actualizó parcialmente, puedes reanudar la actualización para completar el proceso de actualización del grupo de nodos. Esto actualizará los nodos restantes que no se actualizaron en la operación original. Obtén más información sobre cómo reanudar una actualización de grupo de nodos.

Revierte una actualización de aumento

Si un grupo de nodos se actualiza de forma parcial, puedes revertirlo para volver a su estado anterior. No puedes revertir los grupos de nodos una vez que se actualizaron correctamente. Los nodos que no comenzaron la actualización no se ven afectados. Obtén más información sobre cómo revertir una actualización de grupo de nodos.

Si quieres cambiar un grupo de nodos a una versión anterior después de que se complete la actualización, consulta Cambia a una versión inferior de grupos de nodos.

Actualizaciones azules y verdes

Las actualizaciones azul-verde son una estrategia de actualización alternativa a la estrategia predeterminada de actualización de aumento. Con las actualizaciones azul-verde, GKE primero crea un nuevo conjunto de recursos de nodos (nodos “verdes”) con la configuración de nodo nueva antes de expulsar cualquier carga de trabajo en los recursos originales (“nodos azules”). Si es necesario, GKE conserva los recursos “azules” para revertir las cargas de trabajo hasta que se cumpla su tiempo de inactividad. Puedes ajustar el ritmo de las actualizaciones y el tiempo de inactividad según las necesidades de tu entorno.

Con esta estrategia, tienes más control sobre el proceso de actualización. Puedes revertir una actualización en curso, si es necesario, ya que se mantiene el entorno original durante la actualización. Sin embargo, esta estrategia de actualización también requiere más recursos. A medida que 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 con alta disponibilidad que necesitas poder revertir rápido en caso de que la carga de trabajo no tolere la actualización, y puedes aceptar un aumento de costo temporal, recomendamos elegir las actualizaciones azul-verde para tus grupos de nodos.

Las actualizaciones azul-verde son óptimas para las siguientes situaciones:

  • Si deseas un lanzamiento gradual en el que la mitigación de riesgos es más importante, en las que se necesita una finalización ordenada superior a 60 minutos.
  • si tus cargas de trabajo son menos tolerantes a las interrupciones.
  • si es aceptable un aumento temporal de los costos debido a un mayor uso de recursos.

Las actualizaciones azul-verde continúan hasta que se completan, incluso si superan un período de mantenimiento. Para obtener más información, consulta Cómo funcionan las estrategias de actualización de nodos con los períodos de mantenimiento.

Cuándo GKE usa actualizaciones azul-verde

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

Las actualizaciones de aumento 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 aumento.

Fases de las actualizaciones azul-verde

Con las actualizaciones azul-verde, puedes personalizar y controlar el proceso de la siguiente manera:

En esta sección, se explican las fases del proceso de actualización. Puedes usar la configuración de la actualización para ajustar el funcionamiento de las fases y los comandos a fin de controlar el proceso de actualización.

Fase 1: Crea el grupo verde

En esta fase, se crea un conjunto nuevo de grupos de instancias administrado (MIG) conocidos como el grupo “verde” para cada zona del grupo de destino con la configuración de nodo nueva (nueva versión o tipo de imagen).

Se verificará la cuota antes de comenzar a aprovisionar nuevos recursos verdes.

En esta fase, el escalador automático del clúster de los MIG originales, conocidos como el grupo azul, dejará de aumentar y reducir la escala verticalmente. El grupo verde solo puede escalar verticalmente en esta fase.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se detiene en su fase actual. Después de cancelarla, puedes reanudarla o revertirla. En esta fase, la reversión borrará el grupo verde.

Fase 2: Acordona el grupo azul

En esta fase, todos los nodos originales del grupo azul (MIG existentes) se acordonarán (marcados como no programables). Las cargas de trabajo existentes seguirán ejecutándose, pero no se programarán cargas de trabajo nuevas en los nodos existentes.

En esta fase, puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se detiene en su fase actual. Después de cancelarla, puedes reanudarla o revertirla. En esta fase, la reversión desacordonará el grupo azul y borrará el grupo verde.

Fase 3: Vacía el grupo azul

En esta fase, los nodos originales del grupo azul (MIG existentes) se vaciarán en lotes. Cuando Kubernetes desvía un nodo, las solicitudes de expulsión se envían a todos los Pods que se ejecutan en el nodo. Se reprogramarán los Pods. En el caso de los Pods que tienen infracciones de PodDisruptionBudget o terminationGracePeriodSeconds largos durante el vaciado, se borrarán en la fase Borra el grupo azul cuando se borre el nodo. Puedes usar BATCH_SOAK_DURATION y NODE_POOL_SOAK_DURATION, que se describen aquí y en la siguiente sección, para extender el período antes de que se borren los Pods.

Puedes controlar el tamaño de los lotes con cualquiera de las siguientes opciones de configuración:

  • BATCH_NODE_COUNT: la cantidad absoluta de nodos que se vaciarán en un lote.
  • BATCH_PERCENT: el porcentaje de nodos que se vaciarán en un lote, expresado como un decimal entre 0 y 1, incluidos ambos números. GKE se redondea hacia abajo al porcentaje de nodos más cercano, a un valor mínimo de 1 nodo, si el porcentaje no es una cantidad entera de nodos.

Si alguna de estas opciones de configuración se establece en cero, GKE omite esta fase y continúa con la fase de grupo de nodos de prueba.

Además, puedes controlar cuánto tiempo se vacía cada lote en prueba con BATCH_SOAK_DURATION. Esta duración se define en segundos y el valor predeterminado es cero segundos.

En esta fase, aún puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se detiene en su fase actual. Después de cancelarla, puedes reanudarla o revertirla. Si el lote anterior ya se agotó y reanudas la actualización, es posible que el siguiente lote de nodos se procese de inmediato sin respetar el valor de BATCH_SOAK_DURATION para ese lote. La reversión en esta fase detiene el drenado del grupo azul y anula su acordonamiento. Luego, las cargas de trabajo se pueden reprogramar en el grupo azul (no garantizado) y el grupo verde se drena y se borra.

Fase 4: Prueba el grupos de nodos

Esta fase se usa para que verifiques el estado de la carga de trabajo después de que se vacíen los nodos del grupo azul.

El tiempo de prueba se establece con NODE_POOL_SOAK_DURATION, en segundos Se configura de manera predeterminada en una hora (3600 segundos). Si la duración total del tiempo de prueba alcanza 7 días (604,800 segundos), la fase de eliminación del grupo azul comienza de inmediato.

La duración total de la saturación es la suma de NODE_POOL_SOAK_DURATION, más BATCH_SOAK_DURATION multiplicado por la cantidad de lotes, que se determina con BATCH_NODE_COUNT o BATCH_PERCENT.

En esta fase, puedes finalizar la actualización y omitir cualquier tiempo de prueba restante si completas la actualización. Esto comenzará de inmediato el proceso de eliminación de los nodos del grupo azul.

Aún puedes cancelar la actualización si es necesario. Cuando cancelas una actualización azul-verde, esta se detiene en su fase actual. Después de cancelarla, puedes reanudarla o revertirla.

En esta fase, el escalador automático del clúster ahora puede aumentar o reducir la escala del grupo verde como de costumbre.

Fase 5: Borra el grupo azul

Después de la fecha de vencimiento, los nodos del grupo azul se quitarán del grupo de destino. No se puede pausar esta fase. Además, esta fase no usa el desalojo y, en cambio, intenta borrar los Pods. A diferencia del desalojo, el borrado no respeta los PDB y borra los Pods de forma forzada. La eliminación limita el terminationGracePeriodSeconds de un Pod a no más de 60 minutos. Después de este último intento de borrar los Pods restantes, se borran los nodos del grupo azul 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 el escalador automático del clúster con actualizaciones azul-verde

Durante las fases de una actualización azul-verde, el grupo “azul” original no aumenta ni reduce la escala. Cuando se crea el grupo “verde” nuevo, solo se puede escalar verticalmente hasta la fase de grupo de nodos de prueba, en la que se puede aumentar o reducir la escala. Si una actualización se revierte, el grupo “azul” original puede escalar verticalmente durante este proceso si se necesita capacidad adicional.

Controla una actualización azul-verde en curso

Con las actualizaciones azul-verde, mientras una actualización está en curso, puedes usar los comandos para controlarla. Esto te brinda un alto nivel de control sobre el proceso en caso de que determines, por ejemplo, que tus cargas de trabajo deben revertirse a la configuración anterior del nodo.

Cancela (pausa) una actualización azul-verde

Cuando cancelas una actualización azul-verde, debes pausar la actualización en su fase actual. Este comando se puede usar en todas las fases, excepto la eliminación de la fase azul del grupo. Cuando se cancele, el grupo de nodos se pausará en un estado intermedio según la fase en la que se emitió la solicitud.

Obtén más información sobre cómo cancelar una actualización de grupo de nodos.

Después de cancelar una actualización, puedes elegir uno de los dos caminos a seguir: reanudar o revertir.

Reanuda una actualización azul-verde

Si determinaste que la actualización está en condiciones de continuar, puedes reanudarla.

Si la reanudas, el proceso de actualización continuará en la fase intermedia en la que se detuvo. Si quieres aprender a reanudar una actualización de grupo de nodos, consulta Reanuda una actualización de grupo de nodos.

Revierte una actualización azul-verde

Si determinaste que la actualización no debe avanzar y deseas que el grupo de nodos vuelva a su estado original, puedes revertir. Si quieres aprender a revertir una actualización de grupo de nodos, consulta Revierte una actualización de grupo de nodos.

Con el flujo de trabajo de reversión, el proceso se revierte a sí mismo para devolver el grupo de nodos a su estado original. El grupo azul se desacordonará para que las cargas de trabajo se puedan reprogramar en él. Durante este proceso, el escalador automático del clúster puede escalar verticalmente el grupo azul según sea necesario. El grupo verde se vaciará y se borrará.

Si quieres cambiar un grupo de nodos a una versión anterior después de que se complete la actualización, consulta Cambia a una versión inferior de grupos de nodos.

Completa una actualización azul-verde

Durante la fase de prueba, puedes completar una actualización si determinaste que la carga de trabajo no necesita validación adicional en la configuración del nodo nuevo y se pueden quitar los nodos antiguos. Si completas una actualización, se omite el resto de la fase de prueba y se continúa con la fase de eliminación del grupo azul.

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

Actualizaciones azul-verde con ajuste de escala automática

Las actualizaciones azul-verde con ajuste de escala automático son un tipo diferente de estrategia de actualización que maximiza la cantidad de tiempo antes de que se expulsen las cargas de trabajo intolerantes a las interrupciones y, al mismo tiempo, minimiza los costos. Esta estrategia se deriva de las actualizaciones azul-verde estándar. Sin embargo, con las actualizaciones azul-verde con ajuste de escala automático, GKE no desvía los nodos con cargas de trabajo marcadas como no seguras para expulsar durante un máximo de siete días después de que los nodos se acordonen.

En la siguiente sección, se explica cuándo debes elegir esta estrategia, cómo la implementación de las actualizaciones azul-verde de esta estrategia difiere de las actualizaciones azul-verde estándar y qué prácticas recomendadas debes seguir cuando uses esta estrategia.

Para usar las actualizaciones azul-verde con ajuste de escala automático, consulta Configura actualizaciones azul-verde con ajuste de escala automático.

Cuándo elegir actualizaciones azul-verde con ajuste de escala automática para tu entorno

Si tienes cargas de trabajo que necesitan la mayor cantidad de tiempo antes de expulsión, pero no necesitan reprogramarse lo más rápido posible, recomendamos elegir las actualizaciones azul-verde con ajuste de escala automática para tus grupos de nodos.

Las actualizaciones azul-verde con ajuste de escala automática funcionan bien si se aplican los siguientes casos:

  • Tienes cargas de trabajo por lotes (incluido el entrenamiento de IA/AA) que deben ejecutarse hasta completarse.
  • Deseas minimizar el costo en comparación con las actualizaciones estándar azul-verde, para lo cual minimizas la cantidad de nodos inactivos o con poco uso.
  • No necesitas Pods para garantizar una reprogramación inmediata o una reversión inmediata a la configuración anterior del nodo.

Elige actualizaciones azul-verde estándar si necesitas minimizar el tiempo de reprogramar cargas de trabajo en nodos nuevos y la capacidad de revertir a la configuración de nodo anterior.

Las actualizaciones azul-verde con ajuste de escala automática, al igual que las actualizaciones azul-verde estándar, continúan hasta completarse si superan un período de mantenimiento. Para obtener más información, consulta Cómo funcionan las estrategias de actualización de nodos con los períodos de mantenimiento.

Fases de actualizaciones azul-verde con ajuste de escala automática

Cuando GKE actualiza los grupos de nodos con actualizaciones azul-verde con ajuste de escala automática, las fases difieren de las actualizaciones azul-verde estándar. Para conocer 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 ajuste de escala automática, GKE realiza estos pasos durante una operación:

  1. GKE crea el grupo verde. Sin embargo, el grupo verde comienza sin nodos. Cuando GKE expulse Pods del grupo azul en una fase posterior, el escalador automático de clústeres escalará el grupo verde para ejecutar esos Pods.
  2. GKE acordona el grupo azul.

  3. GKE espera un período, que puedes configurar de cero a siete días (con un valor predeterminado de tres días). Durante este tiempo, GKE hace lo siguiente:

  4. GKE vacía el grupo azul y vacía los nodos restantes del grupo azul hasta 20 a la vez en paralelo. GKE respeta la configuración de PodDisruptionBudget durante un máximo de 1 hora y la configuración de terminationGracePeriodSeconds durante un máximo de 24 horas.

  5. GKE omite la fase de grupo de nodos de prueba.

  6. GKE borra el grupo azul.

Prácticas recomendadas para las actualizaciones azul-verde con ajuste de escala automática

En las siguientes secciones, se proporcionan prácticas recomendadas para el clúster, el grupo de nodos y los Pods, con el objetivo de minimizar las interrupciones de la carga de trabajo durante las actualizaciones azul-verde con ajuste de escala automático.

Configuración del clúster y del grupo de nodos

  • GKE respeta los límites del ajuste de escala automático cuando se escala verticalmente el grupo verde. Establece los parámetros --max-nodes o --total-max-nodes lo suficientemente altos como para que el escalador automático del clúster pueda escalar verticalmente el grupo verde cuando GKE reprograma las cargas de trabajo del grupo azul al grupo verde. GKE no respeta los parámetros --min-nodes ni --total-min-nodes cuando reduce la escala del grupo azul.
  • Configura el perfil de ajuste de escala automático optimize-utilization si quieres que GKE reduzca la escala de los nodos subutilizados en el grupo azul de forma más agresiva. Para obtener más información, consulta Perfiles de ajuste de escala automático.
  • No actualices los grupos de nodos creados con el aprovisionamiento automático de nodos para usar actualizaciones azul-verde con ajuste de escala automática. Además, no configures tu clúster para que use actualizaciones azul-verde con ajuste de escala automática para grupos de nodos nuevos aprovisionados de forma automática.

Configuración del pod

  • Para asegurarte de que los Pods no se expulsen durante la pausa antes de vaciar el grupo azul, agrega la anotación "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a esos Pods. Esta anotación evita que el escalador automático del clúster expulse el Pod si el nodo del Pod no se usa lo suficiente.
  • Al igual que con las actualizaciones azul-verde estándar, para garantizar que los Pods expulsados de los nodos del grupo azul solo se reprogramen en los nodos del grupo verde, agrega un nodeSelector para la etiqueta cloud.google.com/gke-nodepool:NODE_POOL_NAME a tu carga de trabajo. Si omites esta etiqueta y tienes otros grupos de nodos en tu clúster, es posible que los Pods expulsados se programen en los nodos de esos otros grupos de nodos.

Limitaciones de las actualizaciones azul-verde con ajuste de escala automática

  • Puedes cancelar y reanudar las actualizaciones azul-verde con ajuste de escala automático; sin embargo, no puedes revertir la actualización cancelada.
  • Cuando se aísla y vacía el grupo azul, los Pods pueden volverse no programables de forma temporal si el escalador automático del clúster no puede escalar verticalmente el grupo verde debido a las cuotas y límites o la disponibilidad de recursos porque el grupo verde se crea sin nodos.
  • Solo puedes actualizar grupos de nodos con actualizaciones azul-verde con ajuste de escala 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 del clúster está habilitado.

Cuándo GKE usa actualizaciones azul-verde con ajuste de escala automática

GKE usa actualizaciones azul-verde con ajuste de escala automática 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 GKE usa actualizaciones azul-verde.

Cómo funciona el escalador automático del clúster con actualizaciones azul-verde de escala automática

Para configurar las actualizaciones azul-verde con ajuste de escala automática, también debes configurar el escalador automático del clúster.

Si usas actualizaciones azul-verde con ajuste de escala automática, el escalador automático de clústeres hace lo siguiente:

  • Durante la fase en la que GKE espera para drenar el grupo azul, este no se escala verticalmente y solo se reduce su escala con el escalador automático de clústeres cuando los nodos se subutilizan. El escalador automático de clústeres puede reducir la escala del grupo azul a cero, sin respetar los parámetros --min-nodes o --total-min-nodes. En todas las demás fases, el escalador automático del clúster no aumenta ni reduce la escala del grupo azul.
  • El escalador automático del clúster aumenta la escala del grupo verde desde cero nodos o la reduce hasta el parámetro de configuración --min-nodes, según sea necesario en todas las fases de la estrategia de actualización.

Actualizaciones de corta duración (solo para aprovisionamiento de inicio flexible y en cola)

Las actualizaciones de corta duración son una estrategia de actualización de nodos que se usa exclusivamente con nodos que utilizan VMs de inicio flexible y nodos que utilizan el aprovisionamiento en cola (con la versión 1.32.2-gke.1652000 o posterior), ambos con la tecnología del programador dinámico de cargas de trabajo. Para obtener más información sobre los nodos que usan actualizaciones de corta duración, consulta Acerca de la disponibilidad de GPU con el Programador dinámico de cargas de trabajo.

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

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

  1. Los nodos existentes se ejecutan hasta que se interrumpen.
  2. Los nodos nuevos usan la nueva configuración de nodos.
  3. En un máximo de siete días, los nodos realizan la transición de ejecutar la configuración existente a ejecutar la nueva.

GKE configura automáticamente esta estrategia para los nodos que usan VMs de inicio flexible. Esta estrategia no tiene parámetros de configuración.

Cuándo GKE usa actualizaciones de corta duración

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

En el caso de los grupos de nodos Estándar y los grupos de nodos en clústeres de Autopilot que usan actualizaciones de corta duración, GKE usa 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 manera similar a cómo se usan las actualizaciones de aumento. Para obtener más información, consulta Cuándo se usan las actualizaciones de aumento.

¿Qué sigue?