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

Virtual Private Cloud

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.

Major update: 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.
Minor update: 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.
Worker replace: Complete los pasos con estos pasos de etiqueta si está sustituyendo un nodo trabajador en la misma versión de parche. Debe repetir estos pasos para cada nodo que desee 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

Major update Minor update Worker replace

Enumera los pods ejecutando el siguiente comando. Compruebe que todos los pods del espacio de nombres openshift-storage se encuentran en buen estado. Aborda cualquier pod que no se encuentre en estado Completed o Running.
```
	oc get pods -n openshift-storage
```

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

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. Apagar más de un pod de OSD a la vez podría poner en peligro los datos de los usuarios.

Actualizar el maestro de clúster

Major update

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_NAME --version MAJOR.MINOR.PATCH --force-update

Mandato de ejemplo:

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

Espera unos minutos y, a continuación, comprueba que la actualización principal se haya completado.
```
	  ibmcloud oc cluster ls
```

Decida qué nodos de almacenamiento desea actualizar o sustituir

Major update Minor update Worker replace

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 funcione correctamente

Major update Minor update Worker replace

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.

Delimitar y reducir la escala de la base de datos OpenShift

Major update Minor update Worker replace

Reducir la escala de las implementaciones de rook-ceph-mon, rook-ceph-osd, y crashcollector antes de vaciarlas garantiza que estos procesos de almacenamiento se cierren correctamente en lugar de ser expulsados de forma forzada. Los pods en los que se ejecuta OSD y de supervisión deben apagarse de forma controlada para que Ceph pueda detener de forma segura las operaciones de E/S y mantener la integridad de los datos mientras el nodo está desconectado. Una vez que el nodo actualizado o sustituido se vuelve a incorporar al clúster, el operador de Rook-Ceph escala automáticamente estas implementaciones hasta alcanzar de nuevo su número original de réplicas.

Acordone el nodo. Al acordonar el nodo se evita que se programen pods en él mientras se reducen las implementaciones de ODF.
```
	oc adm cordon NODE_NAME
```
Salida de ejemplo
```
	node/10.241.0.4 cordoned
```
Busca los pods rook-ceph-osd y rook-ceph-mon que se están ejecutando en el nodo que estás actualizando. Toma nota de los nombres de los pods que aparecen en la salida; los necesitarás en el siguiente paso.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
El nombre de la implementación es el nombre del pod sin los sufijos ReplicaSet y el ID del pod al final. Por ejemplo, un pod llamado rook-ceph-osd-1-6d9f99c68f-pgvxt pertenece a la implementación rook-ceph-osd-1, y un pod llamado rook-ceph-mon-e-85fbb8bcc-kttbt pertenece a la implementación rook-ceph-mon-e.
Reduzca las implementaciones de los pods que ha encontrado en el paso anterior. Sustituye ROOK_CEPH_MON_DEPLOYMENT y ROOK_CEPH_OSD_DEPLOYMENT por los nombres de las implementaciones que has obtenido a partir de los nombres de los pods. Si el comando anterior no ha devuelto ningún rook-ceph-mon pod rook-ceph-osd en este nodo, omite estos dos comandos y pasa al comando crashcollector.
```
	oc scale deployment ROOK_CEPH_MON_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment ROOK_CEPH_OSD_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE_NAME --replicas=0 -n openshift-storage
```
Si el comando devuelve error: no objects passed to scale, comprueba que no haya ningún pod de crashcollector en ejecución en este nodo ejecutando oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep crashcollector. Si no se devuelve ningún pod, puedes omitir este comando sin problema y continuar.

Drene el nodo de trabajador

Major update Minor update Worker replace

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"

Si algún pod de NooBaa se queda atascado durante el proceso de vaciado, elimínalo en el siguiente orden para que se vuelva a programar en un nodo diferente.

	oc delete pod -n openshift-storage -l app=noobaa-db

	oc delete pod -n openshift-storage -l app=noobaa-core

	oc delete pod -n openshift-storage -l app=noobaa-endpoint

	oc delete pod -n openshift-storage -l app=noobaa-operator

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»

