Canales de versiones

En este tema, se presentan los canales de versiones, que proporcionan las prácticas recomendadas de Google Kubernetes Engine (GKE) para controlar 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 e ingresar 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 (aunque es posible que las características individuales no siempre sean de disponibilidad general, como se indica). Las versiones de Kubernetes en estos canales son oficiales e incluyen la API de Kubernetes Beta y la API de Kubernetes 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 en un canal que cumpla con tus necesidades empresariales, de estabilidad y funcionalidad.

¿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 una barra de calificación diferente, todos los canales ofrecen versiones de Kubernetes probadas por Google Analytics.

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.
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 sobre la funcionalidad nueva. 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.

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

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

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

Cada canal de versiones ofrece una versión predeterminada y un conjunto de versiones disponibles para ese canal, lo que te permite calificar la operabilidad de tus cargas de trabajo con versiones nuevas disponibles antes de actualizar el entorno de producción. Estas versiones cumplieron con la barra de calificación para ese canal específico.

  • Los nuevos lanzamientos de parches estarán disponibles una semana antes de que se conviertan en predeterminados.
  • Los nuevos lanzamientos secundarios están disponibles cuatro semanas antes de que se conviertan en predeterminados.

GKE recomienda probar las versiones disponibles para mitigar las interrupciones relacionadas con la actualización. Suscribirse a un entorno de preproducción para recibir todas las versiones disponibles en un canal es un enfoque de este tipo. En el caso de que se requiera más tiempo para realizar la prueba o la validación, GKE recomienda usar ventanas de exclusión a fin de posponer la actualización automática.

GKE actualiza los clústeres a la versión predeterminada de manera gradual Si se necesita más control sobre el proceso de actualización, recomendamos actualizar con anticipación a una versión disponible. El proceso de actualización automática de GKE no modifica los recursos del clúster cuando esos recursos tienen una versión igual o mayor que el objetivo de actualización automática. Los clústeres o nodos se pueden actualizar de forma manual por adelantado para omitir el proceso de actualización automática.

Para ver las versiones predeterminadas y disponibles para los canales de versiones, ejecuta el siguiente comando, reemplazando compute-zone por tu zona de procesamiento:

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

Cómo descubrir 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 GA de Kubernetes, y cada canal representa un nivel diferente de calidad y madurez de las actualizaciones 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

Recomendamos usar el canal rápido para cargas de trabajo que se basan en las API y funciones de Kubernetes más recientes, y para el acceso anticipado a fin de probar y validar los lanzamientos nuevos antes de que las versiones se desarrollen y se promocionen en los canales regular y estable.

Para las cargas de trabajo de producción que requieren madurez sobre 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 del SO de Kubernetes.
  • Si tu requisito es la madurez, 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 la barra de calidad del canal. Sin embargo, te recomendamos actualizar tus clústeres con anticipación, ya que esto 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 actualizació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 (instancia principal) 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 gcloud o Google Cloud Console.

Console

  1. Visita el menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Haz clic en el botón Crear clúster.

  3. En Versión principal, selecciona Canal de versiones.

  4. En la lista desplegable del Canal de versiones, selecciona un canal de versiones para inscribir el clúster.

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

  6. Haz clic en Crear.

gcloud

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

gcloud container clusters create cluster-name \
    --zone compute-zone \
    --release-channel channel \
    additional-flags

Reemplaza lo siguiente:

  • cluster-name: Es el nombre del clúster nuevo.
  • compute-zone: la zona de procesamiento de tu clúster.
  • channel: es el tipo de canal de versiones: rapid, regular o stable.
  • additional-flags: cualquier otra marca que debes especificar cuando creas tu clúster. Para ver la lista completa de marcas opcionales, consulta la documentación de gcloud container clusters create.

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 que la versión del plano de control existente, o una inferior.

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.

Console

  1. Dirígete al menú de Google Kubernetes Engine en Google Cloud Console.

    Ir al menú Google Kubernetes Engine

  2. Selecciona el clúster deseado.

  3. En Detalles del clúster, lee el valor del 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.

