Acerca de las actualizaciones de clústeres con secuencia de lanzamiento

Puedes administrar el orden de las actualizaciones automáticas de clústeres en los clústeres de Google Kubernetes Engine (GKE) en varios entornos con la secuenciación de lanzamiento. Por ejemplo, puedes calificar una versión nueva en clústeres de preproducción antes de actualizar los clústeres de producción. Para usar esta característica, debes estar familiarizado con las actualizaciones de clústeres, los canales de versiones y la administración de flotas.

Para comenzar, consulta Establece una secuencia para el lanzamiento de las actualizaciones de los clústeres.

Califica actualizaciones en todos los entornos

Para actualizar de forma automática los clústeres con secuenciación de lanzamientos, usa flotas o permisos (vista previa) en los que agrupaste los clústeres con el mismo canal de versiones y versión secundaria en etapas de implementación. Elige la secuencia de flotas o la secuencia de permisos y define un tiempo de prueba entre cada grupo de clústeres. Luego, cuando GKE selecciona una versión nueva para las actualizaciones automáticas en el canal de versiones, tus grupos de clústeres se actualizan en la secuencia que definiste, y puedes validar que las cargas de trabajo se ejecuten como se espera con una versión nueva antes de que las actualizaciones comiencen con tus clústeres de producción.

Secuencia de lanzamiento basada en flotas

En el siguiente diagrama, se ilustra cómo GKE actualiza de forma automática los clústeres en una secuencia de lanzamiento organizada con flotas:

Secuencia de lanzamiento basada en flotas. Puedes organizar los clústeres en flotas o subdividirlos aún más en las flotas con permisos.

Con una secuencia basada en flotas, cuando GKE pone a disposición un nuevo objetivo de actualización en el canal de versiones en el que se inscriben todos los clústeres de esta secuencia, GKE actualiza estas flotas de clústeres en esta secuencia, con los clústeres de la flota upstream que califican la versión nueva para clústeres en la flota downstream, hasta tres flotas. Durante el tiempo de prueba configurado entre las flotas, puedes confirmar que las cargas de trabajo se ejecuten como se espera en los clústeres actualizados.

Secuencia de lanzamiento basada en permisos

Si necesitas mayor nivel de detalle con la organización de los clústeres en una flota, puedes crear una secuencia de lanzamiento entre permisos:

Secuencias de lanzamiento basadas en permisos. Puedes organizar los clústeres en flotas o subdividirlos aún más en las flotas con permisos.

Con los permisos, puedes crear varias secuencias de lanzamiento en una flota, cada una con sus propios canales de versiones, objetivos de actualización y tiempos de prueba independientes. Una secuencia de lanzamiento basada en permisos funciona de manera idéntica a una secuencia de lanzamiento basada en flotas, excepto que las actualizaciones son de permiso a permiso calificado, en lugar de ser de flota a flota.

Cómo GKE actualiza los clústeres en una secuencia de lanzamiento

Cuando GKE actualiza un clúster, primero se actualiza el plano de control y, luego, los nodos. En una secuencia de implementación, los clústeres se actualizan con este proceso, pero también puedes controlar el orden en que se actualizan los grupos (flotas o permisos) de los clústeres, y debes especificar un tiempo de prueba para elegir por cuánto tiempo GKE se detiene antes de que las actualizaciones continúen de un grupo al siguiente.

Las actualizaciones de clústeres en una secuencia de lanzamiento continúan con los siguientes pasos:

  1. GKE establece un objetivo de actualización automática nuevo para los clústeres en una versión secundaria en un canal de versiones específico, con la nota de la versión que menciona algo similar al siguiente mensaje: “Los planos de control y los nodos con la actualización automática habilitada en el canal regular se actualizarán de la versión 1.21 a la versión 1.22.15‐gke.1000 con esta versión".
  2. GKE comienza a actualizar los planos de control del clúster a la versión nueva en el primer grupo de clústeres. Después de que GKE actualiza el plano de control de un clúster, GKE comienza a actualizar los nodos del clúster. GKE respeta la disponibilidad de mantenimiento cuando actualizas clústeres en una secuencia de lanzamiento.
  3. GKE realiza los siguientes pasos para las actualizaciones del plano de control:
    1. GKE comienza el período de prueba para las actualizaciones del plano de control después de que finalizan todas las actualizaciones del plano de control del clúster en el primer grupo o que pasan 30 días desde que comenzaron las actualizaciones del control.
    2. Después de que se completa el período de prueba para las actualizaciones del plano de control del clúster en el primer grupo, GKE comienza las actualizaciones del plano de control en el segundo grupo.
  4. En paralelo a las actualizaciones del plano de control, GKE realiza los siguientes pasos para las actualizaciones de nodos:
    1. GKE comienza el período de prueba para las actualizaciones de nodos después de que finalizan todas las actualizaciones de nodos del clúster en el primer grupo o después de que transcurran 30 días desde que comenzaron las actualizaciones de nodos.
    2. GKE inicia las actualizaciones de nodos en el segundo grupo para los clústeres en los que el plano de control ya se actualizó después de que se complete el período de prueba para las actualizaciones de nodos en el primer grupo.
  5. GKE repite estos pasos del segundo grupo al tercer grupo, hasta que los clústeres de todos los grupos de la secuencia de lanzamiento se hayan actualizado al objetivo de actualización nuevo.

