Actualizar manualmente un clúster o un grupo de nodos

En este documento, se explica cómo solicitar de forma manual una actualización o un cambio a una versión inferior del plano de control o los nodos de un clúster de Google Kubernetes Engine (GKE). GKE actualiza automáticamente la versión del plano de control y los nodos para garantizar que el clúster reciba funciones nuevas, correcciones de errores y parches de seguridad. Sin embargo, como se explica en este documento, también puedes realizar estas actualizaciones de forma manual.

Para obtener más información sobre cómo funcionan las actualizaciones automáticas y manuales del clúster, consulta Acerca de clúster de GKE GKE. También puedes controlar cuándo pueden o no ocurrir las actualizaciones automáticas configurando períodos de mantenimiento y exclusiones.

Puedes actualizar la versión de forma manual de la siguiente manera:

Para actualizar un clúster, GKE actualiza la versión que ejecutan el plano de control y los nodos en operaciones separadas. Los clústeres se actualizan a una versión secundaria más nueva (por ejemplo, de la 1.33 a la 1.34) o a una versión de parche más reciente (por ejemplo, de 1.33.4-gke.1350000 a 1.33.5-gke.1080000). El plano de control y los nodos de un clúster no necesariamente ejecutan la misma versión en todo momento. Para obtener más información sobre las versiones, consulta Control de versiones y asistencia de GKE.

Para obtener más información sobre cómo funcionan las actualizaciones de clústeres, incluidas las actualizaciones automáticas y manuales, consulta Acerca de clúster de GKE GKE.

Las versiones nuevas de GKE se anuncian con regularidad, y puedes recibir avisos sobre las versiones nuevas disponibles para cada clúster específico con notificaciones de clústeres. Para encontrar destinos de actualización automática específicos para los clústeres, obtén información sobre las actualizaciones de un clúster.

Para obtener más información sobre las versiones disponibles, consulta Control de versiones. Para obtener más información sobre los clústeres, consulta Arquitectura del clúster. Para obtener orientación sobre la actualización de clústeres, consulta Prácticas recomendadas para actualizar clústeres.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.

Información sobre la actualización

El plano de control y los nodos de un clúster se actualizan por separado. El plano de control y los nodos del clúster no necesariamente ejecutan la misma versión en todo momento.

Los planos de control y los nodos del clúster se actualizan de forma periódica, sin importar si tu clúster está inscrito en un canal de versiones o no.

Limitaciones

Los clústeres Alfa no se pueden actualizar.

Versiones compatibles

Las notas de la versión anuncian cuándo están disponibles versiones nuevas y cuándo las versiones anteriores dejan de estarlo. En cualquier momento, puedes enumerar todas las versiones de clústeres y nodos compatibles mediante este comando:

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

Reemplaza CONTROL_PLANE_LOCATION por la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.

Si tu clúster está inscrito en un canal de versiones, puedes actualizar a una versión de parche en un canal de versiones diferente con la misma versión secundaria que tu plano de control. Por ejemplo, puedes actualizar tu clúster de la versión 1.33.4-gke.1350000 en el canal regular a la versión 1.33.5-gke.1162000 en el canal rápido. Para obtener más información, consulta Ejecuta versiones de parches desde un canal más reciente. Todos los clústeres de Autopilot se inscriben en canales de versiones.

Acerca del cambio a una versión anterior

En ciertos casos, puedes cambiar la versión de tu clúster a una anterior:

A excepción de las situaciones descritas en los puntos anteriores, no puedes cambiar a una versión anterior de un clúster. No puedes cambiar el plano de control de un clúster a una versión secundaria anterior, incluso después de una actualización secundaria del plano de control de un solo paso. Por ejemplo, si tu plano de control ejecuta la versión 1.34 de GKE, no podrás cambiar a la versión inferior 1.33. Si intentas hacerlo, aparecerá el siguiente mensaje de error:

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.33.4-gke.1350000": specified version is
not newer than the current version.

Te recomendamos que pruebes y califiques las actualizaciones de versiones secundarias con clústeres en un entorno de pruebas cuando una versión secundaria nueva esté disponible, pero antes de que la versión se convierta en el destino de actualización automática para tu clúster. Esto es muy recomendable si tu clúster puede verse afectado por cambios significativos en la próxima versión secundaria, como las APIs o las funciones obsoletas que se quitan. Para obtener más información sobre la disponibilidad de las versiones, consulta Qué versiones están disponibles en un canal.

