IBM Cloud Docs
Información de versión de Kubernetes

Información de versión de Kubernetes

Revise esta página para obtener información general sobre las versiones de IBM Cloud® Kubernetes Service y la actualización a las versiones más recientes.

Para obtener más información sobre las versiones del proyecto Kubernetes, consulte los registros de cambios de Kubernetes.

Versiones disponibles de IBM Cloud® Kubernetes Service

IBM Cloud Kubernetes Service da soporte a varias versiones de Kubernetes simultáneamente. Cuando se publica una versión más reciente (n), se da soporte a hasta 2 versiones anteriores (n-2). Las versiones anteriores a 2 versiones anteriores a la versión más reciente (n-3) son las primeras que quedan en desuso y a las que se deja de dar soporte. Para seguir recibiendo actualizaciones importantes de parches de seguridad, asegúrese de que los clústeres ejecuten siempre una versión de Kubernetes soportada. Es posible que los clústeres en desuso no reciban actualizaciones de seguridad. Para obtener más información, consulte Ciclo de vida del release.

Las fechas que están marcadas con el símbolo † son provisionales y están sujetas a cambios. Los sistemas operativos marcados con un asterisco (*) están en desuso; migre los nodos trabajadores que utilizan un sistema operativo en desuso para ejecutarse en una versión más reciente del sistema operativo.

[Última actualización] :{: tag-green} Predeterminado 1.32

1.31

1.30

{: tag-deprecated}, [obsoleto] 1.29

Tipos de actualización

El clúster de Kubernetes tiene tres tipos de actualizaciones: mayores, menores y parches. A medida que las actualizaciones pasan a estar disponibles, se le notifica cuando visualiza información sobre el maestro de clúster o los nodos trabajadores, como por ejemplo con los mandatos ibmcloud ks cluster ls, cluster get, worker ls o worker get.

IBM proporciona fixpacks de nodo trabajador quincenales. IBM el objetivo de la empresa es corregir las vulnerabilidades legítimas detectadas en un plazo adecuado a los riesgos que representan. Para garantizar la calidad y la estabilidad del release, es posible que los fixpacks se retrasen.

Los fixpacks se aplican a la última versión estable del kernel en sentido ascendente que proporciona Canonical.

Para mantener los nodos seguros, debe instalar los fixpacks de nodo trabajador lo antes posible. Puede suscribirse a notificaciones para recibir una alerta cuando haya una nueva actualización disponible.

Consecuencias en las actualizaciones de Kubernetes
Tipo actualización Ejemplos de etiquetas de versión Actualizado el por Impacto
Principal 1.x.x Usted Operación de clústeres de cambios, incluyendo scripts o despliegues.
Secundaria x.22.x Usted Operación de clústeres de cambios, incluyendo scripts o despliegues.
PATCH x.x.4_1510 IBM y el usuario Parches de Kubernetes, así como otras actualizaciones de componentes de Proveedor de IBM Cloud como, por ejemplo, parches de seguridad y del sistema operativo. IBM actualiza los maestros automáticamente, pero el usuario debe aplicar los parches a los nodos trabajadores. Consulte más información sobre los parches en la sección siguiente.
Actualizaciones de versiones principales y menores (1.x)
En primer lugar, actualice el nodo maestro y luego actualice los nodos trabajadores.
  • No se puede actualizar un maestro de Kubernetes a dos o más versiones menores posteriores (n+2). Por ejemplo, si su maestro actual es la versión 1.22 y desea actualizar a 1.24, primero debe actualizar a 1.23.
  • Los nodos de trabajador no pueden ejecutar una versión principal o menor de Kubernetes que sea posterior a la de los maestros. Además, los nodos trabajadores sólo pueden estar hasta dos versiones por detrás de la versión de nodo maestro (n-2).
  • Si utiliza una versión de CLI kubectl que no coincide al menos con la versión major.minor de los clústeres, puede experimentar resultados inesperados. Asegúrese de que mantiene el clúster de Kubernetes y las versiones de CLI actualizados.
