El producto descrito en esta documentación, GKE en AWS, ahora está en modo de mantenimiento y se cerrará el 17 de marzo del 2027.

Esta página se ha traducido con Cloud Translation API.

Acerca de las actualizaciones de sobreaprovisionamiento

En este documento se ofrece una breve descripción general de las actualizaciones continuas estándar y, a continuación, se explica en detalle qué son las actualizaciones de picos, que son un tipo especial de actualización continua. En comparación con las actualizaciones graduales estándar, las actualizaciones de picos te permiten configurar la velocidad de la actualización. Las actualizaciones de Surge también te permiten ejercer cierto control sobre el grado de interrupción de las actualizaciones en tus cargas de trabajo.

Para obtener información sobre cómo habilitar y configurar las actualizaciones de picos de GKE en AWS, consulta Configurar las actualizaciones de picos de los grupos de nodos.

Cómo funcionan las actualizaciones continuas estándar

Algunas actualizaciones de un grupo de nodos, como cuando modificas las anotaciones de un grupo de nodos, no requieren que se reinicien los nodos, por lo que no se produce una actualización gradual. Si GKE en AWS puede aplicar cambios a un grupo de nodos sin tener que reiniciar ni volver a crear recursos, lo hará para evitar interrupciones.

Sin embargo, la mayoría de las actualizaciones de un grupo de nodos en GKE on AWS suelen implicar la finalización de los nodos actuales y el lanzamiento de nuevos nodos con la configuración actualizada. El proceso de finalización de los nodos puede interrumpir las cargas de trabajo.

De forma predeterminada, GKE on AWS realiza actualizaciones continuas estándar. Este método actualiza los nodos de uno en uno y los sustituye mediante un enfoque de "finalizar antes de crear": primero se finaliza un nodo y, a continuación, se inicia un nodo actualizado. De esta forma, se minimizan las interrupciones, ya que solo se termina y se sustituye un nodo en un momento dado.

Estos son los pasos que sigue GKE on AWS durante una actualización continua estándar:

Selecciona un nodo del grupo de nodos y lo marca como no disponible para asegurarse de que no se inicie ningún Pod nuevo en él. Esta acción se denomina cordoning (aislamiento).
Reubica los pods activos del nodo acordonado en otros nodos disponibles del clúster. Si otros nodos tienen capacidad suficiente, podrán alojar los pods desalojados. De lo contrario, el escalador automático de clústeres, que permanece activo durante una actualización gradual estándar, inicia un escalado vertical y aprovisiona nodos adicionales para asegurarse de que haya capacidad suficiente para programar los pods desalojados. Para obtener información sobre las medidas que se toman 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 los ajustes actualizados.
Realiza una comprobación del estado del nodo que acaba de ponerse en funcionamiento. Si el grupo de nodos no supera la comprobación del estado, se marca con el estado DEGRADED. Para ver este estado, ejecuta el comando gcloud container aws node-pools describe. Cuando un grupo de nodos se marca como DEGRADED, es posible que no se programen nuevos pods en los nodos de ese grupo.
Continúa actualizando los nodos uno a uno hasta que se hayan actualizado todos los nodos del grupo.

Cómo funcionan las actualizaciones de subidas

En GKE en AWS, el método de actualización progresiva estándar actualiza los nodos de uno en uno. Las actualizaciones de picos, que son un tipo de actualización progresiva, te permiten actualizar varios nodos simultáneamente. Por lo tanto, las actualizaciones de picos son más rápidas que las actualizaciones continuas estándar. Sin embargo, actualizar varios nodos simultáneamente puede interrumpir las cargas de trabajo. Para mitigar este problema, las actualizaciones de picos proporcionan opciones para modular el nivel de interrupción de tus cargas de trabajo.

Otra diferencia entre las actualizaciones de picos y las actualizaciones continuas estándar es la forma en que se sustituyen los nodos. Las actualizaciones continuas estándar sustituyen los nodos mediante una estrategia de "finalizar antes de crear". En función de los ajustes que elijas, las actualizaciones de picos pueden usar una estrategia de "crear antes de finalizar", una estrategia de "finalizar antes de crear" o incluso una combinación de ambas.

El escalador automático de clústeres desempeña un papel más importante en las actualizaciones de picos que en las actualizaciones continuas estándar, por lo que ocupa un lugar destacado en la siguiente lista de acciones que lleva a cabo GKE en AWS durante una actualización de picos:

Creación de un nuevo grupo de escalado automático: GKE on AWS aprovisiona nuevos nodos con las modificaciones especificadas en el comando de actualización y asigna estos nuevos nodos a un nuevo grupo de escalado automático (ASG) de AWS.
Comportamiento de la herramienta de adaptación dinámica de clústeres: cuando empieza la actualización de picos, se activa la herramienta de adaptación dinámica de clústeres para el nuevo grupo de escalado automático. El escalador automático del clúster del grupo de escalado automático original se desactiva. De esta forma, te aseguras de que las operaciones de escalado solo se dirijan al nuevo grupo.
Sustitución de nodos: en función de los parámetros de actualización de la oleada, se utilizan diferentes estrategias para sustituir los nodos:
- "create before terminate": esta estrategia se activa cuando el parámetro max-surge-update se define en un valor superior a cero. Crea nodos en el nuevo ASG antes de finalizar los antiguos en el ASG original para minimizar las interrupciones del servicio.
- "terminate before create": este método se activa cuando el parámetro max-surge-update se establece en cero y el parámetro max-unavailable-update tiene un valor superior a cero. Primero se terminan los nodos del ASG original y, a continuación, se crean los nodos del nuevo ASG.
Ajustes del tamaño del grupo de nodos: durante la actualización, el tamaño del grupo de nodos (es decir, la suma de los nodos del ASG antiguo y del nuevo) puede fluctuar por encima o por debajo del número original de nodos presentes en el grupo de nodos antes de que se iniciara la actualización. En concreto, GKE en AWS tiene como objetivo mantener el número total de nodos dentro del intervalo (original_count - max-unavailable-update) a (original_count + max-surge-update). Finalmente, los nodos del ASG antiguo (original_count) se sustituyen por nodos actualizados en el nuevo ASG. La herramienta de ajuste automático de escala del clúster puede iniciar más nodos en el nuevo ASG si detecta que no se pueden programar pods, pero se mantiene dentro de los límites definidos por min-nodes y max-nodes.

