Actualización o sustitución de nodos de trabajo de VPC que utilizan OpenShift Data Foundation

Nube privada virtual

En el caso de los clústeres VPC que utilicen una solución de almacenamiento como OpenShift Data Foundation, es necesario aislar, vaciar y actualizar cada nodo de trabajo de forma secuencial. En el caso de los nodos de trabajo «bare metal», ahora puedes utilizar el comando « worker reload » en lugar de « worker replace ». Si ha implementado OpenShift Data Foundation en un subconjunto de nodos de trabajo de su clúster, tras actualizar el nodo de trabajo deberá editar el recurso ocscluster para incluir el nuevo nodo de trabajo.

El siguiente tutorial cubre tanto las actualizaciones mayores y menores como las actualizaciones de los nodos trabajadores.

Actualización importante
Complete los pasos con esta etiqueta para aplicar una actualización importante; por ejemplo, si está actualizando los nodos trabajadores a una nueva versión principal, como por ejemplo de 4.11 a 4.12, así como de OpenShift Data Foundation de 4.11 a 4.12.
Actualización menor
Complete los pasos con esta etiqueta para aplicar una actualización de parche, por ejemplo, si está actualizando de 4.12.15_1542_openshift a 4.12.16_1544_openshift mientras mantiene OpenShift Data Foundation en la versión 4.12. Debes repetir estos pasos para cada nodo que desees actualizar.
Sustitución de trabajadores
Complete los pasos con estos pasos de etiqueta si está sustituyendo un nodo trabajador en la misma versión de parche. Debes repetir estos pasos para cada nodo que quieras sustituir.

No se admite saltarse versiones 4.12 durante una actualización, como de 4.8 a.

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

Antes de actualizar los nodos de trabajador, asegúrese de realizar una copia de seguridad de los datos de la aplicación. Asimismo, planifique realizar los pasos siguientes para un nodo de trabajador a la vez. Repita los pasos para cada nodo de trabajador que desee actualizar.

Comprueba el estado de tu clúster de almacenamiento

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Enumera los pods ejecutando el siguiente comando. Compruebe que todos los pods del espacio de nombres openshift-storage se encuentran en buen estado. Diríjase a los pods que no estén en estado "En ejecución" o "Completado".

    	oc get pods -n openshift-storage

  2. Ejecute el siguiente comando y compruebe que la dirección Phase de ocs-storagecluster es Ready.

    	oc get storagecluster -n openshift-storage

    Salida de ejemplo

    	NAME                 AGE     PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   3m49s   Ready              2025-04-06T09:37:49Z   4.16.9

  3. Comprueba el estado del almacenamiento Ceph ejecutando el siguiente comando. Compruebe que la salud es HEALTH_OK, que todos los OSD son up y IN y que todos los pgs son active+clean. Si alguna de estas comprobaciones falla, abra un caso de asistencia. En los detalles del caso, asegúrese de incluir todos los archivos de registro, mensajes de error o salidas de comandos relevantes... Resuelva cualquier problema antes de continuar.

    	oc rsh -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-operator) ceph status -c /var/lib/rook/openshift-storage/openshift-storage.config

    Salida de ejemplo

    	health: HEALTH_OK  # Verify health is HEALTH_OK
	services:
		mon: 3 daemons, quorum a,b,c (age 3h)
		mgr: a(active, since 6h)
		mds: ocs-storagecluster-cephfilesystem:1 {0=ocs-storagecluster-cephfilesystem-b=up:active} 1 up:standby-replay
		osd: 27 osds: 27 up (since 2h), 27 in (since 111m) # Verify OSDs are “up” and “in”
		rgw: 2 daemons active (ocs.storagecluster.cephobjectstore.a, ocs.storagecluster.cephobjectstore.b)
	data:
		pools:   10 pools, 1136 pgs
		objects: 5.50M objects, 3.3 TiB
		usage:   9.9 TiB used, 43 TiB / 53 TiB avail
		pgs:     1136 active+clean   # Verify psgs are active+clean
	io:
		client:   93 KiB/s rd, 2.0 MiB/s wr, 5 op/s rd, 29 op/s wr