A medida que los clústeres se actualizan en cada grupo, verifica durante el tiempo de prueba que tus cargas de trabajo se ejecuten como se espera con clústeres que ejecutan la versión nueva de GKE.

Es posible que no se puedan actualizar los clústeres debido a exclusiones o períodos de mantenimiento, el uso de APIs obsoletas o a otras razones. Para obtener más información, consulta Cómo funciona la secuenciación de lanzamiento con otras funciones de actualización.

Cómo controlar las actualizaciones en una secuencia de lanzamiento

Con las actualizaciones de clústeres en una secuencia de lanzamiento, los grupos de clústeres se actualizan en el orden que definiste y se prueban en cada grupo durante el tiempo que hayas elegido. Mientras las actualizaciones están en curso, puedes verificar el estado de una secuencia de lanzamiento y administrar la secuencia de lanzamiento según sea necesario. También puedes controlar el proceso de las siguientes maneras:

Para obtener más información, consulta Cómo funciona la secuenciación de lanzamiento con otras funciones de actualización.

Ejemplo: El banco comunitario lanza cambios de forma gradual de las pruebas a la producción

Por ejemplo, el administrador de la plataforma en un banco de la comunidad administra tres entornos de implementación principales, cada uno de los cuales está organizado en una flota: pruebas, almacenamiento en etapa intermedia y producción. Según sea necesario para la secuenciación de lanzamiento, el administrador inscribió cada clúster en las tres flotas en el mismo canal de versiones: en estas flotas, el canal regular con todos los clústeres que ejecutan la misma versión secundaria.

El administrador usa la secuenciación de lanzamiento para definir el orden en el que GKE actualiza los clústeres en estos entornos. El orden del lanzamiento le brinda al administrador la oportunidad de verificar que sus cargas de trabajo se ejecuten como se espera con clústeres en una versión nueva de GKE antes de actualizar el entorno de producción a la versión nueva. Esta secuencia se ilustra en el diagrama de secuencia de lanzamiento basada en flotas.

El administrador usa el tiempo de prueba entre estas flotas que se actualizan para verificar que sus cargas de trabajo se ejecuten como se espera con clústeres en la versión nueva de GKE. En el caso de la flota de pruebas, el administrador establece el tiempo de prueba en 14 días para que tengan dos semanas completas a fin de probar cómo se ejecutan las cargas de trabajo. Para el almacenamiento en etapa intermedia, establece el tiempo de prueba en 7 días, ya que no se necesita tanto tiempo adicional después de que las cargas de trabajo ya se hayan ejecutado en las pruebas.

El administrador también puede anular el tiempo de prueba predeterminado para las actualizaciones en versiones específicas, lo que puede realizar en una de las siguientes situaciones:

  • El administrador termina de calificar la versión antes de que se complete el tiempo de prueba y desea que las actualizaciones continúen con la siguiente flota, por lo que establece el tiempo de prueba en cero.
  • El administrador necesita más tiempo para calificar la versión nueva antes de que las actualizaciones continúen con la siguiente flota, ya que notó un problema con algunas de sus cargas de trabajo, por lo que establece el tiempo de prueba en el máximo de 30 días.

