En este documento, se proporciona una breve descripción general de las actualizaciones progresivas estándar y, luego, se detallan las actualizaciones de aumento, que son un tipo especial de actualización progresiva. En comparación con las actualizaciones progresivas estándar, las actualizaciones de aumento te permiten configurar la velocidad de la actualización. Las actualizaciones de aumento también te permiten tener cierto control sobre qué tan perjudiciales son las actualizaciones para tus cargas de trabajo.
A fin de obtener información sobre cómo habilitar y configurar las actualizaciones de aumento para GKE en AWS, consulta Configura actualizaciones de aumento de grupos de nodos.
Cómo funcionan las actualizaciones progresivas estándar
Algunas actualizaciones de un grupo de nodos, como cuando modificas las anotaciones de un grupo de nodos, no requieren el reinicio de los nodos y, por lo tanto, no generan una actualización progresiva. Si GKE en AWS puede aplicar cambios a un grupo de nodos sin tener que reiniciar o volver a crear recursos, lo hará para evitar interrupciones.
Sin embargo, la mayoría de las actualizaciones de un grupo de nodos en GKE en AWS suelen implicar la finalización de los nodos existentes y el inicio de nodos nuevos con la configuración actualizada. El proceso de finalización de nodos existentes puede interrumpir las cargas de trabajo.
De forma predeterminada, GKE en AWS realiza actualizaciones progresivas estándar. Este método actualiza los nodos de a uno y se reemplazan por un enfoque “finalizar antes de crear”: un nodo finaliza primero y, luego, se inicia un nodo nuevo actualizado. Esto minimiza la interrupción porque solo un nodo se finaliza y se reemplaza en cualquier momento determinado.
Estos son los pasos que sigue GKE en AWS durante una actualización progresiva estándar:
- Selecciona un nodo del grupo de nodos y lo marca como no disponible para garantizar que no se inicien Pods nuevos en él. Esta acción se llama acordonamiento.
- Reubica los Pods activos del nodo acordonado a otros nodos disponibles dentro del clúster. Si otros nodos tienen capacidad suficiente, admiten los Pods expulsados. De lo contrario, el escalador automático del clúster, que permanece activo durante una actualización progresiva estándar, inicia un escalamiento vertical y aprovisiona nodos adicionales a fin de garantizar que haya suficiente capacidad para programar los Pods expulsados. Si deseas obtener información sobre las medidas que se tomaron para proteger las cargas de trabajo durante este proceso, consulta Protección de cargas de trabajo durante el cambio de tamaño.
- Finaliza el nodo acordonado.
- Sustituye el nodo acordonado por uno nuevo con la configuración actualizada.
- Realiza una verificación de estado en el nodo recién operativo. Si el grupo de nodos falla la verificación de estado, se marca con un estado
DEGRADED
. Este estado se puede ver mediante la ejecución del comandogcloud container aws node-pools describe
. Cuando un grupo de nodos se marca comoDEGRADED
, es posible que no se programen Pods nuevos en los nodos dentro de ese grupo. - Continúa con la actualización, nodo por nodo, hasta que todos los nodos del grupo se hayan actualizado.
Cómo funcionan las actualizaciones de aumento
En GKE en AWS, el método progresivo estándar actualiza los nodos de a uno. Las actualizaciones de aumento, que son una forma de actualización progresiva, te permiten actualizar varios nodos de forma simultánea. Por lo tanto, las actualizaciones de aumento son más rápidas que las actualizaciones progresivas estándar. Sin embargo, actualizar varios nodos de forma simultánea puede interrumpir las cargas de trabajo. A fin de mitigar esto, las actualizaciones de aumento proporcionan opciones para modificar el nivel de interrupción en las cargas de trabajo.
Otra forma en que las actualizaciones de aumento pueden diferir de las actualizaciones progresivas estándar es la forma en que se reemplazan los nodos. Las actualizaciones progresivas estándar reemplazan a los nodos mediante una estrategia “finalizar antes de crear”. Según la configuración que elijas, las actualizaciones de aumento pueden usar una estrategia “crear antes de finalizar”, una estrategia “finalizar antes de crear” o incluso una combinación de ambas.
El escalador automático del clúster cumple una función más importante en las actualizaciones de aumento que en las actualizaciones progresivas estándar, por lo que figura de forma destacada en la siguiente lista de acciones que GKE en AWS realiza durante una actualización de aumento:
- Creación de un nuevo grupo de ajuste de escala automático: GKE en AWS aprovisiona nodos nuevos con las modificaciones especificadas por el comando update y asigna estos nodos nuevos a un nuevo grupo de ajuste de escala automático (ASG) de AWS.
- Comportamiento del escalador automático del clúster: Cuando comienza la actualización de aumento, el escalador automático del clúster se activa para el grupo de ajuste de escala automático nuevo. El escalador automático del clúster para el grupo de ajuste de escala automático original está desactivado. Esto garantiza que cualquier operación de escalamiento se oriente solo al grupo nuevo.
- Reemplazo de nodos: según los parámetros de actualización de aumento, se usan diferentes estrategias para el reemplazo de nodos:
- “crear antes de finalizar”: esta estrategia se activa cuando el parámetro
max-surge-update
se establece en un valor mayor que cero. Genera nodos nuevos en el ASG nuevo antes de finalizar los antiguos en el ASG original, con el objetivo de minimizar las interrupciones del servicio. - “finalizar antes de crear”: este método se activa cuando el parámetro
max-surge-update
se establece en cero y el parámetromax-unavailable-update
tiene un valor mayor que cero. Los nodos del ASG original se finalizan primero, seguidos de la creación de nuevos en el ASG nuevo.
- “crear antes de finalizar”: esta estrategia se activa cuando el parámetro
- Ajustes de tamaño del grupo de nodos: durante la actualización, el tamaño del grupo de nodos (es decir, la suma de nodos en el ASG anterior y nuevo) puede fluctuar por encima o por debajo del recuento original de nodos presentes en el grupo de nodos antes de que comenzara la actualización. En particular, GKE en AWS tiene como objetivo mantener el recuento total de nodos dentro del rango de (
original_count
-max-unavailable-update
) a (original_count
+max-surge-update
). Finalmente, los nodos del ASG antiguo (original_count
) se reemplazan por nodos actualizados en el ASG nuevo. El escalador automático del clúster puede iniciar más nodos en el ASG nuevo si detecta que no se pueden programar los Pods, pero permanece dentro de los límites definidos pormin-nodes
ymax-nodes
.
Un ejemplo que ilustra el proceso
Para comprender mejor cómo funcionan las actualizaciones de aumento, considera el siguiente ejemplo. Supongamos que tienes un grupo de nodos con 5 nodos y ejecutas el siguiente comando:
gcloud container aws node-pools update production-node-pool
--cluster my-cluster \
--location us-west1 \
--max-surge-update 2 \
--max-unavailable-update 1 \
--node-version 1.27.6-gke.700
En este ejemplo, max-surge-update
se configura como 2, max-unavailable-update
se configura como 1 y proporcionas una versión nueva del grupo de nodos (es decir, cambias la versión de GKE que se ejecuta en los nodos del grupo de nodos).
Cuando se ejecuta este comando, se activa una actualización de aumento, y GKE en AWS realiza las siguientes acciones:
- Crea 2 nodos adicionales porque el valor de
max-surge-update
es igual a 2. - Asigna estos 2 nodos adicionales a un nuevo grupo de ajuste de escala automático de AWS.
- Quita los nodos del grupo de ajuste de escala automático original una vez que estos nodos nuevos están en funcionamiento. GKE en AWS desactiva hasta 3 nodos (el valor combinado de
max-surge-update
ymax-unavailable-update
), pero garantiza que, como máximo, un nodo deje de estar disponible en cualquier momento (debido al valor demax-unavailable-update
de 1). - Repite estos pasos hasta que se hayan actualizado todos los nodos del grupo de nodos a la nueva versión de GKE.
Durante esta actualización, el grupo de nodos contiene entre 4 y 7 nodos operativos.
Aspectos que debes tener en cuenta antes de ejecutar actualizaciones de aumento
Antes de ejecutar una actualización de aumento, ten en cuenta lo siguiente:
- Las instancias adicionales creadas como parte de este paso de aumento pueden exceder el límite de cuota de tu instancia de AWS. Si no tienes suficiente cuota y estas instancias adicionales no se pueden aprovisionar, la actualización podría fallar.
- Si
max-unavailable-update
se configura en 0, las interrupciones en las cargas de trabajo aún pueden ocurrir a medida que los Pods se expulsan y se reprograman en los nodos más nuevos. - La cantidad máxima de nodos que se pueden actualizar de forma simultánea es igual a la suma de
max-surge-update
ymax-unavailable-update
, y se limita a 20.
Elige la configuración de aumento adecuada para tus necesidades
Si bien las actualizaciones progresivas estándar suelen usar un enfoque de “finalizar antes de crear”, las actualizaciones de aumento presentan más flexibilidad. Según la configuración, las actualizaciones de aumento pueden seguir una estrategia de “crear antes de finalizar”, una estrategia de “finalizar antes de crear” o una combinación de ambas. En esta sección, se describen diferentes opciones de configuración a fin de ayudarte a seleccionar el mejor enfoque para tus cargas de trabajo.
En la siguiente tabla, se muestran tres opciones de configuración de ejemplo y se destaca su impacto en la velocidad de la actualización y la posible interrupción en las cargas de trabajo:
Nombre | Descripción | Configuración |
Configuración equilibrada (predeterminada) | Equilibrado, más lento, pero con la menor cantidad de interrupciones. | maxSurge=1, maxUnavailable=0 |
Actualizaciones rápidas sin recursos adicionales | Rápido, sin recursos de aumento, con la mayor cantidad de interrupciones. | maxSurge=0, maxUnavailable=20 |
Actualizaciones rápidas con menos interrupciones | Rápido, con la mayoría de los recursos de aumento y menos interrupciones. | maxSurge=20, maxUnavailable=0 |
Cada una de las opciones de configuración de la tabla se describe en las siguientes secciones.
Configuración equilibrada (predeterminada)
La forma más directa de usar las actualizaciones de aumento es con la configuración predeterminada de max-surge-update=1
y max-unavailable-update=0
. Esta configuración agrega solo 1 nodo de aumento al grupo de nodos durante la actualización, y solo se actualiza 1 nodo a la vez, de acuerdo con un enfoque “crear antes de finalizar”. En comparación con la actualización progresiva estándar sin aumento, que es equivalente a (max-surge-update=0
, max-unavailable-update=1
), este método es menos perjudicial, acelera los reinicios de Pods durante las actualizaciones y es más conservador en su progreso.
Es importante tener en cuenta que adoptar la configuración equilibrada puede generar costos adicionales debido al nodo de aumento temporal que se agregó durante la actualización. Este nodo adicional genera cargos mientras está activo, lo que aumenta ligeramente el gasto general en comparación con los métodos sin nodos de aumento.
Actualizaciones rápidas sin recursos adicionales
Para las cargas de trabajo que pueden tolerar interrupciones, puede ser adecuado un enfoque de actualización más rápido. Esto se logra mediante la configuración de max-surge-update=0
y max-unavailable-update=20
. Con esta configuración, se pueden actualizar 20 nodos de forma simultánea sin agregar ningún nodo de aumento. Este método de actualización sigue un enfoque de “finalizar antes de crear”. Debido a que no se ingresan nodos de aumento adicionales durante el proceso, este método también es el más rentable, ya que evita los gastos adicionales asociados con los nodos temporales.
Actualizaciones rápidas con menos interrupciones
Si tus cargas de trabajo son sensibles a las interrupciones, puedes aumentar la velocidad de la actualización con la siguiente configuración: max-surge-update=20
y max-unavailable-update=0
. Esta configuración actualiza 20 nodos en paralelo con un enfoque de “crear antes de finalizar”.
Sin embargo, la velocidad general de la actualización puede estar limitada si configuraste PodDisruptionBudgets
(PDB) para tus cargas de trabajo. Esto se debe a que el PDB restringe la cantidad de Pods que se pueden desviar en un momento determinado. Aunque las configuraciones de los PDB pueden variar, si creas un PDB con maxUnavailable
igual a 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.
Recuerda que iniciar varios nodos de aumento al comienzo del proceso de actualización puede generar un aumento temporal de los costos, en especial en comparación con configuraciones que no agregan nodos adicionales o agregan menos nodos durante las actualizaciones.
¿Qué sigue?
A fin de obtener información sobre cómo habilitar y configurar las actualizaciones de aumento para GKE en AWS, consulta Configura actualizaciones de aumento de grupos de nodos.