Aktualisierung von Classic-Worker-Knoten, die die OpenShift Data Foundation verwenden

Klassische Infrastruktur

Bei Classic-Clustern mit einer Speicherlösung wie der OpenShift-Data-Foundation müssen Sie jeden Worker-Knoten nacheinander isolieren, leeren und austauschen. Wenn Sie OpenShift Data Foundation auf einer Untergruppe von Workerknoten in Ihrem Cluster bereitgestellt haben, müssen Sie nach dem Ersetzen des Workerknotens die Ressource ocscluster bearbeiten, um den neuen Workerknoten einzuschließen.

Das folgende Lernprogramm behandelt Aktualisierungen von Haupt-und Nebenworkerknoten.

Wichtiges Update: Führen Sie die Schritte mit dieser Bezeichnung aus, um eine Hauptaktualisierung anzuwenden, wenn Sie beispielsweise Ihre Arbeitsknoten auf eine neue Hauptversion aktualisieren, wie z. B. von 4.11 auf 4.12 sowie OpenShift Data Foundation von 4.11 auf 4.12.
Kleinere Aktualisierung: Führen Sie die Schritte mit dieser Bezeichnung aus, um eine Patchaktualisierung anzuwenden, z. B. wenn Sie eine Aktualisierung von 4.12.15_1542_openshift auf 4.12.16_1544_openshift durchführen und dabei OpenShift Data Foundation in Version 4.12 beibehalten.

Das Überspringen von Versionen während eines Upgrades, beispielsweise von 4.8 auf, 4.12 wird nicht unterstützt.

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

Bevor Sie Ihre Workerknoten aktualisieren, stellen Sie sicher, dass Sie Ihre App-Daten sichern. Planen Sie außerdem, die folgenden Schritte für jeweils einen Workerknoten auszuführen. Wiederholen Sie die Schritte für jeden Workerknoten, den Sie aktualisieren wollen.

Cluster-Master aktualisieren

Wichtiges Update

Wenn Sie Ihre Workerknoten auf eine neue Hauptversion aktualisieren, z. B. von 4.11 auf 4.12, aktualisieren Sie zuerst den Cluster-Master.

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

Beispielbefehl:

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

Warten Sie, bis die Masteraktualisierung abgeschlossen ist.

Zu aktualisierende Workerknoten festlegen

Wichtiges Update Kleines Update

Listen Sie Ihre Workerknoten mit dem Befehl oc get nodes auf und ermitteln Sie, welche Workerknoten Sie aktualisieren möchten.

oc get nodes

Beispielausgabe

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

Scale-down für OpenShift Data Foundation durchführen

Wichtiges Update Kleines Update

