Acerca de los canales de lanzamiento

Usa canales de lanzamiento para Google Kubernetes Engine (GKE) y elige las versiones de tus clústeres con el equilibrio que prefieras entre disponibilidad de funciones y estabilidad.

GKE actualiza automáticamente todos los clústeres con el tiempo, incluidos los que no están registrados en un canal de lanzamiento, para asegurarse de que reciban actualizaciones de seguridad, correcciones de problemas conocidos y nuevas funciones, y de que ejecuten una versión compatible de Kubernetes. Puedes controlar el momento de las actualizaciones con ventanas de mantenimiento y exclusiones.

Te recomendamos que registres tu clúster en un canal de lanzamiento, ya que así tendrás el máximo control sobre el ámbito de las exclusiones de mantenimiento (podrás impedir tipos específicos de actualizaciones en lugar de todas las actualizaciones) y podrás secuenciar el lanzamiento de las actualizaciones del clúster. Los clústeres de Autopilot solo se pueden registrar en un canal de lanzamiento.

Si no registras tu clúster estándar en un canal de lanzamiento, puedes inhabilitar las actualizaciones automáticas de los nodos de grupos de nodos concretos y gestionar manualmente las actualizaciones de los nodos de esos grupos. Sin embargo, los planos de control de todos los clústeres se actualizan automáticamente y, cuando una versión llega al final del periodo de asistencia, los planos de control y los nodos de los clústeres se actualizan automáticamente, independientemente de si están registrados en un canal de lanzamiento. Para obtener más información, consulta la comparación entre los clústeres registrados y no registrados en un canal de lanzamiento.

Qué canales están disponibles

En la siguiente tabla se explican las propiedades de los canales de lanzamiento disponibles, cada uno de los cuales ofrece un equilibrio entre la disponibilidad de las funciones y la estabilidad. Todos los canales ofrecen versiones compatibles de GKE y se consideran disponibles de forma generalizada, aunque es posible que algunas funciones no lo estén, como se indica. Las versiones de Kubernetes de estos canales son versiones oficiales de Kubernetes e incluyen APIs de Kubernetes GA y beta.

Canal Disponibilidad de la nueva versión de Kubernetes Cuándo usar este canal
Rápido Varias semanas después de la disponibilidad general del código abierto upstream Cuanto antes dispongas de la versión más reciente de Kubernetes, antes podrás usar las funciones nuevas de GKE cuando estén disponibles. GKE actualiza tu clúster con frecuencia para ofrecer la versión más reciente del parche disponible y las funciones más recientes de Kubernetes. Los clústeres suscritos al canal Rápido usan versiones de disponibilidad general, pero recomendamos usar el canal Rápido para probar versiones y APIs de Kubernetes más recientes en entornos de preproducción.
Normal (predeterminado) Entre 2 y 3 meses después de lanzar la versión rápida Puedes usar las funciones de GKE y Kubernetes poco después de que estén disponibles para el público general, pero en una versión que se haya cualificado durante un periodo más largo. Recomendamos esta opción para casi todos los usuarios por el equilibrio que ofrece entre la disponibilidad de funciones y la estabilidad de las versiones.
Estable Entre 2 y 3 meses después de lanzarse en Regular Prioriza la estabilidad por encima de las funciones nuevas. GKE lanza los cambios y las nuevas versiones de este canal en último lugar, después de validarlos en los canales Rápido y Habitual, lo que permite más tiempo aún para validarlos.
Ampliada Alineado con el canal habitual Usa este canal para obtener asistencia a largo plazo y mantener un clúster con una versión secundaria el mayor tiempo posible. Para obtener más información, consulta Obtener asistencia a largo plazo con el canal ampliado.
Sin canal (no recomendado) Alineado con el canal habitual No se recomienda esta opción. El plano de control y los nodos se actualizan automáticamente de acuerdo con los canales Regular y Estable. Si necesitas inhabilitar las actualizaciones automáticas de nodos a nivel de grupo de nodos, puedes usar esta opción de configuración. También puedes inhabilitar las actualizaciones automáticas de nodos a nivel de clúster con los canales de lanzamiento. Para obtener más información, consulta la comparación entre los clústeres registrados y no registrados en un canal de lanzamiento.

