Actualizaciones EUS a EUS de OpenShift: un runbook de Control Plane Only update

Qué es una Control Plane Only update

Red Hat designa las versiones menores pares de OpenShift Container Platform, como 4.20 y 4.22, como versiones Extended Update Support (EUS). Muchos equipos ejecutan producción en versiones EUS y solo pasan de una a la siguiente. Este artículo sigue la documentación de OpenShift Container Platform 4.22 para ese paso. Consulte la documentación de sus propias versiones antes de confiar en cualquier detalle de este texto.

Las actualizaciones menores son secuenciales: un clúster no puede ir de 4.20 a 4.22 directamente, debe pasar por 4.21. Una Control Plane Only update, antes llamada actualización EUS-to-EUS, hace que eso sea llevadero. Usted pone en pausa los machine config pools de sus nodos worker y personalizados, deja que el plano de control se actualice a 4.21 y luego a 4.22, y reanuda los pools al final. Los nodos en pausa se actualizan una sola vez, directamente a 4.22, así que se reinician una vez en lugar de dos. Solo funciona entre versiones menores pares.

Del proceso de Red Hat se derivan dos reglas de calendario. La ruta solo se ofrece cuando las actualizaciones entre todas las versiones implicadas están disponibles en los canales stable, y Red Hat documenta un retraso típico de 45 a 90 días tras la disponibilidad general de una nueva versión menor antes de que sus rutas de actualización lleguen a los canales stable, con promoción simultánea a los canales EUS. Es una estimación, no un plazo garantizado. Si la ruta de actualización todavía no se ofrece, la respuesta es esperar, no forzarla.

Lea las dos notas de versión, no solo la de destino

Los requisitos previos empiezan por leer las notas de versión de 4.21 y de 4.22, y las notas de versión y ciclos de vida de cada producto en capas y cada Operator del clúster. Aunque los nodos worker se saltan 4.21, el plano de control no, y cada salto tiene su propia preparación.

Para este par, las guías de actualización de 4.21 y 4.22 no indican ninguna eliminación de API de Kubernetes, lo que elimina un bloqueo habitual. Eso no descarta otros cambios incompatibles, obsolescencias ni requisitos de compatibilidad de Operators, que cubren las notas de versión. El salto de 4.21 a 4.22 añade otro en plataformas concretas: en clústeres vSphere, por ejemplo, donde no se ha configurado el parámetro managedBootImages, la actualización queda bloqueada hasta que un administrador reconozca el nuevo comportamiento predeterminado de las imágenes de arranque actualizadas o desactive explícitamente la función para los nodos de cómputo. Los clústeres con volúmenes vSphere in-tree también necesitan vSphere 7.0u3L+ u 8.0u2+ antes de empezar la actualización. Descubrir esto en una reunión de planificación cuesta minutos. Descubrirlo a mitad de una ventana de mantenimiento cuesta la ventana.

Compruebe que el clúster está listo

OpenShift no inicia una actualización menor a menos que cada cluster Operator informe Upgradeable como True, y la alerta ClusterNotUpgradeable le avisa cuando alguno no lo hace. Resuelva también primero las alertas críticas. El comando de solo lectura oc adm upgrade recommend resume las alertas activas y los riesgos de actualización conocidos para su clúster. Sus comprobaciones basadas en alertas necesitan autenticación con token: con el kubeconfig del instalador y la identidad system:admin basada en certificados, el comando se ejecuta igualmente, pero informa de que falta el token y omite esas comprobaciones.

Elija solo destinos de actualización recomendados por el OpenShift Update Service. Un destino mostrado como actualización condicional conlleva un riesgo conocido que se aplica a su clúster; salvo que necesite esa versión concreta, el consejo de Red Hat es esperar una ruta recomendada.

Después, revise la capacidad. Por defecto los nodos se vacían de uno en uno, ya que maxUnavailable vale 1, y Red Hat recomienda no cambiar ese valor en el pool del plano de control. Todos los nodos deben estar disponibles antes de empezar, los demás nodos necesitan espacio para los pods que se trasladan, y los PodDisruptionBudgets deben permitir que esos pods se muevan. Un presupuesto que no tolera ninguna interrupción detiene el vaciado de un nodo con la misma eficacia que un fallo. Actualice la CLI oc a la versión de destino antes de cada salto y haga una copia de seguridad de etcd antes de empezar.

Los Operators deciden cuánto se tarda

La actualización del clúster es la parte guionizada. Los Operators son donde las Control Plane Only updates suelen atascarse. Antes de cada salto, cada Operator instalado mediante Operator Lifecycle Manager (OLM) debe actualizarse a una versión compatible con la versión de destino, para que conserve una ruta de actualización válida cuando los catálogos predeterminados cambien a la siguiente versión menor. Red Hat ofrece el Operator Update Information Checker para confirmar qué versiones de clúster admite cada versión de un Operator.