Repita estas comprobaciones de estado antes de repetir el procedimiento de actualización para nodos adicionales. Desactivar más de un módulo OSD a la vez puede poner en peligro los datos del usuario.

Actualizar el maestro de clúster

Actualización importante

  1. Si está actualizando los nodos trabajadores a una nueva versión principal, como por ejemplo de 4.11 a 4.12, actualice primero el nodo maestro del clúster.

    	ibmcloud oc cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

    Mandato de ejemplo:

    	ibmcloud oc cluster master update --cluster mycluster --version 4.21.27 --force-update

  2. Espere hasta que finalice la actualización del maestro.

Decida qué nodos de almacenamiento desea actualizar o sustituir

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Enumera tus nodos de trabajo utilizando oc get nodes y determina qué nodos de almacenamiento deseas actualizar.

    	oc get nodes

    Salida de ejemplo

    	NAME           STATUS   ROLES           AGE    VERSION
	10.241.0.4     Ready    master,worker   106s   v1.21.6+4b61f94
	10.241.128.4   Ready    master,worker   22d    v1.21.6+bb8d50a
	10.241.64.4    Ready    master,worker   22d    v1.21.6+bb8d50a

Asegúrate de que el clúster de almacenamiento esté en buen estado

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

Ejecute los siguientes comandos para comprobar el estado del clúster de almacenamiento.

oc get storagecluster -n openshift-storage
oc get cephcluster -n openshift-storage

Asegúrese de que el clúster de almacenamiento está en buen estado antes de continuar.

Reducir OpenShift Data Foundation

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Para cada nodo trabajador que haya encontrado en el paso anterior, busque los despliegues rook-ceph-mon y rook-ceph-osd.

    oc get pods -n openshift-storage -o wide | grep -i <node_name>

    Si los pods de Noobaa se atascan durante el drenaje, puede eliminarlos manualmente para que se NooBaa programen en un nodo diferente.

  2. Elimine los pods Noobaa restantes en el siguiente orden.

       noobaa-db
   noobaa-core
   noobaa-endpoint
   noobaa-operator

  3. Reduzca los despliegues que ha encontrado en el paso anterior.

    	oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage

    	oc scale deployment rook-ceph-osd-2 --replicas=0 -n openshift-storage

    	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE-NAME --replicas=0 -n openshift-storage

Cordon y drene el nodo trabajador

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Acordone el nodo. El acordonamiento del nodo impide que se planiquen pods en este nodo.

    oc adm cordon NODE_NAME

    Salida de ejemplo

    node/10.241.0.4 cordoned

  2. Drene el nodo para eliminar todos los pods. Cuando drena el nodo de trabajador, los pods se mueven a los demás nodos de trabajador asegurándose de que no haya ningún tiempo de inactividad. El drenaje también garantiza que no haya ninguna interrupción del presupuesto de interrupción del pod.

    	oc adm drain NODE_NAME --force --delete-emptydir-data --ignore-daemonsets

    Salida de ejemplo

    	evicting pod "managed-storage-validation-webhooks-7fd79bc9f7-pdpv6"
	evicting pod "calico-kube-controllers-647dbbd685-fmrp9"
	evicting pod "certified-operators-2v852"
	evicting pod "csi-snapshot-controller-77fbf474df-47ddt"
	evicting pod "calico-typha-8574d89b8c-7f2cc"
	evicting pod "dns-operator-6d48cbff67-vrrsw"
	evicting pod "router-default-6fc798b98b-9m6kh"
	evicting pod "prometheus-adapter-5b77ffdd5f-hzqrp"
	evicting pod "alertmanager-main-1"
	evicting pod "prometheus-k8s-0"
	evicting pod "network-check-source-66c7fbb86-2r78z"

  3. Espera a que finalice el vaciado y, a continuación, sigue los siguientes pasos para actualizar el nodo de trabajo.

