Actualizaciones del entorno de ejecución de Nexus del operador de Azure

La actualización del entorno de ejecución de la plataforma Nexus es una actualización disruptiva, administrada por los clientes, para actualizar el software subyacente en los servidores de una instancia de Operator Nexus. La interrupción se produce en los servidores de cómputo dentro de un rack que se está actualizando. Las actualizaciones del servidor de administración se consideran no disruptivas.

Ámbito de las versiones en tiempo de ejecución

La actualización en tiempo de ejecución está diseñada para actualizar los componentes fundamentales de la plataforma para cada servidor de la instancia. Algunos ejemplos de componentes actualizados durante la actualización en tiempo de ejecución son el sistema operativo (SO), el clúster de Kubernetes en la nube, el firmware de proceso, el clúster etcd y el CNI (interfaz de red de contenedor). Cada servidor se vuelve a cargar para instalar la imagen de la versión del entorno de ejecución seleccionado.

Frecuencia de lanzamiento

Versiones principales y menores

Las versiones menores de tiempo de ejecución se generan para la infraestructura de cómputo tres veces al año en febrero, junio y octubre. Estas versiones son compatibles durante aproximadamente un año después de su lanzamiento, y los clientes no pueden omitir las versiones menores.

Lanzamientos de parches

La versión de ejecución del parche se genera mensualmente entre las versiones menores. Estas versiones son opcionales, a menos que Microsoft las requiera por cuestiones de funcionalidad o seguridad específicas.

Información general de flujos de trabajo

El inicio de una actualización en tiempo de ejecución se define en Actualización del entorno de ejecución del clúster a través de la CLI de Azure.

La actualización en tiempo de ejecución comienza actualizando los tres servidores de administración designados como nodos del plano de control. El servidor de plano de control de reserva es el primer servidor que se va a actualizar. El último servidor de plano de control se desaprovisiona y realiza la transición al estado Available. Estos servidores se actualizan de forma secuencial y avanzan solo cuando cada actualización se ha completado correctamente. Los servidores de administración restantes se separan en dos grupos. La actualización en tiempo de ejecución ahora aprovechará dos grupos de administración, en lugar de un único grupo. Cada grupo se actualiza en dos fases y de manera secuencial, con un umbral de éxito del 50% en cada grupo. La introducción de esta funcionalidad permite a los componentes que se ejecutan en los servidores de administración garantizar la resistencia durante la actualización en tiempo de ejecución aplicando reglas de afinidad. Para esta versión, cada CSN aprovechará esta funcionalidad colocando una instancia en cada grupo de administración. No hay interacción del cliente con esta funcionalidad. Puede haber etiquetas adicionales en los nodos de administración para identificar los grupos.

Una vez actualizados todos los servidores de administración, la actualización avanza a los servidores de proceso. Cada bastidor se actualiza en orden alfanumérico y hay varias configuraciones que los clientes pueden usar para determinar cómo se actualizan las computadoras para limitar la interrupción lo mejor posible. A medida que avanza cada bastidor, se realizan varias comprobaciones de estado para garantizar que la actualización de la versión se realice con éxito y que un número suficiente de nodos de cómputo en un bastidor vuelva a su estado de funcionamiento. Cuando un rack se completa, comienza el tiempo de espera definido por el cliente para proporcionar tiempo adicional a fin de que las cargas de trabajo se activen. Una vez que se actualiza cada bastidor, la actualización se completa y el clúster vuelve al Running estado.

Los pasos para ejecutar una actualización en tiempo de ejecución del clúster se encuentran aquí.

Estrategias de actualización en tiempo de ejecución

Cada una de las estrategias explicadas proporciona a los usuarios varios controles sobre cómo y cuándo se actualizan los bastidores de proceso. Estos valores solo son aplicables a los servidores de proceso y no a los servidores de administración. Cada estrategia usa un thresholdType y un thresholdValue para definir el número o porcentaje de servidores de cómputo actualizados correctamente en un bastidor antes de continuar con el siguiente bastidor.

