Mise à jour des nœuds de travail Classic utilisant la base de données OpenShift

Infrastructure classique

Pour les clusters Classic dotés d’une solution de stockage telle qu’ OpenShift Data Foundation, vous devez isoler, vider et remplacer chaque nœud de travail de manière séquentielle. Si vous avez déployé OpenShift Data Foundation sur un sous-ensemble de noeuds de travail dans votre cluster, après avoir remplacé le noeud de travail, vous devez ensuite modifier la ressource ocscluster pour inclure le nouveau noeud de travail.

Le tutoriel suivant décrit les mises à jour des noeuds worker majeurs et mineurs.

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 de 4.11 à 4.12 et OpenShift Data Foundation de 4.11 à 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.

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.

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éterminez les noeuds worker que vous souhaitez mettre à jour

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

Répertoriez vos noeuds worker à l'aide de la commande oc get nodes et déterminez les noeuds worker 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

Réduction d' OpenShift Data Foundation

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

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

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

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 la fin de la vidange, puis effectuez les étapes suivantes pour remplacer le noeud worker.

Mise à jour du noeud worker

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

Répertoriez vos noeuds worker à l'aide de 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*

Mettez à jour le noeud worker.

ibmcloud oc worker update -c CLUSTER --worker kube-***

Exemple de sortie

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 remplacement soit provisionné, puis répertoriez 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

Accédez au projet openshift-storage.
```
oc project openshift-storage
```
Supprimez l'OSD ayant échoué du cluster. Vous pouvez spécifier plusieurs OSD ayant échoué 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 l'OSD a été supprimé en vérifiant le statut du pod ocs-osd-removed-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

Identifiez le volume persistant (PV) associé à la réservation de volume persistant (PVC) à partir de l'ancien noeud:
```
oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
```
S'il existe un volume persistant à l'état Publié, supprimez-le:
```
oc delete pv <persistent_volume>
```

Ajouter les nouveaux noeuds de stockage

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

Attendez que les nacelles OpenShift Data Foundation se déploient sur le nouveau worker. Vérifiez que les volumes persistants OSD 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 de nouveaux pods OSD sont en cours d'exécution sur le noeud de remplacement:
```
oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd
```

Identifiez le déploiement de pod crashcollector.

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

S'il existe un déploiement crashcollector, supprimez-le.

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

Supprimez le travail de suppression ocs-osd.

oc delete -n openshift-storage job ocs-osd-removal-job

Exemple de sortie :

job.batch "ocs-osd-removal-job" deleted

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
autoDiscoverDevices: true
numOfOsd: 1
ocsUpgrade: true
osdSize: 250Gi
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