Canales de versiones

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En este tema, se presentan los canales de versiones, que proporcionan las prácticas recomendadas de Google Kubernetes Engine (GKE) para realizar el control de versiones y actualizar tus clústeres de GKE.

Descripción general

Kubernetes lanza actualizaciones con frecuencia para entregar actualizaciones de seguridad, solucionar problemas conocidos y presentar características nuevas. Los canales de versiones ofrecen a los clientes la capacidad de balancear la estabilidad y el conjunto de atributos de la versión implementada en el clúster.

Cuando inscribes un clúster nuevo en un canal de versiones, Google administra automáticamente la versión y la cadencia de actualización del clúster y sus grupos de nodos. Todos los canales ofrecen versiones compatibles de GKE y se consideran de disponibilidad general (GA) (aunque es posible que las características individuales no siempre sean de GA, como se indica). Las versiones de Kubernetes en estos canales son oficiales e incluyen la API de Kubernetes Beta y de disponibilidad general (como se indica). Las versiones nuevas de Kubernetes se lanzan por primera vez en el canal rápido y, con el tiempo, ascienden al canal regular y estable. Esto te permite suscribir el clúster a un canal que cumpla con tus necesidades empresariales, de estabilidad y funcionalidad.

De forma predeterminada, los clústeres nuevos creados en GKE están inscritos en el canal de versiones Regular.

¿Qué canales están disponibles?

Están disponibles los siguientes canales de versiones. Cada uno tiene una cadencia de actualización diferente y ofrece una compensación entre la disponibilidad de la característica y la renovación de la actualización. Si bien cada canal tiene un estándar de calificaciones diferente, todos los canales ofrecen versiones de DG probadas de Kubernetes.

Canal Disponibilidad de la nueva versión de Kubernetes Propiedades
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 disponibilidad general. Tu clúster se actualiza con frecuencia para permanecer en la última versión de parche disponible y entregar capacidades más nuevas de Kubernetes. Aunque los clústeres suscritos al canal rápido usan versiones de GA, este se usa mejor para probar las versiones más recientes de Kubernetes y la API en entornos de preproducción. Como el canal rápido proporciona las versiones de GKE más recientes, estas versiones se excluyen del ANS de GKE y pueden contener problemas sin soluciones alternativas conocidas.
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 características y la estabilidad de las actualizaciones, 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 funcionalidades. Los cambios y las versiones nuevas de este canal se lanzan en último lugar, después de validarse en los canales rápidos y regulares, lo que permite más tiempo para la validación.

*Los programas de versiones exactos dependen de varios factores, como la versión de código abierto y el programa de parches, y, por lo tanto, están sujetos a cambios. Para mantenerte al día con la información más reciente, revisa las notas de la versión de GKE o suscríbete al feed RSS de tu canal.

Cuando inscribes un clúster en un canal de actualización, se actualiza de manera automática cuando hay una versión nueva disponible en ese canal.

Cuando una versión acumuló un uso acumulativo y demostró estabilidad en el canal rápido, se asciende al canal regular. Por último, 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.

Sin canal

Para lograr una administración más directa del plano de control y las versiones de nodos del clúster, puedes elegir no inscribir el clúster en un canal de versiones (es decir, “sin canal”) si especificas una versión estática de GKE. Sin embargo, te recomendamos que inscribas tu clúster en un canal de versiones, ya que automáticamente garantiza la seguridad, el rendimiento y la estabilidad. Con los canales de versiones, también puedes controlar el tiempo y el alcance de las actualizaciones mediante los períodos de mantenimiento y exclusiones.

Actualizaciones del plano de control

Incluso si el clúster no está inscrito en un canal de versiones, GKE actualizará de forma periódica el plano de control del clúster a versiones más recientes. GKE actualizará los planos de control a la siguiente versión secundaria en la fecha de inicio de actualizaciones programadas. Consulta las notas de la versión para obtener la información más reciente sobre las actualizaciones programadas.

Actualizaciones de nodos

Cuando ejecutas un clúster con una versión estática (“sin canal”), puedes mantener habilitada la actualización automática de nodos o inhabilitar la actualización automática de nodos y administrar la estrategia de actualización de nodos. Recomendamos dejar habilitada la actualización automática de nodos para que las versiones de nodos se actualicen de forma automática después de las actualizaciones del plano de control.

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