El administrador usa exclusiones y períodos de mantenimiento para garantizar que GKE actualice los clústeres cuando sea menos perjudicial para el banco. GKE respeta la disponibilidad de mantenimiento de los clústeres actualizados en una secuencia de lanzamiento.

  • El administrador configuró períodos de mantenimiento para sus clústeres a fin de garantizar que GKE solo actualice los clústeres después de las horas hábiles.
  • El administrador también usa exclusiones de mantenimiento para evitar que los clústeres se actualicen de forma temporal si detecta problemas con las cargas de trabajo del clúster.

El administrador usa una combinación de actualizaciones de aumento y actualizaciones azul-verde para sus nodos, lo que equilibra la velocidad y la tolerancia al riesgo según las cargas de trabajo que se ejecutan en esos nodos.

El administrador cambia a secuencias de lanzamiento basadas en permisos

Si el administrador decide que necesita agrupar más clústeres dentro de una flota, puede usar permisos. Con los permisos, puede crear secuencias de lanzamiento independientes con agrupaciones de clústeres más específicas, que pueden ejecutarse en canales de versiones diferentes o con tiempos de prueba distintos.

Por ejemplo, si el administrador desea que los clústeres del equipo de la base de datos usen el canal estable y tiempos de prueba más largos, mientras que los clústeres del equipo del sitio web de frontend usan el canal rápido y tiempos de prueba más cortos, puede usar permisos para subdividir estos clústeres en las flotas existentes y crear secuencias de lanzamiento independientes. Este tipo de secuencia se ilustra mediante el diagrama de secuencias de lanzamiento basadas en permisos. A fin de hacer esto en tu entorno, sigue las instrucciones para cambiar entre secuencias de lanzamiento basadas en flotas y basadas en permisos.

Elegibilidad para el lanzamiento

Para que los clústeres se actualicen de forma automática con la secuenciación de implementación, todos los clústeres de todos los grupos (flotas o permisos) en una secuencia de lanzamiento deben recibir el mismo objetivo de actualización. Los clústeres deben estar inscritos en el mismo canal de versiones, y recomendamos que los clústeres ejecuten la misma versión secundaria ya que los objetivos de actualización se configuran por versión secundaria. Sin embargo, para algunas versiones, como la versión del siguiente ejemplo, los clústeres de varias versiones secundarias recibieron el mismo objetivo, lo que significa que podrían actualizarse correctamente en el secuencia de lanzamiento que ejecuta varias versiones secundarias.

Puedes verificar el estado del lanzamiento de la versión en una secuencia para obtener más información sobre el estado y si los problemas de elegibilidad de la versión están evitando que se realicen las actualizaciones. Según las discrepancias de la versión, es posible que debas tomar medidas, como actualizar un clúster de forma manual o quitarlo de un grupo para continuar con las actualizaciones de clústeres. Para solucionar problemas de elegibilidad para el lanzamiento, consulta Soluciona problemas de elegibilidad para el lanzamiento.

Ejemplo de versión de GKE

Por ejemplo, la versión 2022-R25 establece un objetivo de actualización para varias versiones secundarias en clústeres inscritos en el canal regular. Un objetivo de actualización puede ser una versión secundaria nueva (de 1.20 a 1.21) o solo una versión de parche nueva (de 1.21.x-gke.x a 1.21.14-gke.4300). En esta versión, en el canal regular, las siguientes versiones nuevas estaban disponibles para clústeres en versiones secundarias específicas:

  • Los clústeres en 1.20 y 1.21 se actualizaron a 1.21.14-gke.4300.
  • Los clústeres en 1.22 se actualizaron a 1.23.8-gke.1900.
  • Los clústeres en 1.24 se actualizaron a 1.24.5-gke.600.

El grupo más ascendente recibe todos los objetivos de actualización

Para los clústeres del primer grupo de una secuencia, que no tiene un grupo ascendente a fin de calificar versiones nuevas, GKE actualiza los clústeres con objetivos de actualización elegibles, sin importar si esos objetivos de actualización son diferentes unos de otros. Por ejemplo, en el primer grupo de una secuencia, si algunos clústeres ejecutaran 1.20, esos clústeres podrían actualizarse a 1.21.14-gke.4300, y los clústeres que ejecutan 1.24 podrían actualizarse a 1.24.5- gke.600. Esto se debe a que, para el primer grupo de una secuencia, GKE considera que todos los objetivos de actualización están calificados para estos clústeres, ya que no hay un grupo ascendente a fin de calificar una versión nueva.

Un grupo ascendente debe calificar solo una versión

