Mise à jour ou remplacement des nœuds de travail VPC utilisant OpenShift Data Foundation

Virtual Private Cloud

Pour les clusters VPC dotés d’une solution de stockage telle qu’ OpenShift Data Foundation, vous devez isoler, vider et mettre à jour chaque nœud de travail de manière séquentielle. Pour les nœuds de travail « bare metal », vous pouvez désormais utiliser la commande « worker reload » à la place de « worker replace ». Si vous avez déployé OpenShift Data Foundation sur un sous-ensemble de nœuds de travail de votre cluster, vous devez, après avoir mis à jour le nœud de travail, modifier la ressource ocscluster afin d’y inclure ce nouveau nœud de travail.

Le tutoriel suivant couvre les mises à jour majeures et mineures ainsi que les mises à jour des nœuds de travail.

Major update
Effectuez les étapes avec ce libellé pour appliquer une mise à jour majeure ; par exemple, si vous mettez à jour vos noeuds worker vers une nouvelle version majeure, par exemple 4.11 vers 4.12 et OpenShift Data Foundation depuis 4.11 vers 4.12.
Minor update
Effectuez les étapes avec ce libellé pour appliquer une mise à jour de correctif, par exemple si vous effectuez une mise à jour depuis 4.12.15_1542_openshift vers 4.12.16_1544_openshift tout en conservant OpenShift Data Foundation à la version 4.12. Vous devez répéter ces étapes pour chaque nœud que vous souhaitez mettre à jour.
Worker replace
Effectuez les étapes avec ces étapes de libellé si vous remplacez un noeud worker à la même version de correctif. Vous devez répéter ces étapes pour chaque nœud que vous souhaitez remplacer.

Il n'est pas possible de sauter des versions lors 4.12 d'une mise à niveau, par exemple de 4.8 à.

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Avant de mettre à jour vos noeuds de travail, assurez-vous de sauvegarder vos données d'application. De plus, prévoyez d'effectuer les étapes suivantes pour un noeud de travail à la fois. Répétez les étapes pour chaque noeud de travail que vous souhaitez mettre à jour.

Vérifiez l'état de votre cluster de stockage

Major update Minor update Worker replace

  1. Répertoriez les pods en exécutant la commande suivante. Vérifier que tous les pods de l'espace de noms openshift-storage sont en bon état. Traitez tous les pods qui ne sont pas à l'état Completed Running ou.

    	oc get pods -n openshift-storage

  2. Exécutez la commande suivante et vérifiez que le Phase du ocs-storagecluster est Ready.

    	oc get storagecluster -n openshift-storage

    Exemple de sortie

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

  3. Vérifiez l'état du stockage Ceph en exécutant la commande suivante. Vérifiez que l'état de santé est HEALTH_OK, que tous les OSD sont up et IN et que tous les pgs sont active+clean. Si l'une de ces vérifications échoue, ouvrez un dossier d'assistance. Dans les détails de l'affaire, veillez à inclure tous les fichiers journaux, messages d'erreur ou sorties de commande pertinents. Résoudre les problèmes éventuels avant de poursuivre.

    	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

    Exemple de sortie

    	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

Répétez ces contrôles de santé avant de répéter la procédure de mise à jour pour d'autres nœuds. L'arrêt simultané de plusieurs pods OSD peut compromettre les données des utilisateurs.

Mise à jour du maître cluster

Major update

  1. Si vous mettez à jour vos noeuds worker vers une nouvelle version majeure, par exemple de 4.11 vers 4.12, mettez d'abord à jour le maître cluster.

    	ibmcloud oc cluster master update --cluster CLUSTER_NAME --version MAJOR.MINOR.PATCH --force-update

    Exemple de commande :

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

  2. Patientez quelques minutes, puis vérifiez que la mise à jour du master est terminée.

    	  ibmcloud oc cluster ls

Déterminer les nœuds de stockage à mettre à jour ou à remplacer

Major update Minor update Worker replace

Répertoriez vos nœuds de travail à l'aide de oc get nodes et déterminez les nœuds de stockage que vous souhaitez mettre à jour.

oc get nodes

Exemple de sortie

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

Assurez-vous que le cluster de stockage fonctionne correctement

Major update Minor update Worker replace

Exécutez les commandes suivantes pour vérifier l'état de la grappe de stockage.

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