Major update Minor update Worker replace

Solo para nodos de trabajo bare metal: si va a actualizar o sustituir un nodo de trabajo bare metal, siga estos pasos para borrar los discos ODF 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.

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
```
Dentro del módulo de depuración, accede al directorio raíz del host.
```
	chroot /host
```

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

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.
Sal del pod de depuración.
```
	exit
	exit
```

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

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, pasa a la siguiente sección para actualizar el nodo de trabajo. Los nuevos volúmenes persistentes se crean y programan automáticamente en el nodo bare metal tras su recarga.

Actualizar el nodo trabajador

Major update Minor update Worker replace

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*

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 NODE_NAME Nodos de trabajo de VSI: Ejemplo Major updateMinor update comando para sustituir el nodo de trabajo y aplicar la última actualización de parches. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME --update Nodos de trabajo de VSI: Ejemplo Worker replace comando para sustituir el nodo de trabajo sin aplicar la última actualización de parches. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME 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

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

Major update Minor update Worker replace

Una vez que el nodo vuelve a incorporarse al clúster, el operador Rook-Ceph vuelve a escalar automáticamente las implementaciones de rook-ceph-mon, rook-ceph-osd, y crashcollector. Comprueba que los pods de ODF estén en funcionamiento antes de continuar.

Comprueba que los pods rook-ceph-osd que rook-ceph-mon se redujeron anteriormente hayan vuelto al estado Running en el nodo actualizado. Sustituya por NODE_NAME el nombre del nodo actualizado o sustituido.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
Comprueba que el resultado muestre y rook-ceph-mon rook-ceph-osd pods en estado Running. Si aún faltan algunos pods o aún no se han creado Running, espera unos minutos y vuelve a ejecutar el comando antes de continuar.
Comprueba que el pod de OSD se haya iniciado en el nodo sustituido en un estado Running. Sustituya por NODE_NAME el nombre del nuevo nodo de sustitución.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep osd
```
Si el pod está en ejecución, continúa actualizando el recurso OcsCluster con el nuevo nodo. Si el pod ha fallado, sigue estos pasos. Si no hay más de un pod de 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.
Vaya al proyecto openshift-storage.
```
	oc project openshift-storage
```
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.
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
```

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

Solo nodos de trabajo bare metal: una vez eliminado el OSD, identifique cualquier volumen persistente (PV) en estado Released que esté asociado a la clase de almacenamiento localblock. La eliminación del OSD coloca estos PV en el estado Released, por lo que este paso debe completarse una vez eliminado el OSD.
```
	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
```
Solo para nodos de trabajo bare metal: si hay algún PV en 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
```

Actualiza el recurso OcsCluster con el nuevo nodo

Antes de continuar con los pasos siguientes, asegúrate de haber completado los pasos anteriores para este nodo de almacenamiento antes de pasar al siguiente nodo del clúster.

Major update Minor update Worker replace

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 ha aplicado ODF a todos sus nodos de trabajo y no ha limitado la implementación a un subconjunto de nodos, omita este paso y continúe con Actualizar el complemento Data Foundation de OpenShift.

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
```
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
```

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

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

Major update

Compruebe la versión existente.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Actualice el complemento.

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

Comprueba que el complemento esté actualizado.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Actualizar el recurso de clúster

Major update

Consigue el nombre de tu recurso ocscluster.

	oc get ocscluster

Salida de ejemplo

	NAME             AGE
	ocscluster-vpc   19d

Ejecuta el siguiente comando para editar tu recurso ocscluster.
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

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

Guarde y cierre el archivo.
Espera a que finalice la actualización.

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

	oc get storagecluster -n openshift-storage

Ejemplo de resultado.

	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

Ejemplo de resultado.

	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

Ejemplo de resultado.

	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