Actualización de clústeres, nodos trabajadores y componentes de clúster

Actualización del nodo maestro

¿Cómo sé cuándo tengo que actualizar el servidor maestro?

Se le notificará en la consola, los anuncios y la CLI cuando haya actualizaciones disponibles. También puede comprobar periódicamente la página de versiones soportadas.

¿Cuántas versiones por detrás de la última puede estar el repositorio principal?

Solo puedes actualizar el servidor de la API a la versión inmediatamente superior a la actual (n+1).

¿Pueden mis nodos de trabajo ejecutar una versión más reciente que la del nodo maestro?

Los nodos de trabajador no pueden ejecutar una versión de Kubernetes major.minor posterior a la del maestro. Además, los nodos de trabajador solo pueden estar una versión detrás de la versión de nodo maestro (n-1). Primero, actualice el nodo maestro a la última versión de Kubernetes. Luego actualice los nodos trabajadores del clúster.

Los nodos trabajadores pueden ejecutar versiones posteriores del parche que el maestro, como versiones de parches específicas de los nodos trabajadores para las actualizaciones de seguridad.

¿Cómo se aplican las actualizaciones de parches?

De forma predeterminada, las actualizaciones de parches para el nodo maestro 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 podría inhabilitar las actualizaciones automáticas para un fixpack maestro específico, como un parche que solo sea necesario si se actualiza un nodo maestro de una versión menor a otra. En cualquiera de estos casos, puedes consultar la página Red Hat OpenShift on IBM Cloud información sobre la versión para ver si hay algún impacto potencial y optar por utilizar tú mismo de forma segura el ibmcloud oc cluster master update comando sin esperar a que se aplique la actualización automática.

A diferencia de lo que sucede con el nodo maestro, debe actualizar los nodos trabajadores para cada versión de parche.

¿Qué ocurre durante la actualización del servidor maestro?

El nodo maestro está altamente disponible con tres pods de maestro de réplica. Los pods del nodo maestro tienen una actualización continua, durante la cual solo hay un pod que no está disponible al mismo tiempo. Dos instancias están activas y en ejecución para que pueda acceder y cambiar el clúster durante la actualización. Sus nodos trabajadores, apps y recursos continúan en ejecución.

¿Puedo revertir la actualización?

No, no puede retrotraer un clúster a una versión anterior después de realizar el proceso de actualización. Asegúrese de utilizar un clúster de prueba y siga las instrucciones para abordar posibles problemas antes de actualizar el nodo maestro de producción.

¿Qué procedimiento debo seguir para actualizar el registro maestro?

El diagrama siguiente muestra el proceso que puede realizar para actualizar el maestro.

Actualización de nodos trabajadores clásicos

Ve que hay una actualización disponible para los nodos trabajadores en un clúster de infraestructura clásica. ¿Qué significa? Como las actualizaciones y parches de seguridad se han aplicado para el servidor de API y otros componentes del nodo maestro, debe asegurarse de que los nodos trabajadores permanecen sincronizados. Puede realizar dos tipos de actualizaciones: actualizar solo la versión de parche o actualizar la versión major.minor con la versión de parche.

• Parche: una actualización de parche de nodo trabajador incluye arreglos de seguridad. Puede actualizar el nodo trabajador clásico al último parche utilizando los mandatos ibmcloud oc worker reload o update. Tenga en cuenta que el mandato update también actualiza el nodo trabajador a la misma versión major.minor que la última versión de parche del nodo maestro, si también hay disponible una actualización de versión major.minor.
• Major.minor: una actualización major.minor mueve la versión de Kubernetes del nodo trabajador a la misma versión que el maestro. Este tipo de actualización suele incluir cambios en la API de Kubernetes u otros comportamientos para los que debe preparar el clúster. Recuerde que los nodos de trabajador solo pueden tener una versión menos que la versión del nodo maestro (n-1). Puede actualizar el nodo de trabajador clásico al mismo parche utilizando el mandato ibmcloud oc worker update.