Los valores de umbral son un cálculo realizado durante la actualización para determinar el número de servidores de proceso disponibles después de completar la actualización.

Bastidor a bastidor

El comportamiento predeterminado de las actualizaciones en tiempo de ejecución recorre en iteración cada bastidor uno por uno hasta que se cumplan todos los umbrales del sitio.

Rack en pausa

Esta estrategia pausará la actualización después de que el bastidor complete la actualización. El próximo rack no arrancará hasta que el cliente ejecute la API de actualización.

Aquí se encuentran detalles sobre cómo ejecutar una actualización con pausa de bastidor.

Cargas de trabajo de tenant de Nexus durante el proceso de actualización del tiempo de ejecución del clúster

Durante una actualización en tiempo de ejecución, los nodos del clúster de Nexus Kubernetes que se ejecutan en servidores programados para la actualización se acordonan, purgan y, a continuación, se apagan correctamente antes de que comience la actualización. El acordonamiento de un nodo impide que se programen nuevos pods en él, mientras que la purga permite que los pods que ejecutan cargas de trabajo de inquilinos cambien a otros nodos disponibles, lo que minimiza la interrupción del servicio. La eficacia del drenaje depende de la capacidad disponible dentro del clúster. Si el clúster está cerca de su capacidad máxima y carece de espacio para la reubicación de pods, esos pods entran en un estado Pendiente después del vaciado.

Una vez completados los pasos de cordón y purga, el nodo se apaga como parte del proceso de actualización. Después de la actualización del servidor baremetal, el nodo se reinicia, se reincorpora al clúster y se elimina su cordón, lo que permite que los pods se programen de nuevo en él.

En el caso de las máquinas virtuales Nexus, el proceso es similar. Las máquinas virtuales se apagan antes de actualizar el servidor baremetal y se reinician automáticamente una vez que el servidor vuelve a estar en línea.

Cada nodo de clúster de inquilinos puede tardar hasta 20 minutos en completarse el proceso de purga. Después de esta ventana, la actualización del servidor continúa, independientemente de la finalización del drenaje, con el fin de asegurar el avance. Los servidores se actualizan un rack a la vez, con las actualizaciones llevándose a cabo en paralelo dentro del mismo rack. La actualización del servidor no espera a que los recursos del arrendatario se conecten antes de continuar con la actualización de ejecución de otros servidores en el rack. Además del tiempo de espera de purga, hay un tiempo de espera de 10 minutos asignado para los apagados de máquina virtual. Este enfoque garantiza que el tiempo de espera máximo por bastidor permanezca en 30 minutos, específico del procedimiento de aislamiento, drenaje y apagado, y no de la actualización general.

Es importante tener en cuenta que después de la actualización en tiempo de ejecución, podría haber una instancia en la que un nodo del clúster de Kubernetes Nexus permanece acordonado. Para este escenario, busque nodos nocordon mediante la ejecución del comando siguiente.

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table

Operaciones de conjunto de claves BareMetalMachine (BMM) durante la actualización de ejecución del clúster

Cuando se actualiza un servidor para usar un nuevo sistema operativo, los conjuntos de claves BMM deben volver a establecerse con el nuevo software. Este proceso se inicia una vez completada la actualización en tiempo de ejecución para la instancia. Todavía se puede acceder a los servidores que aún no se han sometido a una actualización en tiempo de ejecución a través del conjunto de claves BMM. Si se necesita acceso a una máquina durante la actualización, el usuario de la consola está disponible.

Los servidores no se actualizaron correctamente

Un servidor sigue sin estar disponible si no se puede actualizar o aprovisionar desde un posible problema de hardware durante el reinicio o problema con cloud-init (redes, chronyd, etc.). Es necesario resolver la condición subyacente y se debe ejecutar baremetalmachine replace/reimage. Retirar manualmente la restricción del servidor no resolverá los problemas.