Actualiza el plano de control del clúster

GKE actualiza automáticamente los planos de control y los nodos del clúster. Para administrar cómo GKE actualiza tus clústeres, consulta Controla las actualizaciones de clústeres.

Con los clústeres de Autopilot y los clústeres de Standard regionales, el plano de control permanece disponible durante las actualizaciones del plano de control. Sin embargo, cuando inicias una actualización del plano de control para los clústeres zonales, no puedes modificar la configuración del clúster hasta que se pueda acceder al plano de control de nuevo en unos minutos. Las actualizaciones del plano de control no afectan la disponibilidad de los nodos trabajadores en los que se ejecutan las cargas de trabajo, ya que permanecen disponibles durante las actualizaciones del plano de control.

Como parte de la administración de las versiones de tu clúster, puedes iniciar una actualización manual en cualquier momento después de que haya una versión nueva disponible con uno de los siguientes métodos:

  • Actualización en un solo paso: Actualiza tu plano de control directamente a una versión secundaria o de parche posterior lo más rápido posible. Puedes usar este enfoque si ya validaste el rendimiento de tu clúster y tu carga de trabajo en la nueva versión secundaria.
  • Actualización secundaria del plano de control en dos pasos con seguridad de reversión (Versión preliminar): Actualiza tu plano de control a una versión secundaria posterior con un proceso de dos pasos en el que puedes validar la nueva versión secundaria durante un período de tiempo de estabilización y revertir la actualización si es necesario. Este método de actualización solo está disponible para actualizar a la versión 1.33 o posterior, para las actualizaciones secundarias manuales del plano de control.

Actualiza manualmente el plano de control con una actualización de un solo paso

Puedes actualizar tu plano de control de Autopilot o Standard de forma manual con la Google Cloud consola o Google Cloud CLI.

Console

Para actualizar el plano de control de tu clúster de forma manual, sigue estos pasos:

  1. Ve a la página Google Kubernetes Engine en la consola de Google Cloud .

    Ir a Google Kubernetes Engine

  2. Haz clic en el nombre del clúster.

  3. En Conceptos básicos del clúster, haz clic en Actualización disponible junto a Versión.

  4. Selecciona la versión nueva y, luego, haz clic en Guardar cambios.

gcloud

Para ver las versiones disponibles del plano de control de tu clúster, ejecuta el siguiente comando:

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

Para actualizar a la versión de clúster predeterminada, ejecuta el siguiente comando:

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION

Para actualizar a una versión específica que no sea la predeterminada, especifica la marca --cluster-version, como en el siguiente comando:

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

Reemplaza VERSION por la versión a la que deseas actualizar tu clúster. Puedes usar una versión específica, como 1.32.9-gke.1072000, o un alias de versión, como latest. Para obtener más información, consulta Cómo especificar la versión del clúster.

Después de actualizar un plano de control de Standard, puedes actualizar sus nodos. De forma predeterminada, los nodos de Standard que se crearon con la consola de Google Cloud tienen habilitada la actualización automática, por lo que esto ocurre de forma automática. Autopilot siempre actualiza los nodos automáticamente.

Actualización secundaria del plano de control en dos pasos con seguridad de reversión

Puedes actualizar de forma manual el plano de control de tu clúster de GKE Autopilot o Standard a la siguiente versión secundaria con una actualización de dos pasos. En este proceso de dos pasos, puedes probar el rendimiento de tu clúster con la nueva versión secundaria, conocida como versión binaria, mientras usas las funciones y las APIs de la versión secundaria anterior, conocida como versión emulada. Durante este período de prueba, en el que el plano de control se ejecuta en lo que se conoce como modo emulado, puedes revertir a la versión secundaria anterior, si es necesario. Para obtener más información sobre cómo Kubernetes permite este tipo de actualización, consulta Versión de compatibilidad para los componentes del plano de control de Kubernetes.