Para obtener más información, consulte Tipos de actualización.

Es una buena práctica rotar tus certificados CA siempre que actualices tus nodos trabajadores, ya que el paso más largo de la rotación de certificados incluye recargar o reemplazar tus nodos trabajadores.

¿Qué ocurre con mis aplicaciones durante una actualización?

Si ejecuta apps como parte de un despliegue en nodos trabajadores que actualiza, las apps se replanifican en otros nodos trabajadores del clúster. Estos nodos trabajadores pueden estar en otra agrupación de nodos trabajadores o, o si tiene nodos trabajadores autónomos, es posible que las apps se planifiquen en nodos trabajadores autónomos. Para evitar el tiempo de inactividad de la app, debe asegurarse de que tiene suficiente capacidad en el clúster para gestionar la carga de trabajo.

¿Cómo puedo controlar cuántos nodos de trabajo se desactivan a la vez durante una actualización o una recarga?

Si necesita que todos los nodos trabajadores estén en ejecución, tenga en cuenta la posibilidad de redimensionar la agrupación de nodos trabajadores o de añadir nodos trabajadores autónomos para disponer de más nodos trabajadores. Puede eliminar los nodos trabajadores adicionales después de que se haya completado la actualización.

Además, puedes crear un mapa de configuración de « Kubernetes » que especifique el número máximo de nodos de trabajo que pueden estar indisponibles al mismo tiempo, por ejemplo, durante una actualización. Los nodos trabajadores se identifican mediante etiquetas de nodo trabajador. Puede utilizar las etiquetas proporcionadas por IBM o las etiquetas personalizadas que haya añadido al nodo trabajador.

Las reglas del mapa de Kubernetes configuración se utilizan únicamente para actualizar los nodos de trabajo. Estas reglas no afectan a las recargas de nodos trabajadores, lo que significa que la recarga se produce inmediatamente cuando se solicita.

¿Qué pasa si decido no definir un mapa de configuración?

Cuando no se ha definido un mapa de configuración, se utiliza el predeterminado. De forma predeterminada, el 20 % del total de nodos de trabajador de cada clúster, como máximo, pueden estar no disponibles durante el proceso de actualización.

Actualización de nodos trabajadores de VPC

Te das cuenta de que hay una actualización disponible para tus nodos de trabajo en un clúster de VPC. ¿Qué significa? Como las actualizaciones y parches de seguridad se han aplicado para el servidor de API y otros componentes del nodo maestro, debe asegurarse de que los nodos trabajadores permanecen sincronizados. Puede realizar dos tipos de actualizaciones: actualizar solo la versión de parche o actualizar la versión major.minor con la versión de parche.

Si tiene Portworx desplegado en el clúster, siga los pasos necesarios para actualizar los nodos de trabajador de VPC con volúmenes de Portworx.

Es una buena práctica rotar tus certificados CA siempre que actualices tus nodos trabajadores, ya que el paso más largo de la rotación de certificados incluye recargar o reemplazar tus nodos trabajadores.

Si ha desplegado OpenShift Data Foundation en el clúster, siga los pasos para actualizar nodos de trabajador de VPC con OpenShift Data Foundation.

• Parche: una actualización de parche de nodo trabajador incluye arreglos de seguridad. En el caso de los servidores «bare metal» de VPC, puedes aplicar el último parche utilizando el comando « ibmcloud oc worker reload ». Para los trabajadores de instancias de servidor virtual (VPC), utiliza el comando « ibmcloud oc worker replace ».
• Major.minor: una actualización major.minor mueve la versión de Kubernetes del nodo trabajador a la misma versión que el maestro. Este tipo de actualización suele incluir cambios en la API de Kubernetes u otros comportamientos para los que debe preparar el clúster. Recuerda que tus nodos de trabajo solo pueden estar una versión por detrás de la versión maestra (n-1). Puedes actualizar el nodo de trabajo de la VPC a la misma versión de parche utilizando el comando « ibmcloud oc worker replace » con la opción « --update ».