Cada canal de versiones ofrece una versión predeterminada, seleccionada de un conjunto de versiones disponibles para ese canal. Estas versiones cumplieron con los estándares de calificación para ese canal específico. Con el tiempo, GKE actualiza los clústeres a la versión predeterminada de forma automática.

  • Las nuevas versiones de parches estarán disponibles al menos una semana antes de que se conviertan en predeterminadas para todos los canales.
  • Nuevas versiones secundarias disponibles:
    • al menos dos semanas antes de convertirse en el canal rápido como opción predeterminada.
    • al menos cuatro semanas antes de convertirse en las predeterminadas para los canales normal y estable.

Puedes probar una versión de GKE disponible recientemente antes de actualizar el entorno de producción. Por ejemplo, puedes suscribirte anotificaciones 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 la versión predeterminada.

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.

Para las versiones 1.19 y posteriores, después de que una versión 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 final del ciclo de vida.

Visualiza las versiones predeterminadas y disponibles de los canales de versiones

Para ver las versiones predeterminadas y disponibles para los canales de versiones, ejecuta el siguiente comando. Para ello, reemplaza COMPUTE_ZONE por tu zona de procesamiento:

gcloud container get-server-config --format "yaml(channels)" --zone COMPUTE_ZONE

¿Qué sucede cuando una versión nueva se convierte en predeterminada en un canal de versiones?

Cuando una nueva versión de GKE se vuelve predeterminada en un canal de versiones, ocurre lo siguiente:

  • Los clústeres nuevos se crean con la versión predeterminada nueva en el canal de versiones seleccionado.
  • Los clústeres aptos existentes se actualizan de forma automática dentro de los 10 días posteriores a una versión nueva en su canal de versiones predeterminado.

Si pasan 10 días después de que una versión nueva se vuelve predeterminada en el canal de versiones y no se inician 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ó de forma automática a una versión secundaria hace menos de 30 días y la nueva versión predeterminada es una versión secundaria nueva.
  • GKE detuvo el lanzamiento de la nueva versión predeterminada por razones técnicas o empresariales:
    • 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.

Ejecuta versiones de parche desde un canal más reciente

Además de las versiones disponibles que se encuentran disponibles para un canal de versiones, GKE proporciona acceso limitado a las versiones de parche de los canales de versiones menos consolidadas. Un clúster inscrito en un canal de versiones puede usar versiones de parche de un canal más nuevo.si laversión secundaria En el canal más reciente, es la misma que la versión secundaria disponible en el propio canal de versiones del clúster.

Por ejemplo, si las siguientes versiones estaban disponibles en los canales rápidos y normales:

  • 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 a 1.22.4-gke.1500, pero no a 1.23.2- gke.700, ya que es una versión secundaria diferente. También se puede crear un clúster nuevo que ejecute 1.22.4-gke.1500 y se inscriba en el canal Regular.

El clúster permanecerá en la versión del parche del canal menos consolidada hasta que la versión predeterminada del canal en la que está inscrito se convierta en una versión superior a la del clúster. En ese momento, el clúster se actualizará de forma automática a la versión predeterminada.

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.

¿Qué canal debo usar?

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

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.

Inscribe un clúster en un canal de versiones

Puedes inscribir un clúster nuevo o existente en un canal de versiones.

Inscribe clústeres nuevos

Puedes crear y, luego, inscribir un clúster nuevo en un canal de versiones mediante la CLI de gcloud o Google Cloud Console. De forma predeterminada, los clústeres nuevos se inscriben automáticamente en el canal de versiones regular.

Console

Para los clústeres de GKE Standard, puedes especificar un canal diferente durante la creación en la consola de Google Cloud.

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

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. En la sección Estándar, haz clic en Configurar.

  4. En Versión del plano de control, la opción Canal de versiones se selecciona de forma predeterminada.

  5. En la lista desplegable Canal de versiones, selecciona un canal de versiones en el cual inscribir el clúster o deja el valor predeterminado de Canal regular.

  6. Continúa creando el clúster como desees.

  7. Haz clic en Crear.

gcloud

Para crear e inscribir un clúster estándar en un canal de versiones específico, ejecuta el siguiente comando:

gcloud container clusters create CLUSTER_NAME \
    --zone COMPUTE_ZONE \
    --release-channel CHANNEL \
    ADDITIONAL_FLAGS

