Aggiornamento dei nodi di lavoro classici che utilizzano OpenShift Data Foundation

Infrastruttura classica

Per i cluster Classic con una soluzione di archiviazione come OpenShift Data Foundation è necessario isolare, svuotare e sostituire ogni nodo di lavoro in sequenza. Se hai distribuito OpenShift Data Foundation su un sottoinsieme di nodi di lavoro nel tuo cluster, dopo aver sostituito il nodo di lavoro devi modificare la ocscluster risorsa per includere il nuovo nodo di lavoro.

La seguente esercitazione copre gli aggiornamenti del nodo di lavoro principale e secondario.

Aggiornamento importante: Completa i passi con questa etichetta per applicare un aggiornamento principale, ad esempio se stai aggiornando i tuoi nodi di lavoro a una nuova versione principale, come ad esempio da 4.11 a 4.12 e OpenShift Data Foundation da 4.11 a 4.12.
Aggiornamento minore: Completa la procedura con questa etichetta per applicare un aggiornamento della patch, ad esempio se stai eseguendo l'aggiornamento da 4.12.15_1542_openshift a 4.12.16_1544_openshift mantenendo OpenShift Data Foundation alla versione 4.12.

Il salto di versioni durante un aggiornamento, ad esempio da 4.8 a, non 4.12 è supportato.

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Prima di eseguire l'aggiornamento dei tuoi nodi di lavoro, assicurati di eseguire il backup dei tuoi dati dell'applicazione. Inoltre, pianifica di completare la seguente procedura per un nodo di lavoro alla volta. Ripetere questi passaggi per ogni nodo di lavoro che si desidera aggiornare.

Aggiorna il master cluster

Aggiornamento importante

Se stai aggiornando i tuoi nodi di lavoro a una nuova versione principale, ad esempio da 4.11 a 4.12, aggiorna prima il master cluster.

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

Comando di esempio:

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

Attendere il completamento dell'aggiornamento master.

Determinare quali nodi di lavoro si desidera aggiornare

[Aggiornamento importante] {: tag-red} Aggiornamento minore

Elenca i tuoi nodi di lavoro utilizzando il comando oc get nodes e determinando quali nodi di lavoro vuoi aggiornare.

oc get nodes

Output di esempio

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

Riduci OpenShift Data Foundation

[Aggiornamento importante] {: tag-red} Aggiornamento minore

Per ogni nodo di lavoro trovato nel passo precedente, trova le distribuzioni rook-ceph-mon e rook-ceph-osd.
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```

Riduci le distribuzioni che hai trovato nel passo precedente.

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

Cordone e scarico del nodo di lavoro

[Aggiornamento importante] {: tag-red} Aggiornamento minore

Cordone il nodo. La cordonatura del nodo impedisce la pianificazione di qualsiasi pod su questo nodo.
```
oc adm cordon NODE_NAME
```
Output di esempio
```
node/10.241.0.4 cordoned
```

Svuotare il nodo per rimuovere tutti i pod. Quando scarichi il nodo di lavoro, i pod si spostano sugli altri nodi di lavoro assicurandoti che non vi sia alcun tempo di inattività. Il drenaggio garantisce inoltre che non vi sia alcuna interruzione del budget di interruzione del pod.

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

Output di esempio

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"

Attendere il completamento dello svuotamento, quindi completare la seguente procedura per sostituire il nodo di lavoro.

Aggiorna il nodo di lavoro

[Aggiornamento importante] {: tag-red} Aggiornamento minore

Elenca i tuoi nodi di lavoro utilizzando ibmcloud oc worker ls e trova il nodo di lavoro che hai isolato e svuotato nel passo precedente.

ibmcloud oc worker ls -c CLUSTER

Output di esempio

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*

Aggiorna il nodo di lavoro.

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

Output di esempio

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

Attendi che venga eseguito il provisioning del nodo di sostituzione ed elenca i tuoi nodi di lavoro. Tenere presente che questo processo potrebbe richiedere 20 minuti o più.

oc get nodes

Output di esempio

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

Ripulisci le risorse dal vecchio nodo

[Aggiornamento importante] {: tag-red} Aggiornamento minore

Passare al progetto openshift-storage.
```
oc project openshift-storage
```
Rimuovere l'OSD non riuscito dal cluster. È possibile specificare più OSD non riusciti, se necessario:
```
oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
Il valore FAILED_osd_id è il numero intero nel nome pod immediatamente dopo il prefisso rook-ceph-osd. Il valore FORCE_OSD_REMOVAL deve essere modificato in true nei cluster che hanno solo tre OSD o nei cluster con spazio insufficiente per ripristinare tutte e tre le repliche dei dati dopo la rimozione di OSD.
Verificare che OSD sia stato rimosso correttamente controllando lo stato del pod ocs - osd - removal - job.
```
oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

Verificare che la rimozione OSD sia stata completata.

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

Output di esempio

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

Identificare il PV (Persistent Volume) associato alla PVC (Persistent Volume Claim) dal nodo precedente:
```
oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
```
Se c'è un PV in stato Rilasciato, eliminarlo:
```
oc delete pv <persistent_volume>
```

Aggiungere i nuovi nodi di memoria

[Aggiornamento importante] {: tag-red} Aggiornamento minore

Attendi che i pod OpenShift Data Foundation vengano distribuiti al nuovo nodo di lavoro. Verifica che i volumi persistenti OSD siano creati e che tutti i pod siano in uno stato Running.
```
oc get pv
oc get ocscluster
oc get pods -n openshift-storage
```

Verifica che tutti gli altri pod OpenShift Data Foundation richiesti siano in stato In esecuzione.

oc get pod -n openshift-storage | grep mon

Output di esempio:

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

Verificare che i nuovi pod OSD siano in esecuzione sul nodo di sostituzione:

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

Identifica la distribuzione del pod crashcollector.

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

Se esiste una distribuzione crashcollector, eliminarla.

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

Eliminare ocs - osd - removal - job.

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

Output di esempio:

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

Aggiorna il componente aggiuntivo OpenShift Data Foundation

Aggiornamento importante

Verificare la versione esistente.

ibmcloud oc cluster addon ls --cluster CLUSTER

Aggiornare il componente aggiuntivo.

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

Verificare che il componente aggiuntivo sia aggiornato.
```
ibmcloud oc cluster addon ls --cluster CLUSTER
```

Aggiorna la risorsa cluster

Aggiornamento importante

Ottieni il nome della tua risorsa ocscluster.

oc get ocscluster

Output di esempio

NAME             AGE
ocscluster-vpc   19d

Esegui il seguente comando per modificare la tua risorsa ocscluster.
```
oc edit ocscluster OCS-CLUSTER-NAME
```

Impostare il parametro ocsUpgrade su true.

...
spec:
    billingType: hourly
monSize: 20Gi
autoDiscoverDevices: true
numOfOsd: 1
ocsUpgrade: true
osdSize: 250Gi
status:
    storageClusterStatus: Decreasing the capacity not allowed

Salva e chiudi il file.
Attendere il completamento dell'aggiornamento.

Verificare che le risorse storagecluster e cephcluster siano distribuite correttamente.

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