Actualizaciones de parches (x.x.4_1510)
Los cambios de los parches se documentan en el registro de cambios de cada versión. Los parches maestros se aplican automáticamente, pero las actualizaciones y los parches de nodo de trabajador los debe iniciar el usuario. Los nodos maestros también puede ejecutar versiones de parches que sean posteriores a las de los nodos maestros. A medida que las actualizaciones estén disponibles, se le notificará cuando visualice información sobre los nodos trabajadores y maestro en la CLI o consola de IBM Cloud, como por ejemplo con los siguientes mandatos: ibmcloud ks cluster ls, cluster get, worker ls o worker get.
Los parches pueden corresponder a nodos trabajadores, a nodos maestros o a ambos.
  • Parches de nodo de trabajador: compruebe una vez al mes si hay alguna actualización disponible y utilice el mandato ibmcloud ks worker update o el mandato ibmcloud ks worker reload para aplicar estos parches de sistema operativo y de seguridad. Durante una actualización o recarga, se creará de nuevo la imagen de la máquina del nodo trabajador y se suprimirán los datos si no se almacenan fuera del nodo trabajador.
  • Parches maestros: los parches maestros se aplican automáticamente durante el curso de varios días, por lo que una versión de parche maestro podría aparecer como disponible antes de que se aplique a su nodo maestro. La automatización de actualizaciones también pasa por alto los clústeres que no están en buen estado o que tienen operaciones actualmente en curso. Ocasionalmente, IBM puede desactivar las actualizaciones automáticas para un paquete de parches maestro específico, como se indica en el registro de cambios, como un parche que sólo es necesario si un maestro se actualiza de una versión menor a otra. En cualquiera de estos casos, puede optar por utilizar de forma segura el comando ibmcloud ks cluster master update sin esperar a que se aplique la automatización de la actualización.

Ciclo de vida del release

Cada versión soportada de IBM Cloud Kubernetes Service pasa por un ciclo de vida que abarca prueba, desarrollo, publicación general, soporte y desuso hasta que deja de recibir soporte. Revise las descripciones de cada fase del ciclo de vida de una versión.

Se muestran días estimados y versiones para facilitar la comprensión general. Las fechas reales de disponibilidad y de publicación están sujetas a cambios y dependen de diversos factores, como actualizaciones de comunidad, parches de seguridad y cambios tecnológicos entre versiones.

  1. Release de comunidad: la comunidad publica la nueva versión. IBM los ingenieros comienzan a probar y reforzar la versión comunitaria para preparar el lanzamiento de una versión compatible con IBM Cloud Kubernetes Service.

  2. Ciclo de vida de versión soportado:

    Release de desarrollo
    El release está en desarrollo y puede estar disponible como versión beta para seleccionar clientes. IBM proporciona el mejor soporte de esfuerzo para el release.
    Disponibilidad general
    El release está disponible a nivel general (GA). IBM proporciona soporte completo para el release. IBM proporciona una fecha objetivo provisional para que el release no esté soportado. El release se convierte en la versión predeterminada utilizada durante la creación del clúster una vez que hay restricciones mínimas y una tasa de adopción razonable para el release.
    Mantenimiento
    El release ha entrado en el soporte de mantenimiento tal como lo define la comunidad de Kubernetes. IBM proporciona soporte de mantenimiento para Kubernetes basado en la política de comunidad. De lo contrario, IBM proporciona soporte completo.

  3. Versión en desuso: la versión está en desuso. IBM proporciona una fecha de destino no soportada actualizada para el release. Se proporciona una cuenta atrás no soportada hasta esta fecha al menos 45 días antes de que el release deje de estar soportado. IBM proporciona un soporte mínimo para el release en alineación con la comunidad de Kubernetes. Esta fase de soporte suele ser la fase final antes de que el release pase a no estar soportado y altera temporalmente las fases de mantenimiento y soporte ampliado si hay algún solapamiento. Es posible que no se proporcionen actualizaciones de los parches de seguridad. Durante el periodo de obsoleto, la versión sigue siendo compatible y el clúster sigue funcionando, pero es posible que deba actualizarse a una versión compatible para corregir vulnerabilidades de seguridad. Por ejemplo, añadiendo o volviendo a cargar nodos trabajadores.

  4. Versión no soportada: la versión no está soportada. IBM solo proporciona soporte para actualizar a un release soportado. La versión no está soportada. Los clústeres no soportados no se proporcionan con las actualizaciones de seguridad y los parches, ni reciben soporte del servicio de soporte de IBM Cloud. Aunque el clúster y las apps pueden continuar ejecutándose durante un tiempo, ya no se puede crear, volver a cargar ni realizar otras acciones correctivas en el nodo maestro o los nodos trabajadores del clúster cuando se produce un problema. Todavía puede suprimir el clúster o los nodos trabajadores, o actualizar el clúster a la versión siguiente. Revise los impactos potenciales e inmediatamente actualice el clúster para continuar recibiendo actualizaciones importantes de seguridad y soporte. Si el maestro de clúster ejecuta dos o más versiones detrás de la versión soportada más antigua, ya no podrá aplicar actualizaciones y deberá suprimir el clúster y crear uno nuevo.