Cuando registras un clúster en un canal de lanzamiento, ese clúster se actualiza automáticamente en la fecha especificada en la columna Actualización automática de la programación de lanzamientos de GKE o después de ella.

Cuando una versión ha acumulado uso y ha demostrado estabilidad en los clústeres del canal Rápido, se asciende al canal Normal. Finalmente, la versión se promociona al canal Estable, que solo recibe actualizaciones de alta prioridad. Cada promoción indica un nivel de estabilidad y preparación para la producción, en función del rendimiento observado de los clústeres que ejecutan esa versión.

Los parches de seguridad críticos se envían a todos los canales de lanzamiento para proteger tus clústeres y la infraestructura de Google. En situaciones de emergencia poco frecuentes, es posible que GKE actualice automáticamente los clústeres a versiones que aún no estén disponibles en su canal de lanzamiento.

Qué versiones están disponibles en un canal

Cada canal de lanzamiento ofrece varias versiones secundarias. Estas versiones cumplen los estándares de calidad de ese canal concreto. Este conjunto de versiones disponibles incluye una versión predeterminada para la creación de clústeres, que se selecciona de un conjunto de versiones disponibles de ese canal. Para ver qué versiones están disponibles en un canal de lanzamiento, sigue las instrucciones para consultar las versiones predeterminadas y disponibles de los canales de lanzamiento.

  • Las nuevas versiones de los parches estarán disponibles al menos una semana antes de convertirse en el objetivo de actualización automática para todos los canales.
  • Se publican nuevas versiones menores:
    • Al menos dos semanas antes de convertirse en un objetivo de actualización automática para el canal Rápido.
    • Al menos cuatro semanas antes de convertirse en un objetivo de actualización automática para los canales Regular y Estable.

Puedes probar una versión de GKE recién disponible antes de actualizar tu entorno de producción. Por ejemplo, puedes suscribirte a las notificaciones de actualización para recibir información sobre las versiones disponibles y, a continuación, actualizar de forma proactiva un entorno de preproducción a la nueva versión antes de que se convierta en el destino de la actualización automática de los clústeres de tu entorno de producción.

Si necesitas mantener un clúster en una versión específica, por ejemplo, para validar o probar versiones más recientes antes de actualizarlo, te recomendamos que utilices exclusiones de mantenimiento.

Una vez que una versión secundaria esté disponible en un canal de lanzamiento, seguirá estando disponible en ese canal para los clústeres nuevos o actuales hasta que llegue a su fecha de finalización del soporte.

Qué ocurre cuando una versión se convierte en un destino de actualización automática en un canal de lanzamiento

GKE actualiza automáticamente los clústeres a lo largo del tiempo a nuevos destinos de actualización automática. Cuando hay nuevos destinos de actualización automática disponibles, GKE evalúa si tu clúster específico debe actualizarse a esa nueva versión. GKE tiene en cuenta si tu clúster tiene políticas de mantenimiento u otras restricciones que impidan las actualizaciones automáticas y no ignorará esos motivos, excepto en situaciones de emergencia poco frecuentes.

Puedes encontrar los destinos de actualización automática de tus clústeres de las siguientes formas:

Si han pasado 10 días desde que una nueva versión se convirtió en el objetivo de actualización automática de la versión secundaria de tu clúster en el canal de lanzamiento y las actualizaciones automáticas no han empezado en tu clúster, el retraso puede deberse a uno de los siguientes motivos:

  • Tu clúster no cumple los requisitos para las actualizaciones automáticas temporalmente. Esto puede deberse a lo siguiente:
    • El clúster está fuera del periodo de una ventana de mantenimiento configurada.
    • El clúster se encuentra dentro del periodo de una exclusión de mantenimiento.
    • Las actualizaciones automáticas se han pausado porque tu clúster usa funciones de Kubernetes obsoletas que se eliminarán en la próxima versión secundaria.
    • El clúster se actualizó automáticamente a una versión con parche hace menos de 24 horas.
    • El clúster se actualizó automáticamente a una versión secundaria hace menos de 30 días y el objetivo de la actualización automática es una nueva versión secundaria.
  • GKE ha pausado el lanzamiento del nuevo destino de actualización automática por motivos técnicos o empresariales:
    • Se han detectado problemas técnicos en la nueva versión.
    • Se ha aplicado una inmovilización de la producción debido a una temporada de actividad empresarial crucial, como el Black Friday.