Las actualizaciones de dos pasos funcionan de la siguiente manera:

  1. Actualización binaria: GKE actualiza el archivo binario del plano de control a la nueva versión secundaria, pero emula la versión secundaria anterior:

    • Emula la versión anterior: El clúster ejecuta el nuevo binario, pero sigue emulando el comportamiento de la API de la versión secundaria anterior. Por ejemplo, puedes llamar a APIs que se quitaron en la nueva versión secundaria, pero que aún están disponibles en la versión secundaria anterior.
    • Probar nuevo binario: Puedes probar los nuevos binarios para detectar regresiones, correcciones y cambios de rendimiento antes de que las funciones de Kubernetes disponibles con la nueva versión secundaria sean accesibles. Supervisa las métricas de la aplicación, los registros, los estados de los Pods, las tasas de errores y la latencia.
    • Permite que los cambios se apliquen: Espera de seis horas a siete días para tener tiempo de probar y supervisar. Después de este tiempo, GKE realiza la actualización de versión emulada.
    • Revertir o completar la actualización: Puedes revertir la actualización si es necesario. O bien, puedes avanzar a la siguiente etapa si tienes confianza en la nueva versión secundaria, no quieres esperar a que se complete el período de prueba y estás listo para comenzar a usar las nuevas funciones y los cambios en la API.

  2. Actualización de la versión emulada: GKE actualiza la versión emulada para que coincida con la nueva versión binaria.

    • Habilita funciones nuevas: Se habilitan todas las funciones nuevas y los cambios en la API de la nueva versión secundaria.
    • Sin reversión: Después de que se produzca este paso, no podrás revertir a la versión secundaria original. Se completó la actualización.

Durante esta operación, se aplican las siguientes limitaciones:

  • No puedes iniciar una actualización secundaria del plano de control en un solo paso.
  • No puedes crear ni actualizar los nodos a una versión posterior a la versión emulada.
  • GKE no realiza ningún tipo de actualización automática en el plano de control ni en los nodos.

Inicia una actualización de dos pasos

Para iniciar una actualización de dos pasos, ejecuta el siguiente comando:

gcloud beta container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION \
  --control-plane-soak-duration SOAK_DURATION \
  --master

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • CONTROL_PLANE_LOCATION: Es la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.
  • VERSION: Es un parche específico de la próxima versión secundaria. Por ejemplo, si tu clúster ejecuta la versión 1.33, 1.34.1-gke.1829001.
  • SOAK_DURATION: Es el tiempo de espera en la etapa de seguridad de reversión. Puedes establecer este valor por un mínimo de 6 horas y un máximo de 7 días con los formatos de duración absoluta, como se explica en la referencia de gcloud topic datetimes. Por ejemplo, usa 2d1h para un tiempo de remojo de dos días y una hora.

Prueba el nuevo archivo binario durante una actualización de dos pasos

Durante el tiempo de prueba, valida que tu clúster (con el plano de control que ejecuta el nuevo archivo binario) y las cargas de trabajo funcionen según lo esperado. Puedes realizar uno de los siguientes pasos, según si puedes verificar que las cargas de trabajo son compatibles con el nuevo archivo binario:

  • Revertir: Si observas un problema con las cargas de trabajo que se ejecutan en el nuevo archivo binario, puedes revertir a la versión secundaria anterior.
  • Completa la actualización: Si verificaste que tus cargas de trabajo se ejecutan sin problemas en el nuevo binario, puedes completar la actualización si deseas comenzar a usar las funciones y las APIs de la nueva versión.
  • Esperar: También puedes esperar a que transcurra el tiempo de remojo. Luego, GKE realiza la actualización de versión emulada, en la que se realiza la transición para usar las funciones y las APIs de la nueva versión secundaria.
Observa la actualización en curso

Para obtener información sobre una actualización en curso, usa uno de los siguientes recursos:

Cómo revertir una actualización de dos pasos después de la actualización de la versión binaria

Durante una actualización de dos pasos, después de la actualización de la versión binaria, se produce el período de estabilización. Durante este período, puedes revertir a la versión secundaria anterior, si es necesario. No puedes revertir la actualización después de que GKE realice la actualización de versión emulada.

Una vez que se completa la operación de reversión, tu plano de control ejecuta la versión secundaria anterior, como lo hacía antes de que iniciaras la actualización de dos pasos.

Si es posible, sigue estos pasos para revertir la actualización:

  1. Ejecuta el comando de gcloud CLI en Obtén información sobre las actualizaciones a nivel del clúster para verificar que aún puedes revertir el plano de control a la versión secundaria anterior. Determina si puedes revertir la versión según el resultado del comando:

    • Puedes revertir la acción si hay una sección rollbackSafeUpgradeStatus en el resultado. En esa sección, guarda el valor de previousVersion para la variable VERSION en el siguiente paso. Continúa con el siguiente paso.
    • No puedes revertir la versión si no hay una sección rollbackSafeUpgradeStatus. Esto indica que GKE ya realizó la actualización de la versión emulada. No puedes realizar el siguiente paso.

  2. Si el paso anterior determinó que es posible revertir, revierte a la versión anterior:

    gcloud container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION
  --master

    El VERSION debe ser la versión de parche exacta que se usó anteriormente. Guardaste esta versión en el paso anterior.

