Llegeix en anglès

Comparteix a través de

Gobernanza de la actualización del runtime del clúster de la plataforma Operator Nexus

  • Article

En este documento se detalla cómo Operator Nexus publica, administra y admite varias actualizaciones del runtime de la plataforma para clientes perimetrales cercanos.

Operator Nexus publica una versión en runtime del clúster de plataforma con tres versiones secundarias al año y versiones de revisión mensuales entre medias.

Operator Nexus admite versiones en runtime del clúster de la plataforma n-2 para los clientes, lo que proporciona aproximadamente un año de soporte técnico tras el lanzamiento.

Descripción del control de versiones del clúster de Operator Nexus

Las versiones del clúster de la plataforma Operator Nexus usan principios semánticos basados en versiones (https://semver.org/), lo que garantiza que los usuarios puedan tomar decisiones informadas sobre la selección de versiones con las siguientes reglas sobre los cambios permitidos en una versión:

  • Versión principal para introducir funciones fundamentalmente incompatibles o cambios en la interfaz.
  • Versión menor para introducir funcionalidades manteniendo una interfaz compatible con versiones anteriores.
  • Versión de revisión para realizar modificaciones compatibles con versiones anteriores, como correcciones de errores o vulnerabilidades de seguridad.

Las versiones del clúster de Operator Nexus usan el mismo esquema Major.Minor.Patch. El uso del versionamiento semántico incluye un principio crítico de inmutabilidad. Una vez que se ha publicado un paquete con versiones, NO se modificará el contenido de esa versión. Las modificaciones DEBEN publicarse como una nueva versión.

La versión del clúster de plataforma se representa en el recurso del clúster de Operator Nexus. En el momento de la creación del clúster, la versión se especifica en el recurso del clúster y debe contener una versión compatible. Para actualizar el clúster, puede proporcionar una versión deseada, que debe ser una de las versiones admitidas para ese clúster. Puede ver en el clúster las versiones admitidas en función de su instancia específica.

Cadencia de lanzamiento del clúster de la plataforma Operator Nexus

Operator Nexus lanza una nueva versión secundaria del clúster de plataformas en febrero, junio y octubre de cada año. Un cliente puede decidir cuándo aplicar la versión secundaria a una instancia de Operator Nexus. Sin embargo, estas versiones secundarias no son opcionales y deben adoptarse para seguir siendo compatibles.

Estas versiones del clúster de la plataforma constan de nuevas versiones secundarias de Kubernetes para la infraestructura, las nuevas versiones de Azure Linux y otros componentes críticos para la plataforma subyacente.

Además de las versiones secundarias, Operator Nexus publica versiones de revisión del clúster de la plataforma entre las versiones secundarias. En general, estas versiones son opcionales.

Versiones de revisión del runtime del clúster de la plataforma

Las versiones de revisión del clúster de la plataforma se programan mensualmente para proporcionar a los clientes una versión actualizada de Azure Linux, a partir de la versión 2408.1 de Nexus. Estas versiones de revisión se aplican a la versión secundaria más reciente.

El contenido de estas versiones se limita principalmente a actualizar las versiones actuales de las versiones de revisión de HostOS y Kubernetes. Operator Nexus también publicará versiones de revisión del runtime del clúster de la plataforma que abordan problemas críticos de seguridad funcionales o de alta gravedad. Estas versiones de revisión del runtime se publican junto con una nueva versión de agrupación de administración para habilitar la implementación de este nuevo runtime.

Las versiones de revisión son opcionales y no son necesarias. Operator Nexus certifica las distintas versiones de runtime compatibles para asegurarse de que hay una vía de actualización, independientemente de la versión de revisión del runtime, a la siguiente versión secundaria en runtime.

El runtime del clúster de la plataforma no es compatible

Cuando un cliente está en una versión que deja de ser compatible, Microsoft intenta mitigar los vales de cliente, pero puede que no sea posible solucionarlo. Cuando se quita la compatibilidad con una versión secundaria en runtime, ya no será una opción para implementar en una nueva instancia.

Cuando una instancia ejecuta una versión n-3:

  • El clúster continúa ejecutándose; sin embargo, las operaciones normales pueden empezar a degradarse, ya que no se validan las versiones anteriores del software
  • Las incidencias de soporte técnico generadas recibirán soporte técnico, pero es posible que los problemas no se puedan mitigar.
  • La versión n-3 no está disponible para que los clientes implementen una nueva instancia.
  • Ya no se admite una ruta de actualización, lo que requiere que los clientes vuelvan a crear instancias.
  • Las versiones anteriores del runtime del clúster de la plataforma pueden seguir ejecutándose, pero Microsoft no garantiza que toda la funcionalidad sea compatible con la versión más reciente del software en el Administrador de clústeres. Se proporciona una ruta de actualización para los clientes en versiones admitidas. No se admite la actualización desde una versión n-3 o posterior y requiere que se vuelva a implementar el sitio. Los clientes deben ejecutar una actualización en runtime del clúster de la plataforma antes de que un sitio llegue a n-3.
  • Se requiere que el cliente actualice el runtime del clúster de la plataforma en el plazo de un año desde la actualización más reciente del runtime del clúster de la plataforma o la primera implementación para garantizar que su instancia de Nexus puede conectarse a Azure. Después de un año sin ninguna actualización del runtime, la instancia de Operator Nexus, al perder la conexión con Azure, requerirá una nueva implementación

Omisión de versiones secundarias

Las versiones secundarias del runtime del clúster de la plataforma no se pueden omitir debido a los requisitos de actualización de Kubernetes. Un cliente que quiere pasar de una versión n-2 a una versión n debe realizar varias actualizaciones del runtime del clúster de la plataforma.

Cómo realizar una actualización del runtime del clúster de la plataforma