La versión de destino de actualización automática recomendada es la versión a la que GKE actualiza gradualmente tus clústeres con el tiempo. De todos los destinos de actualización automática de un canal de lanzamiento, GKE acerca tus clústeres a esta versión cuando realiza actualizaciones automáticas.

A lo largo de varias actualizaciones automáticas, siempre que no haya restricciones que lo impidan, GKE actualiza tus clústeres de forma progresiva hasta alcanzar el objetivo de actualización automática recomendado del canal de lanzamiento. Una vez alcanzado el objetivo, el clúster usará continuamente el objetivo de actualización automática recomendado, y pasará al nuevo objetivo recomendado cuando se publique.

¿Cuál es la versión predeterminada?

Cuando creas un clúster en un canal de lanzamiento, de forma predeterminada, el clúster usa la versión de parche predeterminada para la creación de clústeres en el canal de lanzamiento seleccionado. Sin embargo, puedes especificar otra versión disponible cuando crees un clúster en el canal de lanzamiento.

Los canales de lanzamiento tienen varias versiones secundarias disponibles en un canal de lanzamiento, y la versión predeterminada a veces puede ser uno de los destinos de actualización automática de un canal de lanzamiento.

Acerca de cómo obtener versiones de parche anteriores

Puedes obtener versiones de parche antes con actualizaciones automáticas o manuales siguiendo los métodos que se describen en esta sección.

Actualizaciones automáticas de parches aceleradas

GKE introduce primero una nueva versión de parche en un canal de lanzamiento haciendo que la versión esté disponible para la creación de clústeres y las actualizaciones manuales. Una vez que GKE determina que la versión del parche es apta, la establece como destino de actualización automática, lo que significa que GKE empieza a actualizar automáticamente los clústeres a esta nueva versión del parche. El tiempo que transcurre desde que una versión está disponible hasta que se actualiza automáticamente suele ser de al menos una semana, pero depende del canal de lanzamiento y de las circunstancias específicas para que la versión cumpla los requisitos.

Para obtener más información sobre la disponibilidad de la versión actual, haz lo siguiente:

Si quieres recibir las actualizaciones de parches en cuanto la versión esté disponible y antes de que GKE defina la versión como objetivo de actualización automática en el canal, puedes usar las actualizaciones automáticas de parches aceleradas. Este ajuste puede ser útil si quieres recibir parches de seguridad lo antes posible mediante actualizaciones automáticas.

Debes conocer los riesgos asociados a la actualización automática del clúster con una programación acelerada antes de que GKE determine que los clústeres del canal deben actualizarse automáticamente a la nueva versión del parche. Con esta programación acelerada, se omite un paso del proceso de cualificación de las versiones de parche en los canales de lanzamiento. Todas las versiones de parche, no solo las que incluyen parches de seguridad, se actualizan con esta programación acelerada. Este ajuste no afecta a las actualizaciones de versiones secundarias y solo está disponible para los clústeres registrados en un canal de lanzamiento.

Este ajuste solo afecta al momento en el que GKE actualiza automáticamente un clúster a una nueva versión de parche. GKE sigue respetando las ventanas y exclusiones de mantenimiento, sigue el orden de una secuencia de lanzamiento y aplica cualquier otra práctica estándar que se suela usar en las actualizaciones automáticas.

Para obtener más información sobre cómo configurar esta función, consulta Usar actualizaciones automáticas de parches aceleradas.

También puedes actualizar manualmente tus clústeres si quieres actualizar a una versión de parche específica en cuanto esté disponible y antes de que se establezca como destino de actualización automática.

