Acerca de los canales de versiones

Usa canales de versiones para Google Kubernetes Engine (GKE) para elegir versiones para tus clústeres con el saldo que elijas entre la disponibilidad y estabilidad de las funciones.

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

Recomendamos inscribir tu clúster en un canal de versiones, ya que esto te brinda el mayor control con respecto al permiso de las exclusiones de mantenimiento, lo que evita tipos específicos de actualizaciones en lugar de todas las actualizaciones y la secuenciación del lanzamiento de actualizaciones de clústeres. Los clústeres de Autopilot solo se pueden inscribir en un canal de versiones.

Si no inscribes tu clúster estándar en un canal de versiones, puedes inhabilitar las actualizaciones automáticas de nodos para grupos de nodos seleccionados y de forma manual administrar las actualizaciones de los nodos en estos grupos de nodos. Sin embargo, todos los planos de control de clústeres se actualizan de forma automática, y cuando una versión alcanza el final de la compatibilidad, los planos de control y los nodos del clúster se actualizan de forma automática, independientemente de la inscripción al canal de versiones. Para obtener más información, consulta la comparación entre los clústeres inscritos y los que no están inscritos en un canal de versiones.

¿Qué canales están disponibles?

En la siguiente tabla, se explican las propiedades de los canales de versiones disponibles, cada uno ofrece una compensación entre la disponibilidad de las características y la estabilidad. Todos los canales ofrecen versiones compatibles de GKE y se consideran de disponibilidad general (DG), (aunque es posible que las características individuales no siempre sean de DG, como se indica). Las versiones de Kubernetes en estos canales son oficiales e incluyen la APIs de Kubernetes Beta y de disponibilidad general.

Canal Disponibilidad de la nueva versión de Kubernetes Cuándo usar este canal
Rápido Varias semanas después de la disponibilidad general de código abierto ascendente* Obtén la versión más reciente de Kubernetes lo antes posible y usa las características nuevas de GKE tan pronto tengan DG. GKE actualiza tu clúster con frecuencia para permanecer en la última versión de parche disponible y entregar capacidades más nuevas de Kubernetes. Los clústeres suscritos al canal rápido usan versiones de DG, pero recomendamos usar el canal rápido para probar las versiones más recientes de Kubernetes y la API en entornos de preproducción.
Regular (predeterminado) Entre 2 y 3 meses después del lanzamiento en el canal rápido* Accede a las características de GKE y Kubernetes poco después de su lanzamiento, pero en una versión calificada durante un período más largo. Ofrece un equilibrio entre la disponibilidad de las funciones y la estabilidad de las versiones, y es lo que recomendamos para la mayoría de los usuarios.
Estable Entre 2 y 3 meses después del lanzamiento en el canal regular* Prioriza la estabilidad por encima de las nuevas funciones. GKE lanza los cambios y las versiones nuevas en este canal por último, después de validarse en los canales rápidos y regulares, lo que permite más tiempo para la validación.
Extendido Alineado con el canal regular Usa este canal para obtener asistencia a largo plazo y mantener un clúster ejecutando una versión secundaria durante el mayor tiempo posible. Para obtener más información, consulta Obtén asistencia a largo plazo con el canal extendido.
Ningún canal (no se recomienda) Alineado con el canal regular Sin embargo, no la recomendamos. El plano de control y los nodos se actualizan automáticamente en consonancia con los canales Regular y Estable. Puedes usar esta opción de configuración cuando necesites inhabilitar las actualizaciones automáticas de nodos a nivel del grupo de nodos. Como alternativa, con los canales de versiones, puedes inhabilitar las actualizaciones automáticas de nodos a nivel del clúster. Para obtener más detalles, consulta la comparación entre los clústeres inscritos y los que no están inscritos en un canal de versiones.

Cuando inscribes un clúster en un canal de versiones, ese clúster se actualiza automáticamente a partir de la fecha especificada en la columna Actualizar automáticamente del programa de lanzamientos de GKE o después de ella.