Después de ejecutar este comando y volver a la versión anterior, puedes determinar por qué tu carga de trabajo no se ejecutó correctamente en el nuevo archivo binario. Si es necesario, puedes comunicarte con Atención al cliente de Cloud y proporcionar registros, mensajes de error y detalles relevantes sobre el error de validación que encontraste. Si deseas obtener más información, consulta Obtén asistencia.

Después de resolver el problema, puedes volver a actualizar manualmente a la nueva versión secundaria.

Completa la actualización en dos pasos

Durante el período de prueba, si verificaste que las cargas de trabajo se ejecutan correctamente con el nuevo archivo binario, puedes omitir el resto del tiempo de prueba:

gcloud beta container clusters clusters complete-control-plane-upgrade CLUSTER_NAME  \
  --location=CONTROL_PLANE_LOCATION

Después de ejecutar este comando, ya no podrás cambiar a la versión secundaria anterior.

Cambia la versión del plano de control a una versión anterior del parche

  1. Configura una exclusión de mantenimiento antes de cambiar a una versión inferior para evitar que GKE actualice automáticamente el plano de control después de que lo hagas.

  2. Cambia la versión del plano de control del clúster a una versión anterior del parche:

     gcloud container clusters upgrade CLUSTER_NAME \
     --master \
     --location=CONTROL_PLANE_LOCATION \
     --cluster-version=VERSION

Inhabilita las actualizaciones automáticas de clústeres

La seguridad de la infraestructura es de alta prioridad para GKE, y esos planos de control se actualizan periódicamente y no se pueden inhabilitar. Sin embargo, puedes aplicar exclusiones y períodos de mantenimiento para suspender de forma temporal las actualizaciones de los planos de control y los nodos.

Aunque no se recomienda, puedes inhabilitar la actualización automática de los nodos para los grupos de nodos estándar.

Cómo consultar el historial reciente de actualizaciones del plano de control

Para obtener una instantánea del historial reciente de actualizaciones automáticas de un clúster, obtén información sobre las actualizaciones de un clúster.

Como alternativa, puedes enumerar las operaciones recientes para ver cuándo se actualizó el plano de control:

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
    --location=CONTROL_PLANE_LOCATION

Actualizar grupos de nodos

De forma predeterminada, los grupos de nodos de Standard tienen habilitada la actualización automática, y todos los grupos de nodos administrados por Autopilot en los clústeres de Standard siempre tienen habilitada la actualización automática. Las actualizaciones automáticas de nodos garantizan que el plano de control y la versión de los nodos del clúster permanezcan sincronizados y cumplan con la política de sesgo de versiones de Kubernetes, que garantiza que los planos de control sean compatibles con los nodos de hasta dos versiones secundarias anteriores a la del plano de control. Por ejemplo, los planos de control de Kubernetes 1.34 son compatibles con los nodos de Kubernetes 1.32.

Práctica recomendada:

Evita inhabilitar las actualizaciones automáticas de nodos con grupos de nodos estándar para que tu clúster se beneficie de las actualizaciones que se mencionan en el párrafo anterior.

Con las actualizaciones del grupo de nodos de GKE Standard, puedes elegir entre tres estrategias de actualización configurables, incluidas las actualizaciones de aumento, las actualizaciones azul-verde y las actualizaciones azul-verde con ajuste de escala automático (versión preliminar). Los grupos de nodos administrados por Autopilot en los clústeres estándar siempre usan actualizaciones de aumento.

En el caso de los grupos de nodos estándar, elige una estrategia y usa los parámetros para ajustar la estrategia de modo que se adapte mejor a las necesidades del entorno del clúster.

Cómo funcionan las actualizaciones de nodos

Mientras se actualiza un nodo, GKE deja de programar pods nuevos en él y, en cambio, intenta programar sus pods en ejecución en otros nodos. Esto es similar a otros eventos que recrean el nodo, como la habilitación o inhabilitación de una función en el grupo de nodos.