¿Qué ocurre con mis aplicaciones durante una actualización?

Si ejecuta apps como parte de un despliegue en nodos trabajadores que actualiza, las apps se replanifican en otros nodos trabajadores del clúster. Estos nodos trabajadores pueden estar en otra agrupación de nodos trabajadores. Para evitar que tu aplicación sufra interrupciones, debes asegurarte de que el clúster dispone de capacidad suficiente para soportar la carga de trabajo, por ejemplo, ajustando el tamaño de tus grupos de trabajadores. Para obtener más información, consulte Adición de nodos trabajadores a clústeres clásicos o Adición de nodos trabajadores a clústeres de VPC.

¿Qué ocurre con mi nodo de trabajo durante una actualización?

El nodo trabajador de VPC se sustituye eliminando el nodo trabajador anterior y suministrando un nuevo nodo trabajador que se ejecuta en la versión major.minor o en el parche actualizado. El nodo trabajador de sustitución se crea en la misma zona y en la misma agrupación de nodos trabajadores, y con el mismo tipo que el nodo trabajador suprimido. Sin embargo, al nodo trabajador de sustitución se le asigna una nueva dirección IP privada y pierde las marcas o etiquetas personalizadas que ha aplicado al nodo trabajador antiguo (las marcas o etiquetas de la agrupación de nodos trabajadores se siguen aplicando al nodo trabajador de sustitución).

¿Qué pasaría si sustituyera varios nodos de trabajo a la vez?

Si sustituye varios nodos trabajadores al mismo tiempo, se suprimen y se sustituyen simultáneamente, no uno por uno. Asegúrese de que tiene suficiente capacidad en el clúster para volver a planificar las cargas de trabajo antes de sustituir los nodos trabajadores.

¿Qué ocurre si no se crea un nodo de trabajo sustituto?

No se crea un nodo trabajador de sustitución si la agrupación de nodos trabajadores no tiene el reequilibrio automático habilitado.

Actualización de las versiones (tipos de máquina)

Antes de empezar:

• Acceda al clúster de Red Hat OpenShift.
• Los datos del nodo trabajador se suprimen. Considere la posibilidad de almacenar los datos en el almacenamiento persistente fuera del nodo trabajador.
• Asegúrate de que tienes el archivo « Operador o el rol de acceso a la plataforma IAM de Administrador ».

Para actualizar las versiones:

1. Obtenga una lista de los nodos trabajadores disponibles y anote su dirección IP privada.

   1. Obtenga una lista de los nodos trabajadores del clúster.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. Obtenga una lista de los nodos trabajadores de la agrupación de nodos trabajadores. Anote el **ID** y la **IP privada**.
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. Obtenga los detalles de un nodo trabajador. En la salida, anote la zona y el ID de VLAN privada y pública para los clústeres clásicos o el ID de subred para clústeres de VPC.
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. Obtenga una lista de las versiones disponibles en la zona.

   ibmcloud oc flavors --zone <zone>
   