Ejecutar versiones de parche de un canal más reciente

Además de las versiones de parche disponibles de un canal de lanzamiento, puedes ejecutar versiones de parche de canales de lanzamiento más recientes que aquel en el que esté registrado tu clúster si la versión secundaria está disponible en el canal de lanzamiento del clúster y usas la CLI de gcloud o la API de GKE.

Por ejemplo, si las siguientes versiones estuvieran disponibles en los canales Rápido y Regular:

  • Rápida: 1.23.2-gke.700, 1.22.4-gke.1500
  • Normal: 1.21.4-gke.400, 1.22.1-gke.400

Un clúster inscrito en el canal Regular que ejecute la versión 1.22.1-gke.400 de GKE podría actualizarse manualmente a la versión 1.22.4-gke.1500, pero no a la 1.23.2-gke.700, ya que se trata de una versión secundaria diferente.

Para actualizar manualmente a una versión de parche en un canal más reciente, el plano de control de tu clúster debe ejecutar una versión de parche con la misma versión secundaria. Por ejemplo, si el clúster ejecuta la versión 1.21.3-gke.200, primero debes actualizar manualmente el clúster a una versión con parche disponible en su canal de lanzamiento actual, 1.22.1-gke.400. Después, puedes actualizar el clúster a la versión 1.22.4-gke.1500.

También puedes crear un clúster que ejecute la versión 1.22.4-gke.1500 y esté registrado en el canal Regular.

GKE mantiene el clúster en la versión del parche del canal más reciente hasta que haya disponible una versión de actualización automática más reciente en el canal registrado del clúster.

Novedades de un canal

Para saber qué novedades incluye un canal de lanzamiento, consulta las notas de la versión. Hay notas de la versión independientes para cada canal de lanzamiento, además de las notas de la versión generales.

Canal de lanzamiento Notas de la versión
Canal rápido HTML o Atom feed.
Canal habitual HTML o Atom feed.
Canal estable HTML o Atom feed.

Elegir el mejor canal de lanzamiento para un clúster

Los canales solo incluyen versiones de Kubernetes de disponibilidad general y cada canal representa un nivel diferente de calidad y madurez de las versiones de Kubernetes y GKE. En el siguiente diagrama se muestra el ciclo de adopción de los canales de lanzamiento:

Ciclo de adopción de los canales de lanzamiento

Como se muestra en este diagrama, los canales de lanzamiento disponibles usan versiones que se encuentran en la mitad del ciclo de adopción, como Adoptadores iniciales (canal Rápido), Mayoría inicial (canal Regular) y Mayoría (canal Estable). La primera parte del ciclo de adopción es la de los innovadores, que prueban las funciones más recientes con la versión upstream de Kubernetes. La última parte del ciclo de adopción es la mayoría tardía, en la que usas una versión que está a punto de dejar de estar disponible y debes cambiar a una versión compatible.

En tus entornos de preproducción, usa el canal rápido para las versiones más recientes, donde puedes probar las funciones en cuanto estén disponibles para el público general.

Para las cargas de trabajo de producción que requieren madurez en lugar de funciones más recientes, recomendamos usar el canal habitual (predeterminado) o el canal estable.

  • Si necesitas hacer un seguimiento exhaustivo de las nuevas funciones, te recomendamos que uses el canal Regular, que ofrece un equilibrio entre la estabilidad y la novedad de la versión de software libre de Kubernetes.
  • Si necesitas que la versión sea estable, sobre todo en los clústeres de producción, usa el canal Estable.

GKE actualiza los clústeres a una versión más reciente que cumple los estándares de calidad del canal. Sin embargo, te recomendamos que actualices tus clústeres con antelación, ya que esto te proporcionará lo siguiente:

  • Mayor control de las actualizaciones y alineación con tu horario de trabajo.
  • Mayor predictibilidad, ya que GKE omite la actualización automática de los clústeres que cumplen el objetivo de lanzamiento (es decir, los clústeres que se han actualizado manualmente a la siguiente versión de destino). Los nodos se actualizan automáticamente a la versión recomendada de su canal seleccionado para que coincida con la versión del plano de control y para protegerte frente a vulnerabilidades y desviaciones de versiones no compatibles.