Durante las actualizaciones automáticas o manuales de los nodos, los PodDisruptionBudgets (PDB) y el período de gracia de finalización del Pod se respetan por un máximo de 1 hora. Si los Pods que se ejecutan en el nodo no se pueden programar en nodos nuevos después de una hora, GKE inicia la actualización de todos modos. Este comportamiento se aplica incluso si configuras tus PDB para que siempre tengan todas las réplicas disponibles configurando el campo maxUnavailable en 0 o 0%, o bien configurando el campo minAvailable en 100% o en la cantidad de réplicas. En todas estas situaciones, GKE borra los Pods después de una hora para que se pueda borrar el nodo.

Práctica recomendada:

Si una carga de trabajo que se ejecuta en un grupo de nodos estándar requiere más flexibilidad con la finalización ordenada, usa actualizaciones azul-verde, que proporcionan una configuración para el tiempo de prueba adicional a fin de extender las verificaciones de PDB más allá del total de una hora predeterminado.

Para obtener más información sobre qué sucederá durante la terminación de nodos en general, consulta el tema sobre Pods.

La actualización se completará cuando se vuelvan a crear todos los nodos y el clúster se encuentre en el nuevo estado. Cuando un nodo recién actualizado se registra con el plano de control, GKE marca el nodo como programable.

Las instancias de nodo nuevas ejecutan la nueva versión de Kubernetes y también los elementos siguientes:

Para que se considere completa la actualización de un grupo de nodos, se deben volver a crear todos los nodos del grupo. Si se inició una actualización, pero no se completó y se encuentra en un estado parcialmente actualizado, es posible que la versión del grupo de nodos no refleje la versión de todos los nodos. Para obtener más información, consulta Algunas versiones de nodos no coinciden con la versión del grupo de nodos después de una actualización incompleta del grupo de nodos. Para determinar que finalizó la actualización del grupo de nodos, verifica el estado de la actualización del grupo de nodos. Si la operación de actualización supera el período de retención, verifica que la versión de cada nodo individual coincida con la versión del grupo de nodos.

Guarda tus datos en discos persistentes antes de actualizar

Antes de actualizar un grupo de nodos, debes asegurarte de que todos los datos que necesitas conservar estén almacenados en un pod con volúmenes persistentes que usen discos persistentes. En lugar de borrarse, los discos persistentes se desactivan durante las actualizaciones y sus datos se transfieren entre los Pods.

Las siguientes restricciones aplican a los discos persistentes:

  • Los nodos en los que se ejecutan los Pods deben ser VMs de Compute Engine.
  • Esas VMs deben estar en la misma zona y proyecto de Compute Engine que el disco persistente.

Para obtener más información sobre cómo agregar un disco persistente a una instancia de nodo existente, consulta Agrega o cambia el tamaño de los discos persistentes zonales en la documentación de Compute Engine.

Actualiza un grupo de nodos de forma manual

Puedes actualizar manualmente la versión de un grupo de nodos estándar o de un grupo de nodos administrado por Autopilot en un clúster estándar. Puedes hacer que coincida con la versión del plano de control o usar una versión anterior que aún esté disponible y sea compatible con el plano de control. Puedes actualizar varios grupos de nodos en paralelo de forma manual, mientras que GKE actualiza de manera automática solo un grupo de nodos a la vez.

Cuando actualizas de forma manual un grupo de nodos, GKE quita las etiquetas que agregaste a los nodos individuales con kubectl. Para evitar esto, aplica etiquetas a los grupos de nodos en su lugar.

Antes de actualizar manualmente tu grupo de nodos, ten en cuenta las siguientes condiciones:

  • La actualización de un grupo de nodos puede interrumpir las cargas de trabajo que se ejecutan en ese grupo de nodos. A fin de evitar esto, puedes crear un grupo de nodos nuevo con la versión requerida y migrar la carga de trabajo. Después de la migración, puedes borrar el grupo de nodos anterior.
  • Si actualizas un grupo de nodos con un Ingress en un estado con error, el grupo de instancias no se sincroniza. Para solucionar este problema, primero verifica el estado con el comando kubectl get ing. Si el grupo de instancias no se sincronizó, existe una forma de solucionar el problema: vuelve a aplicar el manifiesto que usaste para crear la entrada.

Puedes actualizar tus grupos de nodos de forma manual a una versión compatible con el plano de control:

Console