En cualquier grupo descendente, si GKE puede actualizar los clústeres depende de si el grupo ascendente calificó un objetivo de actualización para el que son elegibles todos los clústeres de este grupo. Por lo general, esto significa que todos los clústeres se inician en la misma versión secundaria. Sin embargo, a partir de la versión de ejemplo, los clústeres de 1.20 y 1.21 tenían el mismo objetivo de actualización, por lo que los clústeres que ejecutan ambas versiones podrían, en el mismo grupo, calificar la actualización a 1.21.14‐gke.4300

Si todos los clústeres de un grupo no tienen el mismo objetivo de actualización, este grupo no podrá calificar un objetivo de actualización para el siguiente grupo. En esta situación, GKE no puede actualizar de forma automática los clústeres en grupos descendentes. Por ejemplo, si en el primer grupo, algunos clústeres se actualizaron a 1.21.14-gke.4300 y otros a 1.23.8-gke.1900, los clústeres del segundo grupo no se pueden actualizar de forma automática ya que el grupo no recibió una versión calificada. Para avanzar en las actualizaciones en esta situación, consulta Soluciona los problemas de elegibilidad de un grupo.

Un grupo ascendente debe calificar una versión que coincida con los clústeres del siguiente grupo

Si los clústeres de un grupo ascendente calificaron una versión diferente a la versión por la que los clústeres del siguiente grupo fueron elegibles, GKE tampoco puede actualizar de forma automática los clústeres en ningún grupo descendente.

Por ejemplo, si todos los clústeres del primer grupo se actualizaron a la versión 1.21.14-gke.4300, pero los clústeres del segundo grupo ejecutaron la versión 1.22 (en la que el objetivo de actualización es 1.23.8-gke.1900), los clústeres del segundo grupo no se actualizarán de forma automática. El primer grupo calificaba 1.21.14-gke.4300, pero los clústeres del segundo grupo (actualmente en 1.22) solo son elegibles para el objetivo de actualización 1.23.8-gke.1900, por lo que GKE no puede actualizar estos clústeres de forma automática. Para avanzar en las actualizaciones en esta situación, consulta Corrige la elegibilidad entre grupos.

Cómo funciona la secuenciación de lanzamiento con otras funciones de actualización

La secuencia de lanzamiento es una función de una colección de funciones que te permiten controlar el aspecto de actualización del ciclo de vida del clúster. En esta sección, se explica cómo funciona con algunas de las otras funciones disponibles relacionadas con las actualizaciones de clústeres.

Cómo funciona la secuenciación de lanzamiento con exclusiones y períodos de mantenimiento

GKE respeta los períodos de mantenimiento y las exclusiones de mantenimiento cuando se actualizan clústeres con secuencia de lanzamiento. GKE solo inicia una actualización de clúster dentro del período de mantenimiento de un clúster. Puedes usar una exclusión de mantenimiento para evitar que un clúster se actualice de forma temporal. Si GKE no puede actualizar un clúster debido a una exclusión o período de mantenimiento, esto puede evitar que las actualizaciones de clúster finalicen en un grupo. Si una actualización del clúster no se puede completar en un plazo de 30 días debido a períodos de mantenimiento o exclusiones, el grupo ingresará a su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse.

Puedes usar las exclusiones de mantenimiento como una medida temporal para evitar que una secuencia complete un lanzamiento en un grupo y pase al siguiente grupo. Para obtener más información, consulta Retrasa la finalización del lanzamiento de la versión del grupo.

Cómo funciona la secuenciación de lanzamiento con la detección del uso de elementos obsoletos

GKE pausa las actualizaciones del clúster cuando detecta el uso de ciertas APIs y funciones obsoletas. Las actualizaciones automáticas también se detienen en los clústeres que están dentro del grupo en una secuencia de lanzamiento. Para obtener más información, consulta Cómo funcionan las bajas de Kubernetes con GKE.

Cómo funciona la secuenciación de lanzamiento con estrategias de actualización de nodos

Las actualizaciones de los nodos usarán su estrategia de actualización de nodos configurada cuando se actualicen en una secuencia de lanzamiento. Al igual que con las actualizaciones de clústeres sin secuencia de lanzamiento, GKE usa actualizaciones de aumento para los nodos de Autopilot. Para obtener más información, consulta Actualizaciones automáticas de los nodos.