Cuando una versión acumuló un uso y demostró estabilidad en los clústeres en el canal rápido, se asciende al canal regular. Con el tiempo, la versión asciende al canal estable, que solo recibe actualizaciones de alta prioridad. Cada promoción señala un nivel gradual de estabilidad y preparación para la producción, según el rendimiento observado de los clústeres que ejecutan esa versión.

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

¿Qué versiones están disponibles en un canal?

Cada canal de versiones ofrece varias versiones secundarias. Estas versiones cumplieron con los estándares de calificación para ese canal específico. 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 versiones, sigue las instrucciones para visualizar las versiones predeterminadas y disponibles de los canales de versiones.

  • Las nuevas versiones de parches estarán disponibles al menos una semana antes de que se conviertan en un destino de actualización automática para todos los canales.
  • Nuevas versiones secundarias disponibles:
    • al menos dos semanas antes de convertirse en destino 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 disponible recientemente antes de actualizar el entorno de producción. Por ejemplo, puedes suscribirte a las notificaciones de actualización para recibir información sobre las versiones recién disponibles y, luego, actualizar de forma proactiva un entorno de preproducción a la nueva versión antes de que se convierta en el destino de actualización automática para los clústeres en 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 la actualización, te recomendamos que uses exclusiones de mantenimiento.

Después de que una versión secundaria esté disponible en un canal de versiones, seguirá disponible en ese canal de versiones para clústeres nuevos o existentes hasta que alcance su fecha de finalización del soporte.

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

Con el tiempo, GKE actualiza automáticamente los clústeres 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 versión nueva. GKE considera si tu clúster tiene políticas de mantenimiento o restricciones que impiden las actualizaciones automáticas, y no ignorará esos motivos, excepto en situaciones de emergencia poco frecuentes.

Puedes encontrar los objetivos de actualización automática para tus clústeres de las siguientes maneras:

Si pasaron 10 días después de que una versión nueva se convirtió en objetivo de actualización automática para la versión secundaria de tu clúster en el canal de versiones y no se iniciaron las actualizaciones automáticas para tu clúster, el retraso puede deberse a uno de los siguientes motivos:

  • Por el momento, tu clúster no es apto para realizar actualizaciones automáticas. Esto puede suceder por los siguientes motivos:
    • El clúster está fuera del período de un período de mantenimiento configurado.
    • El clúster se encuentra dentro del período de una exclusión de mantenimiento.
    • Las actualizaciones automáticas se Pausan porque tu clúster usa características de Kubernetes obsoletas que se quitan en la próxima versión secundaria.
    • El clúster se actualizó de forma automática a una versión de 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 destino de la actualización automática es una versión secundaria nueva.
  • GKE detuvo el lanzamiento del nuevo destino de actualización automática por razones técnicas o comerciales:
    • Se descubrieron problemas técnicos con la versión nueva.
    • Se suspende la producción debido a una temporada comercial crítica, 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 en un canal de versiones, GKE acerca tus clústeres a esta versión cuando realiza actualizaciones automáticas.

En varias actualizaciones automáticas, y sin restricciones que impidan las actualizaciones automáticas, GKE actualiza tus clústeres de forma progresiva hasta acercarse al objetivo de actualización automática recomendado del canal de versiones, hasta que el clúster alcance el objetivo. Después de alcanzar el destino, tu clúster usará de forma continua el destino de actualización automática recomendado existente y se cambiará al nuevo destino recomendado cuando se lance.

¿Cuál es la versión predeterminada?

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

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

Acerca de cómo obtener versiones de parche antes

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

Actualizaciones automáticas de parches aceleradas

Primero, GKE introduce una nueva versión de parche en un canal de versiones haciendo que la versión esté disponible para la creación de clústeres nuevos y las actualizaciones manuales. Después de que GKE determina que la versión de parche está calificada, establece la nueva versión de parche como destino de actualización automática, lo que significa que GKE comienza a actualizar automáticamente los clústeres a esta nueva versión de parche. Por lo general, el período entre la disponibilidad de la versión y las actualizaciones automáticas es de al menos una semana, pero depende del canal de versiones y de las circunstancias específicas que califican la versión.

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