Si deseas actualizar un grupo de nodos estándar con la Google Cloud consola, sigue estos pasos:

  1. Ve a la página Google Kubernetes Engine en la consola de Google Cloud .

    Ir a Google Kubernetes Engine

  2. Haz clic en el nombre del clúster.

  3. En la página Detalles del clúster, haz clic en la pestaña Nodos.

  4. En la sección Grupos de nodos, haz clic en el nombre del grupo de nodos que deseas actualizar.

  5. Haz clic en  Editar.

  6. Haz clic en Cambiar, en Versión del nodo.

  7. Selecciona la versión requerida en la lista desplegable Versión del nodo y, luego, haz clic en Cambiar.

Es posible que el cambio de versión del nodo tarde varios minutos.

gcloud

Las siguientes variables se usan en los comandos de esta sección:

  • CLUSTER_NAME: el nombre del clúster del grupo de nodos que se actualizará.
  • NODE_POOL_NAME: el nombre del grupo de nodos que se actualizará.
  • CONTROL_PLANE_LOCATION: Es la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.
  • VERSION: La versión de Kubernetes a la que se actualizan los nodos. Por ejemplo, --cluster-version=1.34.1-gke.1293000 o cluster-version=latest.

Actualiza un grupo de nodos:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

Si deseas especificar una versión diferente de GKE en los nodos, usa la marca opcional --cluster-version:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Para obtener más información sobre cómo especificar versiones, consulta Control de versiones.

Para obtener más información, consulta la documentación de gcloud container clusters upgrade.

Cambia a una versión inferior de los grupos de nodos

Puedes cambiar un grupo de nodos a una versión inferior, por ejemplo, para mitigar una actualización incorrecta del grupo de nodos. Revisa las limitaciones antes de cambiar a una versión inferior de un grupo de nodos.

Práctica recomendada:

Usa la estrategia de actualización de nodos azul-verde si necesitas optimizar la mitigación de riesgos para las actualizaciones de grupos de nodos que afectan tus cargas de trabajo. Con esta estrategia, puedes revertir una actualización en curso a los nodos originales si la actualización no se realiza correctamente.

  1. Configura una exclusión de mantenimiento para el clúster a fin de evitar que GKE actualice el grupo de nodos de forma automática después de cambiar a una versión inferior.
  2. Si deseas cambiar a una versión inferior de un grupo de nodos, especifica una versión anterior mientras sigues las instrucciones para actualizar un grupo de nodos de forma manual.

Cambia los parámetros de actualización de aumento

Para obtener más información sobre cómo cambiar los parámetros de actualización de aumento, consulta Configura las actualizaciones de aumento.

Comprueba el estado de actualización del grupo de nodos

Puedes verificar el estado de una actualización con gcloud container operations.

Visualiza una lista de cada operación en ejecución o completada en el clúster de los últimos 12 días si hay menos de 5,000 operaciones, o bien las últimas 5,000 operaciones:

gcloud container operations list \
    --location=CONTROL_PLANE_LOCATION

A cada operación se le asigna un ID de operación y un tipo de operación, tiempos de comienzo y finalización, un clúster de destino y un estado. La lista es similar al siguiente ejemplo:

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

Para obtener más información sobre una operación en particular, especifica el ID de operación como se muestra en el siguiente comando:

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

Por ejemplo:

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

Si la actualización se canceló o falló y se completó parcialmente, puedes reanudar o revertir la actualización.

Verifica la configuración de actualización de grupos de nodos

Puedes ver los detalles de la estrategia de actualización de grupos de nodos que se usa para tus grupos de nodos mediante el comando gcloud container node-pools describe. En las actualizaciones azul-verde, el comando también muestra la fase actual de la actualización.

Ejecuta el comando siguiente:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Reemplaza lo siguiente:

  • NODE_POOL_NAME: el nombre del grupo de nodos que se debe describir
  • CLUSTER_NAME: el nombre del clúster del grupo de nodos que deseas describir
  • CONTROL_PLANE_LOCATION: Es la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.

Este comando generará la configuración de actualización actual. En el siguiente ejemplo, se muestra el resultado si usas la estrategia de actualización azul-verde.

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

Si usas la estrategia de actualización azul-verde, el resultado también incluye detalles sobre la configuración de actualización azul-verde y su fase intermedia actual. En el siguiente ejemplo, se muestra cómo podría ser este resultado:

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

Cancela la actualización de un grupo de nodos