Para crear e inscribir un clúster de Autopilot en un canal de versiones específico, ejecuta el siguiente comando:

gcloud container clusters create-auto CLUSTER_NAME \
    --region=COMPUTE_REGION
    --release-channel CHANNEL \
    ADDITIONAL_FLAGS

Reemplaza lo siguiente:

  • CLUSTER_NAME: Es el nombre del clúster nuevo.
  • Para los clústeres regionales, usa la marca --region COMPUTE_REGION y especifica la región del clúster.
  • En los clústeres zonales, usa la marca --region COMPUTE_ZONE y especifica la zona para tu clúster.
  • CHANNEL: es el tipo de canal de versiones: uno de rapid, regular o stable.
  • ADDITIONAL_FLAGS son cualquier otra marca que necesites especificar cuando creas el clúster. Si deseas obtener la lista completa de marcas opcionales para los clústeres estándar, consulta la documentación de gcloud container clusters create. Si deseas obtener la lista completa de marcas opcionales para los clústeres de Autopilot, consulta la documentación de gcloud container clusters create-auto.

Inscribe clústeres existentes

Puedes inscribir un clúster existente en un canal de versiones, siempre que la versión del plano de control del clúster se pueda actualizar al valor predeterminado del canal de versiones. Esto significa que la versión predeterminada del canal de versiones debe ser igual o superior a una versión secundaria mayor que la versión del plano de control existente.

Para inscribir, actualiza el canal de versiones del clúster al CHANNEL deseado.

Busca el canal de tu clúster

Puedes determinar el canal de versiones del clúster con gcloud o Google Cloud Console.

Consola

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

    Ir a Google Kubernetes Engine

  2. Haz clic en el nombre del clúster que deseas inspeccionar.

  3. En Aspectos básicos del clúster, verifica el valor en el campo Canal de versiones (por ejemplo, Canal regular).

gcloud

gcloud container clusters describe CLUSTER_NAME \
    --zone COMPUTE_ZONE --format="value(releaseChannel.channel)"

Reemplaza lo siguiente:

Selecciona un canal de versiones nuevo

La migración entre canales de versiones es compatible en situaciones limitadas.

Se admite una transición que dé como resultado una única actualización de la versión secundaria, como la migración de Estable a Regular.

Las versiones inferiores, como la migración de Regular a Estable, no son posibles debido al riesgo de cambiar a versiones secundarias de Kubernetes. Del mismo modo, no se admiten las actualizaciones de más de una versión secundaria, como la migración de Estable a Rápido.

Para seleccionar un canal de versiones nuevo, actualiza el canal de versiones del clúster al CHANNEL deseado.

En los casos en los que no se admite la selección de un canal de versiones nuevo, te recomendamos crear un clúster nuevo en el canal deseado y migrar tus cargas de trabajo. Si prefieres usar tu clúster existente, puedes seguir las instrucciones para anular la suscripción a un canal de versiones, a fin de que el canal de lanzamiento de destino haga disponible la versión secundaria de Kubernetes de tu clúster y, luego, sigue las instrucciones para inscribir el clúster existente en el canal de versiones de destino.

Anula la suscripción a un canal de versiones

Si decides anular la suscripción a un canal, los grupos de nodos del clúster seguirán teniendo la actualización y la reparación automáticas habilitadas, incluso después de inhabilitar los canales de versiones. Una vez que un clúster ya no está suscrito a un canal de versiones, puedes inhabilitar la actualización automática de los nodos y, luego, inhabilitar la reparación automática de nodos de forma manual.

Cuando se anula la suscripción de un clúster a un canal de versiones, las actualizaciones manuales aún están sujetas a las siguientes limitaciones:

Para anular la suscripción a un canal de versiones, actualiza el canal de versiones del clúster a un valor de None:

gcloud container clusters update CLUSTER_NAME \
    --release-channel None

Actualiza el canal de versiones del clúster

Para editar la propiedad del canal de versiones de un clúster existente, ejecuta el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --release-channel CHANNEL

Reemplaza lo siguiente:

  • CLUSTER_NAME: El nombre de tu clúster.
  • CHANNEL: El canal de versiones deseado, que puede ser rapid, regular, stable o None.

Advertencias

Ten en cuenta las siguientes advertencias cuando uses canales de versiones.

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?