Assurez-vous que le cluster de stockage est sain avant de continuer.

OpenShift, Data Foundation : mise en place et réduction de l'échelle

Major update Minor update Worker replace

La réduction des déploiements de rook-ceph-mon, rook-ceph-osd, et crashcollector avant le vidage garantit que ces processus de stockage s'arrêtent correctement au lieu d'être expulsés de force. Les pods exécutant OSD et les pods de surveillance doivent être arrêtés en douceur afin que Ceph puisse mettre en veille les E/S en toute sécurité et préserver l'intégrité des données pendant que le nœud est hors ligne. Une fois que le nœud mis à jour ou remplacé a réintégré le cluster, l’opérateur Rook-Ceph rétablit automatiquement le nombre initial de répliques pour ces déploiements.

  1. effectuer une opération cordon du noeud Le fait de cordonner le nœud empêche tout pod d’être planifié sur ce nœud pendant que vous réduisez l’échelle des déploiements ODF.

    	oc adm cordon NODE_NAME

    Exemple de sortie

    	node/10.241.0.4 cordoned

  2. Recherchez les pods rook-ceph-osd et rook-ceph-mon en cours d'exécution sur le nœud que vous mettez à jour. Notez les noms des pods dans la sortie — vous en aurez besoin à l'étape suivante.

    	oc get pods -n openshift-storage -o wide | grep NODE_NAME

    Le nom du déploiement correspond au nom du pod, sans les suffixes ReplicaSet et pod ID à la fin. Par exemple, un pod nommé appartient rook-ceph-osd-1-6d9f99c68f-pgvxt au déploiement rook-ceph-osd-1, et un pod nommé rook-ceph-mon-e-85fbb8bcc-kttbt appartient au déploiement rook-ceph-mon-e.

  3. Réduisez l'échelle des déploiements des pods que vous avez identifiés à l'étape précédente. Remplacez ROOK_CEPH_MON_DEPLOYMENT et ROOK_CEPH_OSD_DEPLOYMENT par les noms de déploiement que vous avez dérivés des noms de pods. Si la commande précédente n'a renvoyé aucun ou rook-ceph-mon pod rook-ceph-osd sur ce nœud, ignorez ces deux commandes et passez à la commande 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 la commande renvoie error: no objects passed to scale, vérifiez qu'aucun pod crashcollector n'est en cours d'exécution sur ce nœud en exécutant oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep crashcollector. Si aucun pod n'est renvoyé, vous pouvez ignorer cette commande en toute sécurité et continuer.

Arrêtez le noeud worker :

Major update Minor update Worker replace

  1. Égouttez le noeud pour retirer tous les nacelles. Lorsque vous drainez le noeud de travail, les nacelles se déplacent vers les autres nœuds de travail pour s'assurer qu'il n'y a pas de temps d'indisponibilité. Le drainage permet également de s'assurer qu'il n'y a pas de perturbation du budget d'interruption de la nacelle.

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

    Exemple de sortie

    	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"

  2. Si des pods d' NooBaa s se bloquent pendant le processus de vidange, supprimez-les dans l'ordre suivant afin qu'ils soient replanifiés sur un autre nœud.

    	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

  3. Attendez que la vidange soit terminée, puis suivez les étapes suivantes pour mettre à jour le nœud de travail.

Nettoyer les volumes persistants des nœuds de travail « bare metal »

Major update Minor update Worker replace

Nœuds de travail bare metal uniquement: si vous mettez à jour ou remplacez un nœud de travail bare metal, suivez les étapes suivantes pour effacer les disques ODF et préparer le nœud en vue du nouveau déploiement. Si vous utilisez des nœuds de travail sous forme d'instances de serveurs virtuels (VSI), ignorez cette section et passez directement à la section « Mise à jour du nœud de travail ».