Suchen Sie für jeden Workerknoten, den Sie im vorherigen Schritt gefunden haben, die Bereitstellungen rook-ceph-mon und rook-ceph-osd.
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```

Führen Sie ein Scale-down für die Bereitstellungen durch, die Sie im vorherigen Schritt gefunden haben.

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

Workerknoten anschnallen und bereinigen

Wichtiges Update Kleines Update

Riegeln Sie den Knoten ab. Durch das Abriegeln des Knotens wird verhindert, dass Pods auf diesem Knoten geplant werden.
```
oc adm cordon NODE_NAME
```
Beispielausgabe
```
node/10.241.0.4 cordoned
```

Bereinigen Sie den Knoten, um alle Pods zu entfernen. Wenn Sie den Workerknoten bereinigen, werden die Pods auf die anderen Workerknoten verschoben, um sicherzustellen, dass keine Ausfallzeit auftritt. Durch das Entleeren wird außerdem sichergestellt, dass das Budget für Podunterbrechungen nicht beeinträchtigt wird.

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

Beispielausgabe

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"

Warten Sie, bis das Entleeren abgeschlossen ist, und führen Sie dann die folgenden Schritte aus, um den Workerknoten auszutauschen.

Workerknoten aktualisieren

Wichtiges Update Kleines Update

Listen Sie Ihre Workerknoten mithilfe von ibmcloud oc worker ls auf und suchen Sie den Workerknoten, den Sie im vorherigen Schritt gesperrt und bereinigt haben.

ibmcloud oc worker ls -c CLUSTER

Beispielausgabe

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*

Aktualisieren Sie den Workerknoten.

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

Beispielausgabe

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

Warten Sie, bis der Ersatzknoten bereitgestellt wurde, und listen Sie dann Ihre Worker-Knoten auf. Beachten Sie, dass dieser Prozess 20 Minuten oder länger dauern kann.

oc get nodes

Beispielausgabe

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

Ressourcen auf dem alten Knoten bereinigen

Wichtiges Update Kleines Update

Navigieren Sie zum Projekt openshift-storage.
```
oc project openshift-storage
```
Entfernen Sie das fehlerhafte OSD aus dem Cluster. Sie können bei Bedarf mehrere fehlgeschlagene OSDs angeben:
```
oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
Der Wert FAILED_osd_id ist die ganze Zahl im Podnamen direkt nach dem Präfix rook-ceph-osd. Der Wert FORCE_OSD_REMOVAL muss in Clustern mit nur drei OSDs in true geändert werden oder in Clustern mit nicht ausreichendem Speicherplatz, um alle drei Replikate der Daten nach dem Entfernen des OSD wiederherzustellen.
Überprüfen Sie, ob das Betriebssystem erfolgreich entfernt wurde, indem Sie den Status des Pods ocs-osd-removal-job überprüfen.
```
oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

Überprüfen Sie, ob das Entfernen des OSD abgeschlossen ist.

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

Beispielausgabe

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

Geben Sie den Persistent Volume (PV) an, der dem Persistent Volume Claim (PVC) aus dem alten Knoten zugeordnet ist:
```
oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
```
Wenn sich ein PV im Status 'Freigegeben' befindet, löschen Sie ihn:
```
oc delete pv <persistent_volume>
```

Neue Speicherknoten hinzufügen

Wichtiges Update Kleines Update

Warten Sie, bis die OpenShift Data Foundation-Pods auf dem neuen Worker bereitgestellt wurden. Überprüfen Sie, ob die persistenten OSD-Datenträger erstellt wurden und ob sich alle Pods im Status Running befinden.
```
oc get pv
oc get ocscluster
oc get pods -n openshift-storage
```

Überprüfen Sie, ob sich alle anderen erforderlichen OpenShift Data Foundation-Pods im Status 'Aktiv' befinden.

oc get pod -n openshift-storage | grep mon

Beispielausgabe:

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

Überprüfen Sie, ob neue OSD-Pods auf dem Ersatzknoten ausgeführt werden:

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

Geben Sie die crashcollector-Podbereitstellung an.

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

Wenn eine crashcollector-Implementierung vorhanden ist, löschen Sie sie.

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

Löschen Sie den Job ocs-osd-removal-job.

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

Beispielausgabe:

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

OpenShift Data Foundation-Add-on aktualisieren

Wichtiges Update

Überprüfen Sie die vorhandene Version.

ibmcloud oc cluster addon ls --cluster CLUSTER

Aktualisieren Sie das Add-on.

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

Stellen Sie sicher, dass das Add-on auf dem neuesten Stand ist.
```
ibmcloud oc cluster addon ls --cluster CLUSTER
```

Clusterressource aktualisieren

Wichtiges Update

Rufen Sie den Namen Ihrer Ressource ocscluster ab.
```
oc get ocscluster
```
Beispielausgabe
```
NAME             AGE
ocscluster-vpc   19d
```
Führen Sie den folgenden Befehl aus, um Ihre Ressource ocscluster zu bearbeiten.
```
oc edit ocscluster OCS-CLUSTER-NAME
```

Setzen Sie den Parameter ocsUpgrade auf true.

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

Speichern und schließen Sie die Datei.
Warten Sie, bis die Aktualisierung abgeschlossen ist.

Stellen Sie sicher, dass die Ressourcen storagecluster und cephcluster ordnungsgemäß implementiert sind.

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