Cambiar a una versión inferior, como la migración de Regular a Estable, no es posible debido al riesgo de cambiar a versiones anteriores 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.

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.

Para anular la suscripción, actualiza el canal de versiones del clúster con un channel de Ninguno.

Actualiza el canal de versiones de clústeres

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.

Recuperar asignaciones de actualización (secuencia de comandos de ejemplo)

Puedes usar la siguiente secuencia de comandos de muestra a fin de recuperar los objetivos de actualización para tus clústeres. La secuencia de comandos realiza las siguientes tareas:

  • Extrae las últimas versiones válidas de cada canal de versiones con la API de get-server-config.
  • Verifica las versiones actuales para el plano de control y el grupo de nodos del clúster. Si la versión actual es anterior a la última versión válida, la secuencia de comandos iniciará una organización de actualización personalizada (plano de control y grupos de nodos). Si el clúster no usa canales de versiones, la secuencia de comandos compara la última versión estable válida.

Secuencia de comandos de muestra: recupera las asignaciones de actualización del clúster

#!/bin/bash

# semver_lt checks whether the first semver is less than the second semver.
# It returns 1 if it is less than, and 0 otherwise.
semver_lt() {
    # Get the smaller version by sorting them in ascending semver
    # and grabbing the first line.
    smaller=$(printf "$1\n$2" | sort -V | head -n1)
    if [[ ${1} == "${smaller}" && ${1} != ${2} ]]; then
            return 1
    fi
    return 0
}

# get_latest_valid gets the latest valid version for a release channel.
get_latest_valid() {
        channel=$1
        echo $(gcloud container get-server-config \
        --format="table(channels:format='table(channel,validVersions)')" |\
        grep ${channel} | cut -d"'" -f 2)
}

upgrade_master() {
    echo "Cluster $1 needs to upgrade to $2."
    # Actuate master upgrade.
}

upgrade_np() {
    echo "Node pool $1/$2 needs to upgrade to $3."
    # Actuate node pool upgrade.
}

# Get the latest valid channel versions from server-config.
stable_target=$(get_latest_valid "STABLE")
regular_target=$(get_latest_valid "REGULAR")
rapid_target=$(get_latest_valid "RAPID")
echo "stable version from gcloud: ${stable_target}"
echo "regular version from gcloud: ${regular_target}"
echo "rapid version from gcloud: ${rapid_target}"

# List the clusters by name, master version, zone, and release channel.
clusters=$(gcloud container clusters list \
  --format="table[no-heading](name,master_version(),zone,release_channel.channel)")

IFS=$'\n'
for cluster in ${clusters}
do
    echo ""
    cname=$(printf "${cluster}" | awk '{print $1}')
    master_version=$(printf "${cluster}" | awk '{print $2}')
    zone=$(printf "${cluster}" | awk '{print $3}')
    channel=$(printf "${cluster}" | awk '{print $4}')

    # Determine the target version (default to latest valid stable version).
    target=${stable_target}
    case ${channel} in
        "RAPID")
            target=${rapid_target}
            ;;
        "REGULAR")
            target=${regular_target}
            ;;
        "STABLE")
            target=${stable_target}
            ;;
        esac

    # Check if the master needs to upgrade to the target version.
    semver_lt "${master_version}" "${target}"
    need_upgrade=$?
    if [[ ${need_upgrade} -eq 1 ]]; then
        upgrade_master ${cname} ${target}
    else
        echo "Cluster ${cname} does not need to upgrade."
    fi

    # Then check if the cluster's node pools need to upgrade too.
    nps=$(gcloud container node-pools list --cluster ${cname} --zone ${zone} \
            --format="table[no-heading](name,version)")
    for np in ${nps}
    do
        np_name=$(printf "${np}" | awk '{print $1}')
        np_version=$(printf "${np}" | awk '{print $2}')

        semver_lt "${np_version}" "${target}"
        need_upgrade=$?
        if [[ ${need_upgrade} -eq 1 ]]; then
            upgrade_np ${cname} ${np_name} ${target}
        else
            echo "Node pool ${np_name} does not need to upgrade."
        fi
    done
done

¿Qué sigue?