Puedes cancelar una actualización en cualquier momento. Para obtener más información sobre lo que sucede cuando cancelas una actualización de aumento, consulta Cancela una actualización de aumento. Para obtener más información sobre lo que sucede cuando cancelas una actualización azul-verde, consulta Cancela una actualización azul-verde.

  1. Obtén el ID de operación de la actualización:

    gcloud container operations list \
      --location=CONTROL_PLANE_LOCATION

  2. Cancela la actualización:

    gcloud container operations cancel OPERATION_ID \
      --location=CONTROL_PLANE_LOCATION

Consulta la documentación de gcloud container operations cancel.

Reanuda una actualización del grupo de nodos

Para reanudar una actualización, vuelve a iniciarla de forma manual y especifica la versión de destino de la actualización original.

Por ejemplo, si una actualización falló o si pausaste una actualización en curso, puedes reanudar la actualización cancelada si vuelves a iniciar la misma actualización en el grupo de nodos y especificas la versión de destino de la operación de actualización inicial.

Para obtener más información sobre lo que sucede cuando reanudas una actualización, consulta Reanuda una actualización de aumento y actualización azul-verde.

Para reanudar una actualización, usa el siguiente comando:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Reemplaza lo siguiente:

  • NODE_POOL_NAME: El nombre del grupo de nodos para el que deseas reanudar la actualización del grupo de nodos.
  • CLUSTER_NAME: El nombre del clúster del grupo de nodos para el que deseas reanudar la actualización.
  • CONTROL_PLANE_LOCATION: Es la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.
  • VERSION: Es la versión de destino de la actualización del grupo de nodos cancelada.

Para obtener más información, consulta la documentación de gcloud container clusters upgrade.

Revierte la actualización de un grupo de nodos

Puedes revertir un grupo de nodos para cambiar los nodos actualizados a su estado original antes de que comience la actualización del grupo de nodos.

Usa el comando rollback si se canceló una actualización en curso, o si la actualización falló o está incompleta debido a un tiempo de espera de período de mantenimiento. Como alternativa, si quieres especificar la versión, sigue las instrucciones para cambiar a una versión inferior del grupo de nodos.

Para obtener más información sobre lo que sucede cuando se revierte una actualización de un grupo de nodos, consulta Revierte una actualización de aumento o Revierte una actualización azul-verde.

Para revertir una actualización, ejecuta el siguiente comando:

gcloud container node-pools rollback NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Reemplaza lo siguiente:

  • NODE_POOL_NAME: el nombre del grupo de nodos en el que se revertirá la actualización del grupo de nodos.
  • CLUSTER_NAME: el nombre del clúster del grupo de nodos para el que se debe revertir la actualización.
  • CONTROL_PLANE_LOCATION: Es la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.

Consulta la documentación de gcloud container node-pools rollback.

Completa una actualización del grupo de nodos

Si usas la estrategia de actualización azul-verde, puedes completar una actualización del grupo de nodos durante la fase de prueba y omitir el resto del tiempo de prueba.

Para obtener información sobre cómo funciona la actualización de un grupo de nodos, consulta Completa una actualización de grupo de nodos.

Para completar una actualización cuando usas la estrategia de actualización azul y verde, ejecuta el siguiente comando:

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Reemplaza lo siguiente:

  • NODE_POOL_NAME: El nombre del grupo de nodos para el que deseas completar la actualización.
  • CLUSTER_NAME: El nombre del clúster del grupo de nodos para el que deseas completar la actualización.
  • CONTROL_PLANE_LOCATION: Es la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.

Consulta la documentación de gcloud container node-pools complete-upgrade.

Problemas conocidos

Si tienes objetos PodDisruptionBudget configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se actualicen a la versión del plano de control después de varios intentos. Para evitar esta falla, te recomendamos que escales verticalmente la Deployment o la HorizontalPodAutoscaler a fin de permitir que el nodo se desvíe y aún respete la configuración de PodDisruptionBudget.

Para ver todos los objetos PodDisruptionBudget que no permiten ninguna interrupción, haz lo siguiente:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Aunque las actualizaciones automáticas pueden encontrar el problema, el proceso de actualización automática fuerza a los nodos a actualizarse. Sin embargo, la actualización toma una hora de más en cada nodo del espacio de nombres istio-system que infringe el PodDisruptionBudget.

Soluciona problemas

Para obtener información sobre la solución de problemas, consulta Soluciona problemas de actualización de clústeres.

¿Qué sigue?