Limpiar los volúmenes persistentes de los nodos de trabajo «bare metal»

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

Solo para nodos de trabajo «bare metal »: Si vas a actualizar o sustituir un nodo de trabajo «bare metal», sigue estos pasos para limpiar los volúmenes persistentes y preparar el nodo para la nueva implementación. Si estás trabajando con nodos de trabajo que son instancias de servidor virtual (VSI), omite esta sección y pasa directamente a « Actualizar el nodo de trabajo ».

Antes de empezar, asegúrate de haber completado los pasos anteriores para aislar y vaciar el nodo de trabajo.

  1. Identifica los volúmenes persistentes (PV) que se encuentren en estado « Released » y que estén asociados a la clase de almacenamiento « localblock » en el nodo que estás actualizando.

    	oc get pv -L kubernetes.io/hostname | grep localblock | grep Released

    Salida de ejemplo

    	local-pv-d6bf175b  1490Gi  RWO  Delete  Released  openshift-storage/ocs-deviceset-0-data-0-6c5pw  localblock  2d22h  compute-1

  2. Si hay algún PV en el estado « Released », elimínalo. Sustituye por <persistent_volume> el nombre del PV del paso anterior.

    	oc delete pv <persistent_volume>

    Mandato de ejemplo

    	oc delete pv local-pv-d6bf175b

    Salida de ejemplo

    	persistentvolume "local-pv-d6bf175b" deleted

  3. Borra los discos ODF del nodo «bare metal» para preparar la creación de un nuevo volumen persistente. Inicia un pod de depuración en el nodo que estás actualizando. Sustituye « <node-name> » por el nombre de tu nodo «worker» de «bare metal».

    	kubectl debug node/<node-name> -it --image=registry.access.redhat.com/ubi8/ubi

    Mandato de ejemplo

    	kubectl debug node/kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -it --image=registry.access.redhat.com/ubi8/ubi

  4. Dentro del módulo de depuración, accede al directorio raíz del host.

    	chroot /host

  5. Borra todos los discos NVMe que haya utilizado ODF. Ajusta el rango de discos (nvme{0..7}n1) en función del número de discos de tu configuración.

    	for disk in /dev/nvme{0..7}n1; do
	  echo "Wiping $disk..."
	  wipefs -af $disk
	  dd if=/dev/zero of=$disk bs=1M count=100
	  sgdisk --zap-all $disk 2>/dev/null || true
	done

  6. Comprueba que los discos estén limpios y que ya no contengan ningún rastro del sistema de archivos.

    	for disk in /dev/nvme{0..7}n1; do
	  echo "=== $disk ==="
	  blkid $disk 2>&1 || echo "Clean"
	done

    Cada disco debería aparecer como «Clean» en el resultado, lo que indica que se han eliminado todas las firmas del sistema de archivos.

  7. Sal del pod de depuración.

    	exit
	exit

  8. Consulta la lista de recursos de localvolumediscoveryresults para encontrar la entrada correspondiente al nodo que estás actualizando.

    	kubectl get localvolumediscoveryresults -n openshift-local-storage

    Salida de ejemplo

    	NAME                                                                      AGE
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3   5d
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000004a1   5d

  9. Elimina el recurso « localvolumediscoveryresults » correspondiente al nodo que estás actualizando. Sustituye « <discovery-result-name> » por el nombre del paso anterior.

    	kubectl delete localvolumediscoveryresults <discovery-result-name> -n openshift-local-storage

    Mandato de ejemplo

    	kubectl delete localvolumediscoveryresults discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -n openshift-local-storage

Una vez completados estos pasos, se crearán automáticamente nuevos volúmenes persistentes y se programarán en el nodo «bare metal» tras su reinicio. Pasa a la siguiente sección para actualizar el nodo de trabajo.

