Estrategias de actualización de nodos

En esta página, 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:

  • 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.

En los clústeres Autopilot, GKE usa actualizaciones de aumento. Para obtener más información, consulta la sección Actualizaciones de aumento de la página de actualizaciones del clúster de Autopilot.

Cuando eliges una estrategia de actualización para tu grupo de nodos de clúster Standard, puedes elegir el proceso con el equilibrio adecuado entre velocidad, interrupción de la carga de trabajo, mitigación de riesgos y optimización de costos. Si deseas obtener más información sobre qué estrategia de actualización de nodos es adecuada para tu entorno, consulta Elige actualizaciones de aumento y Elige actualizaciones azul-verde.

Con ambas 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, en la estrategia que elijas, tengas suficiente cuota, disponibilidad de recursos o capacidad de reserva para actualizar tus nodos mediante esa estrategia. Si deseas obtener más información, consulta Garantiza los recursos para las actualizaciones de nodos.

Actualizaciones de aumento

Las actualizaciones de aumento son la estrategia de actualización predeterminada y es 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 de aumento nuevos 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.

Elige 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 mediante la configuración maxSurge y maxUnavailable, que determina 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

Configura maxSurge para elegir la cantidad máxima de nodos de aumento adicionales 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 para hasta uno. hora.
  5. Borra el nodo existente.

Para que GKE cree nodos de aumento, tu proyecto debe tener los recursos 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 hace que un nodo existente no esté disponible para volver a crearlo

Configura 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 el nodo existente se actualice, 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.
  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, GKE libera de forma temporal la capacidad del nodo si la capacidad no es de una reserva. Esto significa que, si la capacidad es limitada, corres el riesgo de perder la capacidad existente. Por lo tanto, si tu entorno tiene recursos limitados, usa esta 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 progresiva, GKE crea dos nodos actualizados y, además, interrumpe como máximo un nodo existente. 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 la actualización de aumento

Considera la siguiente información antes de establecer la configuración de actualización de aumento:

  • Los nodos que crea la actualización de aumento están sujetos a las cuotas de recursos, disponibilidad de recursos y capacidad de reserva de Google Cloud, para grupos de nodos con afinidad de reserva específica. Si tu entorno tiene recursos limitados, consulta Actualiza en un entorno con recursos limitados.
  • 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 multizona de a una zona a la vez. Los parámetros de actualización de aumento solo se aplican hasta la cantidad de nodos de 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 mediante 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 su finalización
Rápido, con la mayoría de los recursos de aumento y menos interrupciones 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 recursos limitados con 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 progresan con lentitud, y solo se agrega un nodo de aumento a la vez, lo que significa solo uno se actualiza a la vez. Los Pods pueden reiniciarse de inmediato en el nodo de aumento nuevo. Esta configuración solo requiere que los recursos creen 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 ningún recurso adicional, puedes usar maxSurge=0;maxUnavailable=1 para volver a crear 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.

Elige 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.

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:

Se usarán las actualizaciones de aumento para cualquier otra funció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 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 al porcentaje de nodos más cercano, a un valor mínimo de 1 nodo, si el porcentaje no es una cantidad entero 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. En esta fase, la reversión detendrá el drenado del grupo azul y se anulará el acordonamiento del grupo azul. Luego, las cargas de trabajo se pueden reprogramar en el grupo azul (no garantizado) y el grupo verde se borrará.

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 del tiempo de prueba es la suma de NODE_POOL_SOAK_DURATION, más BATCH_SOAK_DURATION multiplicado por la cantidad de lotes, que se determina mediante 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 la expulsión y, en su lugar, intenta borrar los Pods. A diferencia de la expulsión, la eliminación no respeta los PDB y fuerza la eliminación de los Pods. La eliminación limita el terminationGracePeriodSeconds de un Pod a no más de 60 minutos. Después de este último intento para borrar los Pods restantes, los nodos del grupo azul se borran 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.

¿Qué sigue?