Avant de commencer, assurez-vous d'avoir bien suivi les étapes précédentes pour isoler et vider le nœud de travail.

  1. Effacez les disques ODF sur le nœud « bare metal » afin de préparer la création d'un nouveau volume persistant. Lancez un pod de débogage sur le nœud que vous êtes en train de mettre à jour. Remplacez « NODE_NAME » par le nom de votre nœud de travail « bare metal ».

    	kubectl debug node/NODE_NAME -it --image=registry.access.redhat.com/ubi8/ubi

    Exemple de commande

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

  2. Dans le pod de débogage, accédez au répertoire racine de l'hôte.

    	chroot /host

  3. Effacez chaque disque NVMe qui a été utilisé par ODF. Ajustez la plage de disques (nvme{0..7}n1) en fonction du nombre de disques de votre configuration.

    	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

  4. Vérifiez que les disques sont vides et ne contiennent plus aucune trace de système de fichiers.

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

    Chaque disque devrait afficher « Clean » dans la sortie, ce qui indique que toutes les signatures du système de fichiers ont été supprimées.

  5. Quitter le pod de débogage.

    	exit
	exit

  6. Consultez la liste des ressources de l' localvolumediscoveryresults pour trouver l'entrée correspondant au nœud que vous êtes en train de mettre à jour.

    	kubectl get localvolumediscoveryresults -n openshift-local-storage

    Exemple de sortie

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

  7. Supprimez la ressource « localvolumediscoveryresults » associée au nœud que vous êtes en train de mettre à jour. Remplacez « DISCOVERY_RESULT_NAME » par le nom indiqué à l'étape précédente.

    	kubectl delete localvolumediscoveryresults DISCOVERY_RESULT_NAME -n openshift-local-storage

    Exemple de commande

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

Une fois ces étapes terminées, passez à la section suivante pour mettre à jour le nœud de travail. De nouveaux volumes persistants sont automatiquement créés et planifiés sur le nœud bare metal après son redémarrage.

Mise à jour du nœud de travail

Major update Minor update Worker replace

  1. Répertoriez vos noeuds worker à l'aide de la commande ibmcloud oc worker ls et recherchez le noeud worker que vous avez grisé et vidé à l'étape précédente.

    	ibmcloud oc worker ls -c CLUSTER

    Exemple de sortie

    	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. Mettre à jour le nœud de travail. Pour les nœuds de travail en métal nu, utilisez la commande worker reload. Pour les nœuds de travail des instances de serveurs virtuels (VSI), utilisez la commande worker replace.

Nœuds de travail en métal nu: Utilisez la commande worker reload pour recharger le nœud de travail. Cette commande est prise en charge pour les instances « bare metal » VPC. sh {: pre} ibmcloud oc worker reload --worker NODE_NAME Nœuds de travail VSI: Exemple Major updateMinor update de commande permettant de remplacer le nœud de travail et d'appliquer la dernière mise à jour de correctifs. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME --update Nœuds de travail VSI: Exemple Worker replace de commande permettant de remplacer le nœud de travail sans appliquer la dernière mise à jour de correctif. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME Exemple de sortie pour le remplacement d'un nœud de travailleur 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. Attendez que le nœud de travail soit rechargé ou remplacé, puis dressez la liste de vos nœuds de travail. Notez que ce processus peut prendre 20 minutes ou plus.

    	oc get nodes

    Exemple de sortie

    	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

Nettoyer les ressources de l'ancien noeud

Major update Minor update Worker replace