Si las actualizaciones de los nodos no se pueden completar en 30 días, el grupo ingresará a su fase de prueba sin importar si todos los clústeres terminaron de actualizarse. Esto puede suceder si la estrategia de actualización de nodos hace que la actualización de nodos de un clúster Standard tarde más en completarse, en especial si es un grupo de nodos grande. También puede verse agravado por los períodos de mantenimiento que no son lo suficientemente extensos como para que una actualización de nodos se complete. Para obtener más información, consulta Consideraciones para configurar un período de mantenimiento.

Cómo funciona la secuenciación de lanzamiento con canales de versiones

Se requieren canales de versiones para usar la secuencia de lanzamiento. Todos los clústeres de todos los grupos de una secuencia de lanzamiento deben estar en el mismo canal de versiones.

Recibe varias actualizaciones en una secuencia

Si una versión nueva se convierte en un objetivo de actualización en el canal de versiones mientras las actualizaciones del clúster a un objetivo de actualización anterior aún continúan en la secuencia de lanzamiento, un grupo ascendente puede comenzar el lanzamiento de una versión nueva mientras un el grupo descendente aún recibe la actualización anterior. Por ejemplo, si el tercer grupo de una secuencia lanza 1.24.2-gke.100, el primer grupo en la secuencia puede lanzar 1.24.3-gke.500 de forma simultánea.

Consideraciones para elegir la secuencia de lanzamiento

Considera usar la secuenciación de lanzamiento si deseas administrar las actualizaciones de clústeres mediante la calificación de las versiones nuevas en un entorno antes de implementarlas en otro.

Para crear secuencias de lanzamiento basadas en permisos, debes habilitar la API de Anthos (GKE Enterprise) en tus proyectos host de la flota.

Sin embargo, es posible que esta no sea la opción correcta para tu entorno si se cumple alguna de las siguientes afirmaciones:

  • Tienes clústeres que no están en el mismo canal de versiones ni versión secundaria en el mismo entorno de producción.
  • Debes automatizar las actualizaciones que no se pueden asignar a tres etapas de implementación, ya que solo puedes crear una secuencia de lanzamiento con hasta tres grupos de clústeres. No puedes vincular grupos en varias secuencias de lanzamiento para crear una secuencia de lanzamiento con más de tres grupos.
  • No puedes usar la administración de flotas.
  • Con frecuencia, realizas actualizaciones manuales que hacen que los clústeres de un grupo tengan diferentes versiones de objetivo de actualización automática.

Limitaciones

Para actualizar correctamente tus clústeres con secuenciación de lanzamiento, debes cumplir con las siguientes limitaciones:

  • Inscribe un clúster en un solo permiso. Si un clúster está inscrito en varios permisos, GKE no puede actualizar de forma automática el clúster en la secuencia de lanzamiento.
  • No se admite la creación de una secuencia de lanzamiento basada en permisos con varios permisos dentro de la misma flota.
  • Crea una secuencia de lanzamiento lineal sin ciclos (un grupo tiene un grupo descendente como su grupo ascendente) o ramas (un grupo tiene más de un grupo descendente).
  • Crea secuencias de lanzamiento entre permisos o secuencias de lanzamiento entre flotas. No puedes crear secuencias mixtas con flotas y permisos en la misma secuencia.
  • Asegúrate de que tus clústeres en una secuencia de lanzamiento estén inscritos en el mismo canal de versiones y ejecuten la misma versión secundaria.

Problemas conocidos

  • Si un grupo contiene clústeres de diferentes ubicaciones, es posible que una actualización de clústeres solo esté disponible para algunos de los clústeres de forma temporal debido al lanzamiento gradual de la versión nueva. Es más probable que esto suceda con el primer grupo de clústeres y debería resolverse en una semana.
  • Si hay un grupo vacío en una secuencia de lanzamiento, la forma en que esto afecta la calificación de la versión depende de las siguientes condiciones:
    • Si el grupo vacío no tiene un grupo ascendente, las actualizaciones del clúster no continúan con el grupo descendente, ya que el grupo vacío no puede calificar versiones.
    • Si el grupo vacío tiene un grupo ascendente, todas las actualizaciones pendientes del clúster ingresan al estado COMPLETE y se propagan al grupo descendente.
  • Debido a la forma en que GKE realiza un seguimiento de las actualizaciones menores y de parches, es posible que veas dos actualizaciones del mismo tipo y la misma versión, pero con estados diferentes cuando verifiques el estado del permiso.

¿Qué sigue?