Obtener asistencia a largo plazo con el canal Ampliado

GKE ofrece asistencia a largo plazo para versiones secundarias de Kubernetes a través del canal Extended. Con este canal, puedes mantenerte en una versión secundaria durante un máximo de 24 meses. Después del periodo de asistencia estándar de 14 meses, tu clúster recibirá parches de seguridad durante aproximadamente 10 meses más durante el periodo de asistencia ampliado.

Cómo actualiza GKE automáticamente los clústeres en el canal Extended

En el caso de los clústeres registrados en el canal ampliado, GKE actualiza automáticamente los clústeres de la siguiente manera:

  • Durante el periodo de asistencia estándar: GKE actualiza los clústeres a versiones de parche más recientes de la misma versión secundaria siguiendo la misma cadencia que el canal Regular.
  • Durante el periodo de asistencia ampliado: GKE sigue proporcionando actualizaciones de parches de seguridad para la versión secundaria. Unos dos meses antes de que finalice el periodo de asistencia ampliado, GKE empieza a actualizar los clústeres a la siguiente versión secundaria, a menos que el clúster utilice funciones o APIs obsoletas. Puedes usar las exclusiones de mantenimiento para evitar las actualizaciones de versiones secundarias hasta el final del periodo de asistencia ampliado.
  • Al final del periodo de asistencia ampliado: GKE actualiza todos los clústeres que aún ejecutan la versión secundaria que ya no se admite, independientemente de los problemas que puedan surgir. No puedes configurar exclusiones de mantenimiento después de esta fecha.

Para obtener más información sobre los diferentes periodos de disponibilidad y las actualizaciones que proporciona GKE durante el periodo de asistencia ampliado, consulta el ciclo de vida de la versión secundaria de GKE.

Limitaciones para registrar un clúster en el canal Extended

Consulta las siguientes limitaciones de los clústeres registrados en el canal Extended:

Precios de la asistencia ampliada

Si quieres registrar un clúster en el canal Extended, asegúrate de haber consultado los precios del servicio de asistencia ampliado. Los costes por uso se aplican cuando tu clúster está registrado en el canal ampliado y la versión secundaria de tu clúster entra en el periodo de asistencia ampliado.

Prácticas recomendadas para el canal Extended

Consulta los siguientes casos para saber cómo puedes usar el canal ampliado para minimizar las interrupciones causadas por las actualizaciones de versiones secundarias.

Los casos prácticos admitidos requieren que se lleven a cabo algunas acciones manuales a lo largo del tiempo para sacar el máximo partido al canal. No te recomendamos que registres un clúster en el canal sin tener previsto cambiar a la siguiente versión secundaria, ya que GKE acabará actualizando el clúster a versiones secundarias más recientes con la misma frecuencia que otros canales, y tu clúster podría incurrir en un coste mayor y recibir las nuevas funciones más tarde.

Situaciones admitidas y no admitidas

Para obtener más información sobre los casos prácticos admitidos y no admitidos, consulta la siguiente tabla y el artículo Usar el canal ampliado cuando necesites asistencia a largo plazo. Una marca de verificación () indica un caso práctico admitido:

Situación de actualización Compatible Resumen Tiempo entre cambios de versiones secundarias Se requiere una acción manual
Mantener temporalmente una versión secundaria durante más tiempo Mantenerse en una versión secundaria para mitigar un problema que impide las actualizaciones. La misma frecuencia media, con una interrupción para añadir tiempo en una versión secundaria.
  • Mover temporalmente un clúster al canal Extended y viceversa.
  • Actualiza manualmente el clúster a la nueva versión secundaria cuando esté listo.
Actualizar manualmente la versión secundaria una o dos veces al año Obtén nuevas funciones, pero con actualizaciones menores menos frecuentes, cuando sea óptimo para las cargas de trabajo del clúster. 1-2 veces al año.
  • Actualiza manualmente el clúster a una versión secundaria más reciente.