Une fois que le nœud a réintégré le cluster, l’opérateur Rook-Ceph redimensionne automatiquement les déploiements rook-ceph-mon, rook-ceph-osd, et crashcollector. Vérifiez que les pods ODF sont en cours d'exécution avant de continuer.

  1. Vérifiez que les pods rook-ceph-osd et rook-ceph-mon qui ont été réduits précédemment sont de nouveau à l'état Running sur le nœud mis à jour. Remplacez par NODE_NAME le nom du nœud mis à jour ou remplacé.

    	oc get pods -n openshift-storage -o wide | grep NODE_NAME

    Vérifiez que le résultat indique rook-ceph-mon que les pods rook-ceph-osd sont dans l'état Running. Si certains pods manquent encore ou ne sont pas encore disponibles Running, patientez quelques minutes et relancez la commande avant de continuer.

  2. Vérifiez que le pod OSD s’est démarré sur le nœud remplacé et qu’il se trouve dans un état Running. Remplacez par NODE_NAME le nom du nouveau nœud de remplacement.

    	oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep osd

    Si le pod est en cours d'exécution, poursuivez en mettant à jour la ressource OcsCluster avec le nouveau nœud. Si le pod a échoué, procédez comme suit. Si plusieurs pods OSD ne sont pas Running, arrêtez-vous et contactez le support. Ouverture d'un cas de support. Dans les détails de l'affaire, veillez à inclure tout fichier journal, message d'erreur ou résultat de commande pertinent.

  3. Accédez au projet openshift-storage.

    	oc project openshift-storage

  4. Supprimez l'OSD ayant échoué du cluster. Vous pouvez spécifier plusieurs OSD défaillants si nécessaire.

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

    La valeur FAILED_osd_id est l'entier du nom de pod immédiatement après le préfixe rook-ceph-osd. La valeur FORCE_OSD_REMOVAL doit être remplacée par true dans les clusters qui ne comportent que trois OSD, ou dans les clusters dont l'espace est insuffisant pour restaurer les trois répliques des données après le retrait de l'OSD.

  5. Vérifiez que le retrait de l'OSD a abouti en vérifiant le statut du pod ocs-osd-removal-job.

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

  6. Vérifiez que la suppression de l'OSD est terminée.

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

    Exemple de sortie

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

  7. Nœuds de travail bare metal uniquement: une fois l’OSD supprimé, identifiez tous les volumes persistants (PV) dont l’état Released est associé à la classe de stockage localblock. La suppression de l'OSD place ces PV dans l'état Released ; cette étape doit donc être effectuée après la suppression de l'OSD.

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

    Exemple de sortie

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

  8. Nœuds de travail bare metal uniquement: s’il existe des PV à l’état Released, supprimez-les. Remplacez par PERSISTENT_VOLUME le nom du PV de l'étape précédente.

    	oc delete pv PERSISTENT_VOLUME

    Exemple de commande

    	oc delete pv local-pv-d6bf175b

    Exemple de sortie

    	persistentvolume "local-pv-d6bf175b" deleted

Mettre à jour la ressource OcsCluster avec le nouveau nœud

Avant de passer aux étapes suivantes, assurez-vous d'avoir terminé les étapes précédentes pour ce nœud de stockage avant de passer au nœud suivant du cluster.

Major update Minor update Worker replace

  1. Si vous avez limité votre déploiement ODF à un sous-ensemble de noeuds worker en spécifiant des noms de noeud lors de l'installation, vous devez mettre à jour la définition de ressource personnalisée ocscluster pour inclure le nouveau nom. Si vous avez appliqué l’ODF à tous vos nœuds de travail et que vous n’avez pas limité le déploiement à un sous-ensemble de nœuds, ignorez cette étape et passez à la section Mise à jour du module complémentaire Data Foundation d’ OpenShift.

    Si vous n'avez pas limité votre configuration à certains nœuds de travail, vous n'avez pas besoin de mettre à jour le CRD 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. Attendez que les nacelles OpenShift Data Foundation se déploient sur le nouveau worker. Vérifiez que les nouveaux volumes persistants sont créés et que tous les pods sont à l'état Running.

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

  3. Vérifiez que tous les autres pods OpenShift Data Foundation requis sont à l'état En cours d'exécution.

    	oc get pod -n openshift-storage | grep mon

    Exemple de sortie :

    	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. Vérifiez que les nouveaux modules OSD fonctionnent sur le nœud de remplacement.

    	oc get pods -o wide -n openshift-storage| egrep -i NEW_NODE_NAME | egrep osd

Mise à jour du module complémentaire OpenShift Data Foundation

Major update

  1. Vérifiez la version existante.

    	ibmcloud oc cluster addon ls --cluster CLUSTER

  2. Mettez à jour le module complémentaire.

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

  3. Vérifiez que le module complémentaire est à jour.

    	ibmcloud oc cluster addon ls --cluster CLUSTER

Mise à jour de votre ressource de cluster

Major update

  1. Récupérez le nom de votre ressource ocscluster.

    	oc get ocscluster

    Exemple de sortie

    	NAME             AGE
	ocscluster-vpc   19d

  2. Exécutez la commande suivante pour modifier votre ressource ocscluster.

    	oc edit ocscluster OCS-CLUSTER-NAME

  3. Définissez le paramètre ocsUpgrade sur 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. Sauvegardez et fermez le fichier.

  5. Attendez que la mise à jour soit terminée.

  6. Vérifiez que les ressources storagecluster et cephcluster sont correctement déployées.

    	oc get storagecluster -n openshift-storage

    Exemple de sortie.

    	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

    Exemple de sortie.

    	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

    Exemple de sortie.

    	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