3. Cree un nodo trabajador con el nuevo tipo de máquina.

   1. Cree una agrupación de nodos trabajadores con el número de nodos trabajadores que desea sustituir.
      • Clústeres clásicos:

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • Clústeres VPC Generación 2:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. Verifique que la agrupación de nodos trabajadores se ha creado.

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. Añada la zona a la agrupación de nodos trabajadores que ha recuperado anteriormente. Cuando se añade una zona, los nodos trabajadores definidos en la agrupación de nodos trabajadores se suministran en la zona y se tienen en cuenta para la futura planificación de la carga de trabajo. Si desea distribuir los nodos trabajadores en varias zonas, elija una ubicación multizona [clásica](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) o [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc).
       * Clústeres clásicos:
           ```sh {: pre}
           ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * Clústeres VPC:
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. Espere a que se desplieguen los nodos trabajadores. Cuando el estado del nodo trabajador pase a ser Normal, significa que el despliegue ha finalizado.

   ibmcloud oc worker ls --cluster CLUSTER
   

5. Elimine el nodo trabajador antiguo. Nota: Si va a eliminar una versión que se factura mensualmente (como las nativas), se le facturará todo el mes.

   1. Elimine la agrupación de nodos trabajadores con el tipo de máquina antiguo. Al eliminar una agrupación de nodos trabajadores se eliminan todos los nodos trabajadores de la agrupación en todas las zonas. El proceso puede tardar varios minutos en completarse.

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. Verifique que la agrupación de nodos trabajadores se ha eliminado.
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. Verifique que los nodos trabajadores se han eliminado del clúster.

   ibmcloud oc worker ls --cluster CLUSTER
   

7. Repita estos pasos para actualizar otras agrupaciones de nodos trabajadores o nodos trabajadores autónomos a distintas versiones.

¿Cómo se reduce la escala de las agrupaciones de nodos trabajadores?

Cuando disminuye el número de nodos trabajadores en una agrupación de nodos trabajadores, como por ejemplo durante una actualización de nodo trabajador o con el mandato ibmcloud oc worker-pool resize, los nodos trabajadores se priorizan para su supresión basándose en varias propiedades, incluido el estado, la salud y la versión.

Esta lógica de prioridad no es relevante para el complemento del programa de escalado automático.

En la tabla siguiente se muestra el orden en el que se prioriza la supresión de los nodos trabajadores.

Puede ejecutar el mandato ibmcloud oc worker ls para ver todas las propiedades de nodo trabajador listadas en la tabla.

Actualización de los componentes de un clúster

El clúster de Red Hat OpenShift on IBM Cloud se suministra con componentes, como Ingress, que se instalan automáticamente cuando se suministra el clúster. De forma predeterminada, IBM actualiza automáticamente estos componentes. No obstante, puede inhabilitar las actualizaciones automáticas de algunos componentes y actualizarlos manualmente de forma independiente de los nodos maestro y trabajador.

¿Qué componentes predeterminados puedo actualizar por separado del clúster?

Opcionalmente, puede inhabilitar las actualizaciones automáticas para los componentes siguientes:

• Fluentd para registro
• Equilibrador de carga de aplicación (ALB) de Ingress

¿Hay algún componente que no pueda actualizar por separado del clúster?

Sí. El clúster se despliega con los siguientes componentes gestionados y recursos asociados que no se pueden cambiar, excepto para escalar pods o editar mapas de configuración para obtener determinadas mejoras de rendimiento. Si intenta modificar uno de estos componentes de despliegue, se restauran sus valores originales con un intervalo regular cuando se actualizan con el clúster maestro. Sin embargo, tenga en cuenta que los recursos que cree asociados a dichos componentes, como las políticas de red de Calico que cree para que las implementen los componentes de despliegue de Calico, no se actualizan.

• Componentes de calico
• Componentes de coredns
• ibm-cloud-provider-ip
• ibm-file-plugin
• ibm-keepalived-watcher
• ibm-master-proxy
• ibm-storage-watcher
• Componentes de kubernetes-dashboard
• metrics-server
• Componentes de olm-operator y catalog (1.16 y posterior)
• vpn

¿Puedo instalar otros complementos o extensiones además de los componentes predeterminados?

Sí. Red Hat OpenShift on IBM Cloud ofrece otros complementos y extensiones entre los que puedes elegir para ampliar las capacidades de tu clúster. Por ejemplo, es posible que desee habilitar los complementos administrados de IBM en su clúster. Debe actualizar estos complementos por separado siguiendo los pasos para actualizar complementos gestionados.

Actualización de complementos gestionados

Los complementos para clústeres gestionados de IBM Cloud Kubernetes Service son una forma sencilla de mejorar tu clúster con funcionalidades de código abierto, como Istio. La versión de la herramienta de código abierto que añade al clúster se prueba en IBM y se aprueba para ser utilizada en IBM Cloud Kubernetes Service. Para actualizar los complementos gestionados que ha habilitado en el clúster a las últimas versiones, consulte Actualización de complementos gestionados.