Si quieres recibir actualizaciones de parches en cuanto la versión esté disponible y antes de que GKE establezca la versión como destino de actualización automática en el canal, puedes usar las actualizaciones automáticas de parches aceleradas. Este parámetro de configuración puede ser útil si deseas recibir parches de seguridad lo antes posible a través de actualizaciones automáticas.

Debes comprender los riesgos asociados con la actualización automática del clúster en un programa acelerado antes de que GKE determine que los clústeres del canal se deben actualizar automáticamente a la nueva versión de parche. Este programa acelerado omite un paso en el proceso de calificación de las versiones de parche en los canales de versiones. Todas las versiones de parche, no solo las que incluyen parches de seguridad, se actualizan con este programa acelerado. Este parámetro de configuración no afecta las actualizaciones de versiones secundarias y solo está disponible para los clústeres inscritos en un canal de versiones.

Este parámetro de configuración solo afecta el momento en que GKE actualiza automáticamente un clúster a una nueva versión de parche. GKE sigue cumpliendo con los períodos de mantenimiento y las exclusiones, respeta el orden de una secuencia de lanzamiento y aplica cualquier otra práctica estándar que se suela usar para las actualizaciones automáticas.

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

Como alternativa, puedes actualizar tus clústeres de forma manual si deseas 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.

Ejecuta versiones de parche desde un canal más reciente

Además de las versiones de parche disponibles que se indican para un canal de versiones, puedes ejecutar versiones de parche desde los canales de versiones más recientes de aquellos en los que tu clúster está inscrito si la versión secundaria está disponible en el canal de versiones del clúster y usas gcloud CLI o la API de GKE.

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

  • Rápido: 1.23.2-gke.700, 1.22.4-gke.1500
  • Regular: 1.21.4-gke.400, 1.22.1-gke.400

Un clúster inscrito en el canal Regular que ejecuta la versión de GKE 1.22.1-gke.400 puede actualizarse manualmente a 1.22.4-gke.1500, pero no a 1.23.2-gke.700, ya que es 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 1.21.3-gke.200, primero debes actualizarlo de forma manual a una versión de parche disponible en su canal de versiones actual, 1.22.1-gke.400. Luego, puedes actualizar el clúster a 1.22.4-gke.1500.

También puedes crear un clúster nuevo que ejecute 1.22.4-gke.1500 y esté inscrito en el canal Regular.

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

Descubre las novedades de un canal

Para conocer las novedades de un canal de versiones, consulta las notas de la versión. Hay notas de la versión distintas para cada canal de versiones, además de las notas generales de la versión.

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

Elige el mejor canal de versiones para tu clúster

Los canales incluyen solo versiones de DG de Kubernetes, y cada canal representa un nivel diferente de calidad y madurez de las versiones de Kubernetes y GKE. En el siguiente diagrama, se ilustra el ciclo de adopción para los canales de versiones:

Ciclo de adopción de los canales de versiones

Como se muestra en este diagrama, los canales de versiones disponibles usan versiones en el medio del ciclo de adopción, incluidos los usuarios pioneros (canal rápido), Primera mayoría (canal regular) y Mayoría (canal estable). La parte más temprana del ciclo de adopción son los Innovadores, que prueban las funciones más recientes con la versión ascendente de Kubernetes. La última parte del ciclo de adopción es la Última mayoría, en la que usas una versión que está a punto de darse de baja y debes realizar la transición a una versión compatible.

En tus entornos de producción previa, usa el canal rápido para versiones más recientes en las que puedes probar funciones en cuanto estén disponibles de forma general.

Para las cargas de trabajo de producción que requieren cierto desarrollo de la funcionalidad más nueva, recomendamos usar el canal regular (predeterminado) o el canal estable.

  • Si necesitas realizar un seguimiento detallado de las características nuevas, considera usar el canal regular, que ofrece un equilibrio entre la estabilidad y la actualización de la versión de OSS de Kubernetes.
  • Si tu requisito es el desarrollo, en especial para los clústeres de producción, usa el canal Estable.