Actualizar el nodo trabajador

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Liste los nodos trabajadores utilizando el mandato ibmcloud oc worker ls y busque el nodo trabajador que ha acordonado y drenado en el paso anterior.

    	ibmcloud oc worker ls -c CLUSTER

    Salida de ejemplo

    	ID                                                 Primary IP     Flavor     State    Status   Zone        Version
	kube-c85ra07w091uv4nid9ug-vpcoc-default-000001c1   10.241.128.4   bx2.4x16   normal   Ready    us-east-3   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000288   10.241.0.4     bx2.4x16   normal   Ready    us-east-1   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000352   10.241.64.4    bx2.4x16   normal   Ready    us-east-2   4.8.29_1544_openshift*

  2. Actualiza el nodo trabajador. Para los nodos trabajadores de metal desnudo, utilice el comando worker reload. Para los nodos trabajadores de instancia de servidor virtual (VSI), utilice el comando worker replace.

Nodos trabajadores de metal desnudo: Utilice el comando worker reload para recargar el nodo trabajador. Este comando es compatible con los trabajadores de hardware físico de VPC. sh {: pre} ibmcloud oc worker reload --worker kube-*** Nodos trabajadores VSI: Actualización menor Ejemplo de comando para reemplazar el nodo trabajador y aplicar la última actualización del parche. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update Nodos trabajadores VSI: Worker replace Ejemplo de comando para reemplazar el nodo worker sin aplicar la última actualización del parche. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** Ejemplo de salida para la sustitución del nodo trabajador VSI: sh {: screen} The replacement worker node is created in the same zone with the same flavor, but gets new public or private IP addresses. During the replacement, all pods might be rescheduled onto other worker nodes and data is deleted if not stored outside the pod. To avoid downtime, ensure that you have enough worker nodes to handle your workload while the selected worker nodes are being replaced. Replace worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288? [y/N]> y Deleting worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288 and creating a new worker node in cluster

  1. Espere a que el nodo trabajador se recargue o sustituya y, a continuación, liste sus nodos trabajadores. Tenga en cuenta que este proceso puede tardar 20 minutos o más.

    	oc get nodes

    Salida de ejemplo

    	NAME           STATUS   ROLES           AGE   VERSION
	10.241.0.4     Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.128.4   Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.64.4    Ready    master,worker   22d   v1.21.6+bb8d50a

Limpiar los recursos del nodo antiguo

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Compruebe que el pod OSD ha aparecido en el nodo sustituido en un estado running. Si el pod está en marcha, continúe con el paso 7. Si el pod ha fallado, realice lo siguiente steps.If no hay más de un pod OSD Running, deténgase y póngase en contacto con el servicio de asistencia. Abra un caso de soporte. En los detalles del caso, asegúrese de incluir todos los archivos de registro, mensajes de error o salidas de comandos relevantes.

  2. Vaya al proyecto openshift-storage.

    	oc project openshift-storage

  3. Elimine el OSD anómalo del clúster. Puede especificar varios OSD fallidos si es necesario.

    	oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -

    El valor FAILED_osd_id es el entero en el nombre de pod inmediatamente después del prefijo rook-ceph-osd. El valor FORCE_OSD_REMOVAL debe cambiarse a true en clústeres que solo tienen tres OSD, o clústeres con espacio insuficiente para restaurar las tres réplicas de los datos después de eliminar el OSD.

  4. Verifique que el OSD se ha eliminado correctamente comprobando el estado del pod ocs-osd-removal-job.

    	oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage

  5. Verifique que la eliminación de OSD se ha completado.

    	oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

    Salida de ejemplo

    	2023-03-10 06:50:04.501511 I | cephosd: completed removal of OSD 0

Añadir el nuevo nodo de almacenamiento

Antes de añadir nuevos nodos de almacenamiento, asegúrese de haber completado los pasos anteriores para todos los nodos de almacenamiento del clúster.