Los productos en capas se intercalan con las actualizaciones del clúster. El ejemplo de Red Hat para OpenShift Data Foundation es: pausar los pools worker, actualizar el clúster a 4.21, actualizar ODF a su versión 4.21, actualizar el clúster a 4.22, actualizar ODF a 4.22 y reanudar. Haga una lista de cada Operator con su versión actual, sus versiones compatibles y el punto de la secuencia en el que cambia, y trate esa lista como parte del registro de cambio.

Clústeres que ejecutan máquinas virtuales

Si el clúster ejecuta OpenShift Virtualization, hay un paso adicional antes del primer salto. Anote el valor actual de workloadUpdateMethods y déjelo vacío. Así OpenShift Virtualization no migra ni desaloja máquinas virtuales mientras el plano de control pasa por 4.21.

Después, OpenShift Virtualization sigue al clúster. Tras el salto a 4.21, se actualiza al último z-stream de su versión intermedia, y hay que esperar a que el HyperConverged Operator vuelva a informar Upgradeable antes de iniciar el salto a 4.22. Con la estrategia de aprobación Automatic predeterminada, estas actualizaciones se aplican solas; con aprobación Manual, cada una debe aprobarse. Tras el salto a 4.22 y la actualización correspondiente de OpenShift Virtualization, restaure el valor de workloadUpdateMethods anotado, compruebe las migraciones de VM y solo entonces reanude los pools.

La secuencia

La secuencia documentada, desde la CLI o la consola web, es corta. Actualice los Operators de OLM a versiones compatibles con el destino. Confirme que todos los machine config pools están al día y que ninguno se está actualizando. Cambie el canal del clúster a eus-4.22. Pause todos los pools excepto el del plano de control, que no se puede pausar. Actualice a la última versión 4.21 y confirme que la actualización ha terminado. Vuelva a actualizar los Operators si hace falta. Actualice a 4.22 y confirme. Reanude los pools y confirme que cada uno aparece al día.

Solo el paso de reanudar reinicia los nodos worker, así que es el paso que hay que programar según el calendario del negocio. Si el clúster incluye máquinas de cómputo RHEL, hay que ejecutar el playbook de actualización en cada una cuando entra en estado NotReady. Asigne a cada paso un responsable, una comprobación que demuestre que terminó y una condición escrita para detenerse.

Mantenga la pausa corta

Los pools en pausa no son un lugar seguro para esperar. Mientras un pool está en pausa, el Machine Config Operator no puede enviar configuración a sus nodos, y eso incluye el paquete de confianza de certificados actualizado tras la rotación automática de la CA kube-apiserver-to-kubelet-signer. La pausa por sí sola no rompe nada, pero cuando el API server usa un certificado de cliente firmado por el nuevo firmante, los nodos en pausa pueden rechazarlo, y comandos como oc logs, oc exec, oc debug y oc attach fallan. Y si los pools siguen en pausa después de la actualización, el clúster no puede actualizarse a ninguna versión menor posterior y algunas tareas de mantenimiento quedan bloqueadas.

Hasta que se reanudan los pools, algunas funciones y correcciones de 4.21 y 4.22 no están disponibles en los nodos en pausa. Si aparece un problema en 4.21, antes del segundo salto, corregirlo puede exigir que los nodos en pausa completen primero la actualización a 4.21. Ese es el camino de vuelta a una actualización normal con dos reinicios, así que acéptelo en lugar de mantener los pools en pausa mientras busca otro. En clústeres grandes, los pools personalizados pueden reanudarse por etapas, empezando por un pequeño pool canary, siempre que todos terminen en la misma versión.

Planifique sin rollback del clúster

Revertir un clúster de OpenShift a una versión anterior no está soportado. Esto se refiere a la versión del clúster: el rollback a nivel de aplicación y la recuperación ante desastres documentada son otra cuestión. Una copia de seguridad de etcd protege frente a un clúster que queda irrecuperable, pero Red Hat deja claro que una restauración de etcd no es un mecanismo de rollback, es destructiva y es el último recurso. Si una actualización no llega a completarse, la vía soportada es el soporte de Red Hat.

Por eso todo lo que haría innecesario un rollback ocurre antes de la actualización: un ensayo en un clúster que no sea de producción con los mismos Operators en las mismas versiones, la secuencia de Operators y productos en capas por escrito, la capacidad y los PodDisruptionBudgets revisados, los reconocimientos de administrador dados y un caso de soporte listo para abrir. La ventana de mantenimiento debe indicar quién puede detener el cambio y ante qué señales. Para las cargas de trabajo de aplicación, recuperar significa la copia de seguridad y restauración propias de la aplicación, probadas de antemano, no una restauración del clúster.

Cómo lo abordamos

Tratamos una actualización EUS a EUS como un cambio planificado con un runbook: requisitos previos específicos de cada versión comprobados con la documentación de las versiones exactas, una lista de compatibilidad de Operators, un ensayo, condiciones de parada acordadas de antemano y una pausa tan corta como permita el plan. Los runbooks de actualización y la evidencia de pruebas de recuperación forman parte de los entregables documentados de nuestra práctica de Kubernetes y OpenShift, y las actualizaciones controladas se incluyen en el soporte de plataforma dentro de la cobertura acordada.