GKE actualiza los clústeres a una versión más reciente que cumpla con el estándar de calidad del canal. Sin embargo, te recomendamos actualizar tus clústeres con anticipación, ya que esto te proporciona lo siguiente:

  • Mejor control de las actualizaciones y alineación con tu horario laboral.
  • Mayor capacidad de predicción, ya que GKE omite los clústeres de actualización automática que cumplen con el objetivo de versión (es decir, clústeres que se actualizaron de forma manual a la siguiente versión de destino). Los nodos se actualizan de forma automática a la versión recomendada en el canal seleccionado para alinearse con la versión del plano de control y protegerte de las vulnerabilidades y el sesgo de versión no compatible.

Obtén asistencia a largo plazo con el canal extendido

GKE proporciona asistencia a largo plazo para las versiones secundarias de Kubernetes a través del canal extendido. Con este canal, puedes usar una versión secundaria por hasta 24 meses. Después del período de asistencia estándar de 14 meses, tu clúster recibe parches de seguridad durante aproximadamente 10 meses más durante el período de asistencia extendida.

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

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

  • Durante el período de asistencia estándar: GKE actualiza los clústeres a versiones de parche más recientes de la misma versión secundaria con la misma cadencia que el canal regular.
  • Durante el período de asistencia extendida: GKE continúa proporcionando actualizaciones de parches de seguridad para la versión secundaria. Aproximadamente 2 meses antes del final del período de asistencia extendida, GKE comienza a actualizar los clústeres a la siguiente versión secundaria, a menos que el clúster use funciones o APIs obsoletas. Puedes usar exclusiones de mantenimiento para evitar actualizaciones de versiones secundarias hasta el final de la asistencia extendida.
  • Al final del período de asistencia extendida: GKE actualiza los clústeres que ejecutan la versión secundaria que ya no es compatible, independientemente de los problemas de bloqueo. No puedes configurar exclusiones de mantenimiento después de esta fecha.

Para obtener más información sobre los diferentes períodos de disponibilidad y las actualizaciones que proporciona GKE durante el período de asistencia extendida, consulta el ciclo de vida de la versión secundaria de GKE.

Limitaciones para inscribir un clúster en el canal extendido

Revisa las siguientes limitaciones para los clústeres inscritos en el canal Extended:

Precios de la asistencia extendida

Si deseas inscribir un clúster en el canal extendido, asegúrate de haber revisado los precios de la asistencia extendida. Se aplican costos de pago por uso cuando el clúster está inscrito en el canal extendido y la versión secundaria del clúster ingresa al período de asistencia extendida.

Prácticas recomendadas para el canal Extendido

Revisa las siguientes situaciones para comprender cómo puedes usar el canal extendido y minimizar las interrupciones causadas por las actualizaciones de versiones secundarias.

Las situaciones admitidas requieren alguna acción manual con el tiempo para obtener el mayor beneficio del canal. No te recomendamos que inscribas un clúster en el canal sin planes para pasar a la siguiente versión secundaria, ya que GKE eventualmente actualizará el clúster a versiones secundarias más recientes con la misma frecuencia que otros canales, y es posible que tu clúster incurra en un mayor costo y reciba las nuevas funciones en último lugar.

Situaciones compatibles y no compatibles

Para obtener más información sobre las situaciones admitidas y no admitidas, revisa la siguiente tabla y consulta Usa el canal extendido cuando necesites asistencia a largo plazo para obtener más detalles. Una marca de verificación () indica una situación admitida:

Situación de actualización Admitido Resumen Tiempo entre cambios de versiones secundarias Acción manual obligatoria
Permanece temporalmente en una versión secundaria durante más tiempo Permanece en una versión secundaria para mitigar un problema que impide las actualizaciones. La misma frecuencia promedio, con una interrupción para dedicar tiempo adicional a una versión secundaria.
  • Mover temporalmente un clúster al canal extendido y desde él
  • Actualiza el clúster de forma manual a la nueva versión secundaria cuando esté listo.