[Actualización importante] {: tag-red}[ Actualización menor] {: tag-blue} Sustitución de trabajadores

  1. Si ha limitado el despliegue de ODF a un subconjunto de nodos trabajadores especificando nombres de nodo durante la instalación, debe actualizar la CRD de ocscluster para que incluya el nuevo nombre.

    Si no ha limitado su configuración a sólo determinados nodos trabajadores, no necesita actualizar el CRD de ocscluster.

    	oc edit ocscluster

    	apiVersion: ocs.ibm.io/v1
	kind: OcsCluster
	metadata:
	name: ocscluster-auto
	spec:
	. . .
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-metro-10iops-tier
	workerNodes:
	- NODE-NAME # Example 10.248.128.42
	- NODE-NAME
	- NODE-NAME

  2. Espere a que los pods de OpenShift Data Foundation se desplieguen en el nuevo nodo de trabajador. Verifique que se hayan creado los nuevos volúmenes persistentes y que todos los pods estén en un estado Running.

    	oc get pv
	oc get ocscluster
	oc get pods -n openshift-storage

  3. Verifique que todos los demás pods de OpenShift Data Foundation necesarios estén en estado En ejecución.

    	oc get pod -n openshift-storage | grep mon

    Salida de ejemplo:

    	rook-ceph-mon-a-cd575c89b-b6k66         2/2     Running
	0          38m
	rook-ceph-mon-b-6776bc469b-tzzt8        2/2     Running
	0          38m
	rook-ceph-mon-d-5ff5d488b5-7v8xh        2/2     Running
	0          4m8s

  4. Compruebe que los nuevos pods OSD se están ejecutando en el nodo de sustitución.

    	oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd

Actualizar el complemento OpenShift Data Foundation

Actualización importante

  1. Compruebe la versión existente.

    	ibmcloud oc cluster addon ls --cluster CLUSTER

  2. Actualice el complemento.

    	ibmcloud oc cluster addon update openshift-data-foundation --cluster CLUSTER --version VERSION

  3. Comprueba que el complemento esté actualizado.

    	ibmcloud oc cluster addon ls --cluster CLUSTER

Actualizar el recurso de clúster

Actualización importante

  1. Consigue el nombre de tu recurso ocscluster.

    	oc get ocscluster

    Salida de ejemplo

    	NAME             AGE
	ocscluster-vpc   19d

  2. Ejecuta el siguiente comando para editar tu recurso ocscluster.

    	oc edit ocscluster OCS-CLUSTER-NAME

  3. Establece el parámetro ocsUpgrade en true.

    	...
	spec:
		billingType: hourly
	monSize: 20Gi
	monStorageClassName: ibmc-vpc-block-10iops-tier
	numOfOsd: 1
	ocsUpgrade: true
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-10iops-tier
	status:
		storageClusterStatus: Decreasing the capacity not allowed

  4. Guarde y cierre el archivo.

  5. Espera a que finalice la actualización.

  6. Verifique que los recursos storagecluster y cephcluster se hayan desplegado correctamente.

    	oc get storagecluster -n openshift-storage
	NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   43h   Ready              2023-06-21T09:22:00Z   4.11.0

    	oc get cephcluster -n openshift-storage
	NAME                             DATADIRHOSTPATH   MONCOUNT   AGE   PHASE   MESSAGE                        HEALTH      EXTERNAL
	ocs-storagecluster-cephcluster   /var/lib/rook     3          43h   Ready   Cluster created successfully   HEALTH_OK   

    	oc get csv -n openshift-storage
	NAME                              DISPLAY                       VERSION   REPLACES                          PHASE
	mcg-operator.v4.11.8              NooBaa Operator               4.11.8    mcg-operator.v4.11.7              Succeeded
	ocs-operator.v4.11.8              OpenShift Container Storage   4.11.8    ocs-operator.v4.11.7              Succeeded
	odf-csi-addons-operator.v4.11.8   CSI Addons                    4.11.8    odf-csi-addons-operator.v4.11.7   Succeeded
	odf-operator.v4.11.8              OpenShift Data Foundation     4.11.8    odf-operator.v4.11.7              Succeeded