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

Cloud privé virtuel

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 le 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.

Mise à jour majeure: 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.
Mise à jour mineure: 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.
Remplacement d'un travailleur: 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

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

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. Adresser tous les pods qui ne sont pas dans l'état "Running" ou "Completed".
```
	oc get pods -n openshift-storage
```

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

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 de plus d'un module OSD à la fois peut mettre en péril les données des utilisateurs.

Mise à jour du maître cluster

Mise à jour majeure

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 [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Exemple de commande :

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

Attendez la fin de la mise à jour du maître.

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

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

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

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

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.

Réduction d' OpenShift Data Foundation

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

Pour chaque noeud worker que vous avez trouvé à l'étape précédente, recherchez les déploiements rook-ceph-mon et rook-ceph-osd.
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```
Si les pods Noobaa se bloquent pendant la vidange, vous pouvez les NooBaa supprimer manuellement afin qu'ils soient programmés sur un autre nœud.

Supprimez les cosses Noobaa restantes dans l'ordre suivant.

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

Réduisez les déploiements que vous avez trouvés à l'étape précédente.

	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 et arrêt du noeud worker

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

effectuer une opération cordon du noeud L'opération cordon du noeud empêche la planification de tous les disques sur ce noeud.
```
oc adm cordon NODE_NAME
```
Exemple de sortie
```
node/10.241.0.4 cordoned
```

É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"

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

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

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

Nœuds de travail « bare metal » uniquement: si vous mettez à jour ou remplacez un nœud de travail « bare metal », suivez les étapes ci-dessous pour nettoyer les volumes persistants 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.

Identifiez tous les volumes persistants (PV) en état « Released » associés à la classe de stockage « localblock » sur le nœud que vous mettez à jour.

	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

S'il y a des PV dans 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
```
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
```
Dans le pod de débogage, accédez au répertoire racine de l'hôte.
```
	chroot /host
```

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

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.
Quitter le pod de débogage.
```
	exit
	exit
```

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

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, de nouveaux volumes persistants seront automatiquement créés et planifiés sur le nœud « bare metal » après son redémarrage. Passez à la section suivante pour mettre à jour le nœud de travail.

Mise à jour du nœud de travail

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

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*

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 kube-*** Nœuds de travail VSI: Mise à jour mineure Exemple de commande pour remplacer le nœud de travailleur et appliquer la dernière mise à jour du correctif. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update Nœuds de travail VSI: Worker replace Exemple de commande pour remplacer le nœud de travailleur sans appliquer la dernière mise à jour du correctif. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** 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

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

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

Vérifier que le pod OSD est apparu sur le nœud remplacé dans un état running. Si le pod est en marche, passez à l'étape 7. Si le module est défaillant, procédez comme suit steps.If Plus d'un module OSD n'est pas Running, arrêtez-vous et contactez le service d'assistance. 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.
Accédez au projet openshift-storage.
```
	oc project openshift-storage
```
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.
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
```

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

Ajouter le nouveau nœud de stockage

Avant d'ajouter de nouveaux nœuds de stockage, assurez-vous d'avoir effectué les étapes précédentes pour tous les nœuds de stockage de la grappe.

[Mise à jour] {: tag-red} majeure Mise à jour mineure Remplacement des travailleurs

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

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

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

Mise à jour majeure

Vérifiez la version existante.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Mettez à jour le module complémentaire.

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

Vérifiez que le module complémentaire est à jour.
```
	ibmcloud oc cluster addon ls --cluster CLUSTER
```

Mise à jour de votre ressource de cluster

Mise à jour majeure

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

	oc get ocscluster

Exemple de sortie

	NAME             AGE
	ocscluster-vpc   19d

Exécutez la commande suivante pour modifier votre ressource ocscluster.
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

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

Sauvegardez et fermez le fichier.
Attendez que la mise à jour soit terminée.

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

	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