Actualiza manualmente la versión secundaria de 1 a 2 veces al año Obtén funciones nuevas, pero con actualizaciones secundarias menos frecuentes, cuando sea óptimo para las cargas de trabajo del clúster. De 1 a 2 veces al año
  • Actualiza el clúster de forma manual a una versión secundaria más reciente.
No hacer nada y recibir actualizaciones menores con la misma frecuencia Recibe actualizaciones de versiones secundarias con la misma frecuencia que otros canales y funciones nuevas lo más tarde posible. Cada 4 meses, en promedio
  • Supervisar las actualizaciones automáticas de versiones secundarias desde versiones no compatibles

Clústeres no inscritos en un canal de versiones

No recomendamos esta opción de configuración debido a las limitaciones de los clústeres que no están inscritos en canales de versiones, pero puedes elegir no inscribir un clúster estándar en un canal de versiones (conocido como sin canal y, anteriormente, como estático). No uses esta opción a menos que los grupos de nodos individuales no se puedan actualizar de forma automática y, en su lugar, debas actualizar esos nodos de forma manual. Si tu clúster no está inscrito en un canal de versiones, puedes inhabilitar la actualización automática de los nodos para los grupos de nodos seleccionados. Con los canales de versiones, puedes lograr el mismo resultado a nivel del clúster en todos los grupos de nodos. Sin embargo, independientemente de la inscripción al canal de versiones, todos los planos de control de clústeres se actualizan de forma automática, y cuando una versión alcanza el final de la compatibilidad, los planos de control y los nodos del clúster se actualizan de forma automática.

Te recomendamos que, si deseas evitar las actualizaciones automáticas para todo el clúster estándar o todos sus grupos de nodos, uses una exclusión de mantenimiento con tu clúster inscrito en un canal de versiones. Con las exclusiones de mantenimiento, puedes inhabilitar las actualizaciones automáticas de nodos para todos los grupos de nodos, mientras que puedes inhabilitarlas a nivel de grupo de nodos si el clúster no está inscrito en un canal de versiones.

Comparación entre los clústeres inscritos y los que no están inscritos en un canal de versiones

Revisa la siguiente tabla para comprender las similitudes y diferencias entre la inscripción y la no inscripción de tu clúster en un canal de versiones:

Función Clúster inscrito en un canal de versiones El clúster no está inscrito en un canal de versiones
Comportamiento de la actualización compartida
Cronograma de actualización Alineación con el canal de versiones respectivo
  • La misma fecha de inicio de 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 el canal rápido para las versiones secundarias disponibles en el canal regular
Actualizaciones automáticas de parches aceleradas Disponible No disponible
Control de la interrupción del grupo de nodos
Períodos de mantenimiento Disponible Disponible
Exclusiones de mantenimiento Permisos de exclusión de mantenimiento disponibles:
  • "Sin actualizaciones" (30 días)
  • “Sin actualizaciones secundarias” (hasta el final de la asistencia)
  • “Sin actualizaciones secundarias ni de nodos” (hasta el final de la asistencia)
 Restringido al permiso “Sin actualizaciones” (30 días)
Secuenciación de lanzamiento Disponible con secuencias basadas en flotas y en permisos No disponible
Asistencia a largo plazo Solo está disponible en el canal de versiones extendido No disponible
Autopilot Disponible No disponible

Diferencias entre los clústeres de canales rápidos y los clústeres Alfa

Los clústeres creados con el canal de versiones rápido no son clústeres Alfa. Estas son las diferencias:

  • Los clústeres que usan canales de versiones se pueden actualizar, además, 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 versiones no caducan. Los clústeres Alfa se vencen después de 30 días.
  • Las API de Kubernetes Alfa no están habilitadas en clústeres que usan canales de versiones.

¿Qué sigue?