Los clústeres que ejecuten una versión no compatible acabarán fallando porque los certificados de clúster caducan. Los fallos pueden incluir, entre otros, un plano de control de clústeres no disponible, nodos de trabajador NotReady s o un Ingress no operativo.

  1. Archivado: La versión no está soportada sin ninguna vía de acceso de actualización. IBM no proporciona soporte. IBM se reserva el derecho de concluir los planos de control para dichos clústeres.

IBM Cloud Kubernetes Service no ha expandido su desvío soportado entre el nodo principal y los componentes del plano de control en una versión menor. El desvío soportado sigue siendo n-2. Para obtener más información, consulte Cambios en el desvío soportado entre el plano de control y las versiones de nodo para obtener información de la comunidad de Kubernetes.

Si espera hasta que el clúster sea de dos o más versiones menores anteriores a la versión soportada más antigua, no podrá actualizar el clúster. En ese caso, debe crear un nuevo clúster, desplegar las apps en el nuevo clúster y suprimir el clúster no soportado. Para evitar este problema, actualice los clústeres en desuso a una de las dos versiones soportadas anteriores a la actual, como la 1.21 o la 1.22, y, a continuación, actualice a la última versión, la 1.23. Si los nodos trabajadores ejecutan una versión que está dos o más por detrás del nodo maestro, es posible que los pods fallen y entren en un estado como MatchNodeSelector, CrashLoopBackOff o ContainerCreating hasta que actualice los nodos trabajadores a la misma versión que el nodo maestro. Después de actualizar de una versión en desuso a una soportada, el clúster puede reanudar las operaciones normales y seguir recibiendo soporte. Puede averiguar si su clúster no es compatible revisando el campo Estado en la salida del comando ibmcloud ks cluster ls o en la consola IBM Cloud Kubernetes Service.

Preparación para la actualización

Es probable que la actualización de un clúster a una nueva versión desde la versión anterior afecte de algún modo a las aplicaciones desplegadas. Para obtener una lista completa de los cambios, revise los registros de cambios de comunidad Kubernetes, los registros de cambios de versión deIBM y los avisos útiles deKubernetes.

Para ver las acciones que debe realizar antes y después de actualizar el clúster, consulte los enlaces de información de versión en Versiones disponibles de IBM Cloud® Kubernetes Service.

Archivo

Los clústeres no soportados no se proporcionan con las actualizaciones de seguridad y los parches, ni reciben soporte del servicio de soporte de IBM Cloud. Aunque el clúster y las apps pueden continuar ejecutándose durante un tiempo, ya no se puede crear, volver a cargar ni realizar otras acciones correctivas en el nodo maestro o los nodos trabajadores del clúster cuando se produce un problema. Todavía puede suprimir el clúster o los nodos trabajadores, o actualizar el clúster a la versión siguiente. Revise los impactos potenciales e inmediatamente actualice el clúster para continuar recibiendo actualizaciones importantes de seguridad y soporte. Si el maestro de clúster está dos o más versiones por detrás de la versión soportada más antigua, debe crear un nuevo clúster y desplegar las apps en el nuevo clúster.

Versiones no compatibles Kubernetes
Historial de versiones archivadas