No hacer nada y recibir pequeñas actualizaciones con la misma frecuencia Recibe las actualizaciones de versión secundaria con la misma frecuencia que otros canales y las nuevas funciones lo más tarde posible. Cada 4 meses de media.
  • Monitorizar las actualizaciones automáticas de versiones secundarias desde versiones no compatibles.

Clústeres no registrados en un canal de lanzamiento

No recomendamos esta opción de configuración debido a las limitaciones de los clústeres que no están registrados en canales de lanzamiento, pero puedes elegir no registrar un clúster estándar en un canal de lanzamiento (conocido como sin canal y anteriormente como estático). No utilices esta opción a menos que los grupos de nodos individuales no se puedan actualizar automáticamente y tengas que actualizar esos nodos manualmente. Si tu clúster no está registrado en un canal de lanzamiento, puedes inhabilitar la actualización automática de nodos en grupos de nodos concretos. Con los canales de lanzamiento, puedes conseguir el mismo resultado a nivel de clúster en todos los grupos de nodos. Sin embargo, independientemente de si están registrados en un canal de lanzamiento, los planos de control de todos los clústeres se actualizan automáticamente. Además, cuando una versión llega al final de la asistencia, los planos de control y los nodos de los clústeres se actualizan automáticamente.

Si quieres evitar que se realicen actualizaciones automáticas en todo el clúster Standard o en todos sus grupos de nodos, te recomendamos que uses una exclusión de mantenimiento con el clúster registrado en un canal de lanzamiento. Con las exclusiones de mantenimiento, puedes inhabilitar las actualizaciones automáticas de nodos en todos los grupos de nodos, mientras que puedes inhabilitarlas a nivel de grupo de nodos si tu clúster no está registrado en un canal de lanzamiento.

Comparación entre clústeres registrados y no registrados en un canal de lanzamiento

Consulta la siguiente tabla para conocer las similitudes y diferencias entre registrar un clúster en un canal de lanzamiento y no hacerlo:

Función El clúster se ha registrado en un canal de lanzamiento El clúster no está registrado en un canal de lanzamiento
Comportamiento de la actualización compartida
Etapas de la actualización Alineado con el canal de lanzamiento correspondiente
  • La misma fecha de inicio de la actualización automática que el canal estable para las versiones secundarias
  • Las mismas versiones secundarias disponibles, versiones de actualización automática de parches y versión predeterminada que el canal Regular
  • Las mismas versiones de parche disponibles que en el canal Rápido para las versiones secundarias disponibles en el canal Habitual
Actualizaciones automáticas de parches aceleradas Disponible No disponible
Control de las interrupciones de grupos de nodos
Ventanas de mantenimiento Disponible Disponible
Exclusiones de la ventana de mantenimiento Ámbitos de exclusión de mantenimiento disponibles:
  • "Sin mejoras" (30 días)
  • "Sin actualizaciones menores" (hasta el final del periodo de asistencia)
  • "No se pueden actualizar las versiones secundarias ni los nodos" (hasta el final del periodo de asistencia)
 Restringido al ámbito "Sin actualizaciones" (30 días)
Secuenciación de lanzamientos Disponible con secuencias basadas en flotas y en ámbitos No disponible
Asistencia a largo plazo Disponible solo con el canal de lanzamiento ampliado No disponible
Autopilot Disponible No disponible

Diferencias entre los clústeres de canal rápido y los clústeres alfa

Los clústeres creados con el canal de lanzamiento rápido no son clústeres alfa. A continuación te explicamos las diferencias:

  • Los clústeres que usan canales de lanzamiento se pueden actualizar y la actualización automática está habilitada y no se puede inhabilitar. Los clústeres alfa no se pueden actualizar.
  • Los clústeres que usan canales de lanzamiento no caducan. Los clústeres alfa caducan al cabo de 30 días.
  • Las APIs alfa de Kubernetes no están habilitadas en los clústeres que usan canales de lanzamiento.

Siguientes pasos