Ejemplo para ilustrar el proceso

Para entender mejor cómo funcionan las actualizaciones de subida, consulta 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 define como 2, max-unavailable-update se define como 1 y se proporciona una nueva versión del grupo de nodos (es decir, se cambia la versión de GKE que se ejecuta en los nodos del grupo de nodos).

Al ejecutar este comando, se activa una actualización de aumento y GKE on AWS realiza las siguientes acciones:

Crea dos nodos adicionales porque el valor de max-surge-update es 2.
Asigna estos dos nodos adicionales a un nuevo grupo de escalado automático de AWS.
Quita nodos del grupo de escalado automático original una vez que estos nuevos nodos estén operativos. GKE on AWS reduce hasta 3 nodos (el valor combinado de max-surge-update y max-unavailable-update), pero se asegura de que, como máximo, solo un nodo no esté disponible en un momento dado (debido al valor max-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.

Cosas que debes tener en cuenta antes de ejecutar actualizaciones de picos

Antes de ejecutar una actualización de subida, ten en cuenta lo siguiente:

Las instancias adicionales creadas como parte de este paso de aumento pueden superar el límite de cuota de instancias de AWS. Si no tienes suficiente cuota y no se pueden aprovisionar estas instancias adicionales, es posible que la actualización falle.
Si max-unavailable-update se define como 0, las cargas de trabajo pueden seguir sufriendo interrupciones a medida que se desalojan los pods y se reprograman en los nodos más recientes.
El número máximo de nodos que se pueden actualizar simultáneamente es igual a la suma de max-surge-update y max-unavailable-update, y está limitado a 20.

Elige la configuración de aumento adecuada para tus necesidades

Mientras que las actualizaciones continuas estándar suelen usar un enfoque de "finalizar antes de crear", las actualizaciones de picos introducen más flexibilidad. En función de la configuración, las actualizaciones de picos 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 configuraciones para ayudarte a seleccionar el mejor enfoque para tus cargas de trabajo.

En la siguiente tabla se muestran tres ejemplos de ajustes y se destaca su impacto en la velocidad de la actualización y en las posibles interrupciones de tus cargas de trabajo:

Nombre	Descripción	Configuración
Ajuste Equilibrado (predeterminado)	Equilibrado, más lento, pero menos disruptivo.	maxSurge=1, maxUnavailable=0
Actualizaciones rápidas sin recursos adicionales	Rápido, sin recursos de aumento, el más disruptivo.	maxSurge=0, maxUnavailable=20
Actualizaciones rápidas y menos disruptivas	Rápido, con la mayoría de los recursos de aumento y menos disruptivo.	maxSurge=20, maxUnavailable=0

Cada uno de los ajustes de la tabla se describe en las siguientes secciones.

Ajuste Equilibrado (predeterminado)

La forma más sencilla de usar las actualizaciones de picos es con la configuración predeterminada de max-surge-update=1 y max-unavailable-update=0. Esta configuración añade solo 1 nodo de compensación al grupo de nodos durante la actualización y solo se actualiza 1 nodo a la vez, siguiendo un enfoque de "crear antes de terminar". En comparación con la actualización gradual estándar sin picos, que equivale a (max-surge-update=0, max-unavailable-update=1), este método es menos disruptivo, acelera los reinicios de pods durante las actualizaciones y es más conservador en su progresión.

Es importante tener en cuenta que, si adoptas el ajuste equilibrado, pueden producirse costes adicionales debido al nodo de aumento temporal que se añade 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 que no tienen nodos de aumento.

Actualizaciones rápidas sin recursos adicionales

En el caso de las cargas de trabajo que pueden tolerar interrupciones, puede ser adecuado un enfoque de actualización más rápido. Para ello, configura max-surge-update=0 y max-unavailable-update=20. Con esta configuración, se pueden actualizar 20 nodos simultáneamente sin añadir ningún nodo de sobretensión. Este método de actualización sigue un enfoque de "finalizar antes de crear". Como no se introducen nodos de aumento adicionales durante el proceso, este método también es el más rentable, ya que evita los gastos adicionales asociados a los nodos temporales.

Actualizaciones rápidas y menos disruptivas

Si tus cargas de trabajo son sensibles a las interrupciones, puedes aumentar la velocidad de la actualización con los siguientes ajustes: max-surge-update=20 y max-unavailable-update=0. Esta configuración actualiza 20 nodos en paralelo de forma que se crean antes de finalizar.

Sin embargo, la velocidad general de la actualización puede verse limitada si has configurado PodDisruptionBudgets (PDB) para tus cargas de trabajo. Esto se debe a que el PDB restringe 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 igual a 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.

Recuerda que iniciar varios nodos de aumento al principio del proceso de actualización puede provocar un aumento temporal de los costes, sobre todo en comparación con las configuraciones que no añaden nodos adicionales o que añaden menos nodos durante las actualizaciones.

Siguientes pasos