概要

OpenShift Container Platform (OCP) 4.8以降は、すべての偶数のマイナーリリース(例: 4.8、4.10、4.12)は延長アップデートサポート(EUS)リリースとなります。

OCP 4.8以降では、4.8 -> 4.10のように、ESU間でアップデートができるようになっています。
但し、正確には、1回のアップデート処理と言うわけではなく、master nodeは、4.8 -> 4.9 -> 4.10のように1つづつバージョンアップして、2回再起動が走ります。
一方で、worker nodeは 4.8 -> 4.10のように1回でアップデートできるので、再起動の数が減るため、全体でのアップデートの時間が少し短縮されるようになります。

とはいえ、実際には、OCP 4.10がGAされてからしばらくは 4.8 -> 4.10へEUS間アップデートできるOCPのマイクロバージョンはなかった気がします。
それが、7月半ばぐらいに、とうとうEUS間アップデートできるパスが出てきたので、今回は実際にEUS間アップデートをやってみた際の手順をメモとして残しておきます。

参考リンク

EUS間アップデート

4.8 -> 4.9に上げるための準備(削除されたAPI対応)

OCPとOperatorのバージョンの互換性

Red Hat OpenShift Container Platform のライフサイクルポリシー

検証構成

OCP構成

アップデート前のOCPクラスタの構成は以下のリンク先と同じ手順でインストールしたOCP 4.8.45の構成となります。

Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール
- OCP 4.8.45をベアメタルのUPIでインストールしています。
- ベアメタルのUPIの構成ですが、node自体はVMwareの仮想マシンで作成しています。

インフラノード

インフラノードは以下の手順で作成しています。

Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する
- モニタリングは、デフォルトのモニタリング(prometheusk8s、alertmanager)のみで、ユーザーワークロードモニタリングはここでは入れていません。
- クラスターロギングは、Elasticsearch、Fluentd、Kibanaの構成です。

モニタリング、ロギングの永続ボリューム

モニタリング、ロギングのPVは以下の手順で作成しています。

Qiita / Local Storage Operatorで、ロギング、モニタリングの永続ボリュームを作成する

Operator

上述の構成をとるために追加で導入しているOperatorは以下になります。

Operator	Channel	更新承認ストラテジー
OpenShift Elasticsearch Operator	stable-5.4	手動
Red Hat OpenShift Logging	stable-5.4	手動
Local Storage	4.8	手動

手順の流れ

ベアメタルUPIのOCPでOCP 4.8.45からOCP 4.10.20までEUS間アップデートする流れは以下のようになります。

アップデートパスの確認

(0)アップデートパスの確認

OCP本体

(1) 4.8 -> 4.9に上げるための準備(削除されたAPI対応)
(2) EUS間アップデートの準備 (worker(infra)のMCPのPause)
(3) チャネルをeus-4.10に変更
(4) バージョンを4.8.45 -> 4.9.40に更新
(5) バージョンが4.9.40になる (*)masterのアップデートのみ(Masterの再起動1回目)
(6) バージョンを4.9.40 -> 4.10.20に更新
(7) バージョンが4.10.20になる (*)masterのアップデートのみ(masterの再起動2回目)
(8) worker(Infra)のMCPのPauseの解除 (*)worker(infra)のアップデート(Worker(Infra)の再起動1回)
(9) masterもworkerも4.10.20になる
(10) CLI(oc)のアップデート

Operator

(1) 適宜必要なものをアップデート(例 Local Storage Operator (stable-4.8 -> stable-4.10)など)
(2) alertmanagerのreplicasが3->2になるのでPVC/PVを一つ削除など
(3) その他個別に導入していたものも対応
((*) Operatorやその他アプリは、OCPとの互換性によっては、OCPを4.10に上げる前にアップデートしておく必要があるものがある場合もありますので適宜判断ください。)

実際の手順

アップデートパスの確認

(0) アップデートパスの確認

アップデートパスの確認は以下のリンクで確認できます。

Red Hat OpenShift Container Platform Update Graph / Update Graph
Red Hat OpenShift Container Platform Update Graph / Update Path
KB / OpenShift Container Platform (OCP) 4 upgrade paths

Update Pathの方で「Current Channel」をeus-4.10を選択し、「Current OpenShift Version」に4.8.45を選択すると、「Target OpenShift Version」のプルダウンから (no update path available) ではないバージョンが表示され、ここでは検証時に選択できる最新のバージョンだった4.10.20を選択することができました。

ここで「Generate」をクリックすると、eus-4.10 channelでは、「4.8.45 -> 4.9.40 -> 4.10.20」の順番のアップデートパスがあることがわかります。

(検証時のOCP 4.9の最新は、OCP 4.9.41だったので、このEUS間アップデートをする場合は、あえて4.9.40にしないとその時点では次のパスがなかったりするので、ここの確認はかなり重要です。)

今回はこのバージョンでEUS間アップデートをやってみます。

OCP本体

(1) 4.8 -> 4.9に上げるための準備(削除されたAPI対応)

OCP 4.8から4.9では、Kubernetes 1.21から1.22になります。これにより非推奨となったv1beta1 APIが大幅に削除されました。
このため、OCP 4.9へのアップデートの際に、管理者はAPIの移行が必要なものを評価し、影響を受けるコンポーネントを適切な新規APIバージョンを使用するように移行する必要があります。

これらの対応の完了後に、管理者は確認をしたという処理を明示的に実施する必要があります。

(admin-acksというconfigmapに"ack-4.8-kube-1.22-api-removals-in-4.9":"true"}というフラグをつける)

この「管理者の確認」処理を完了しないと、OCP 4.9にはアップデートすることはできないため、アップデート後に何かAPIバージョンに関する問題が起こるリスクを減らすことができます。

(参考)OCP 4.9へのアップデートで表示されるメッセージ

参考リンク

4.8 -> 4.9に上げるための準備(削除されたAPI対応)

ここでは、OCP 4.9のドキュメントの記載の手順に従って対応をした際のメモを記載します。

削除される予定のAPIが使用されているかの確認

cluster-adminロールを持つユーザーとしてクラスターにログインします。

APIRequestCountを使用し、削除されるAPIを使用しているかを特定します。

以下のコマンドを実行すると、REMOVEDINRELEASE列で、現在使用中の削除されるAPIを確認することができます。

[root@bastion-01 ~]# oc get apirequestcounts
NAME                                                                           REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
alertmanagerconfigs.v1alpha1.monitoring.coreos.com                                                15                      346
(略)
ingresses.v1beta1.extensions                                                   1.22               12                      333
installplans.v1alpha1.operators.coreos.com                                                        201                     1522
ippools.v1alpha1.whereabouts.cni.cncf.io                                                          10                      242
jobs.v1.batch                                                                                     122                     2417
(略)

以下のように-o jsonフィルターをして確認すると使用されているAPIだけを抽出して表示することができます。
今回はingresses.v1beta1.extensionsが使用されていることがわかります。

[root@bastion-01 ~]# oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'
1.22	ingresses.v1beta1.extensions
[root@bastion-01 ~]#

使用されていた削除される予定のAPIをどのワークロードが使用しているかの確認

洗い出されたingresses.v1beta1.extensionsのAPIをどのワークロードが使用しているかを特定します。
-o jsonpathを使用して、APIRequestCountリソースからusernameおよびuserAgentの値を抽出することができるので、今回はingresses.v1beta1.extensionsに対して以下のコマンドを実行して確認します。

[root@bastion-01 ~]# oc get apirequestcounts ingresses.v1beta1.extensions -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
>   | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT
VERBS       USERNAME                        USERAGENT
list watch  system:kube-controller-manager  cluster-policy-controller/v0.0.0
list watch  system:kube-controller-manager  kube-controller-manager/v1.21.11+6b3cbdd
[root@bastion-01 ~]#

上述で出力したUSERNAME、USERAGENTを確認すると、OCPのドキュメントでは、以下のエントリーは無視して良いとの記載があります。
今回は、これらのエントリーに当てはまっているので、削除されるAPIに対して、特に何も移行処理をしなくても良いことがわかりました。

重要
結果に表示される以下のエントリーは無視しても問題はありません。

system:serviceaccount:kube-system:generic-garbage-collector ユーザーは削除するリソースを検索するため、結果に表示される場合があります。

system:kube-controller-manager および system:cluster-policy-controller ユーザーは、さまざまなポリシーを適用しながらすべてのリソースをウォークスルーするため、結果に表示される場合があります。

削除される予定のAPIの移行

今回は、OCP 4.8に追加でOperatorやアプリケーションを何もデプロイしていないので、Kubernetes v1.22で削除される予定のAPIはほとんど使用されておらず、何も移行対応をする必要がありませんでした。

但し、ユーザーがOperatorやアプリケーションをデプロイしていた場合には、対応が必要なAPIを使用している可能性があります。

対象となるAPI

上述の確認手順で対応が必要なAPIが表示された場合には、以下のKubernetesのドキュメントに従って対応を実施をする必要があります。

Kubernetes Docs
- Deprecated API Migration Guide / Removed APIs by release / v1.22

管理者の確認

削除される予定のAPIを使用しているかを確認して全ての移行の対応が完了したら、管理者は明示的に確認をしたという処理をする必要があります。

以下のコマンドを実行して、評価を完了し、OCP 4.9にアップデートできることを確認したフラグを立てます。

(admin-acksというconfigmapに"ack-4.8-kube-1.22-api-removals-in-4.9":"true"}というフラグをつける)

[root@bastion-01 ~]# oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.8-kube-1.22-api-removals-in-4.9":"true"}}' --type=merge
configmap/admin-acks patched
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get cm -n  openshift-config admin-acks -o yaml
apiVersion: v1
data:
  ack-4.8-kube-1.22-api-removals-in-4.9: "true"
kind: ConfigMap
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "true"
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  creationTimestamp: "2022-07-12T07:59:54Z"
  name: admin-acks
  namespace: openshift-config
  resourceVersion: "683740"
  uid: e1f88089-0a23-40dc-8daf-36704714ec71
[root@bastion-01 ~]#

こうすることで、OCPのGUIから先ほどのメッセージが表示されなくなり、OCP 4.9にアップデートすることができるようになりました。

(2) EUS間アップデートの準備 (worker(infra)のMCPのPause)

ESU間アップデートでは、master nodeは、4.8 -> 4.9 -> 4.10のように1つづつアップデートして、2回再起動が走ります。
一方で、worker nodeは 4.8 -> 4.10のように1回でアップデートし、再起動の回数を1回に抑えることができます。

master nodeのアップデート中にworker nodeがアップデートされないようにするためには、worker用のMachine Config Pool (MCP)にアップデートの一時停止処理(Pause)を実施する必要があります。
この検証環境では、infra nodeのMCPも作成しているため、worker nodeだけではなく、infra nodeにも更新の一時停止処理(Pause)をする必要があります。

[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd24e2400e059460c308e626771bc373    True      False      False      3              3                   3                     0                      18h
master   rendered-master-f192fab4dbcb44579e7df8408dba89a7   True      False      False      3              3                   3                     0                      19h
worker   rendered-worker-bd24e2400e059460c308e626771bc373   True      False      False      2              2                   2                     0                      19h
[root@bastion-01 ~]#

[root@bastion-01 ~]# oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'
machineconfigpool.machineconfiguration.openshift.io/worker patched
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc patch mcp/infra --type merge --patch '{"spec":{"paused":true}}'
machineconfigpool.machineconfiguration.openshift.io/infra patched
[root@bastion-01 ~]#

worker nodeとinfra node用のMCPに一時停止処理(Pause)がされたことを確認します。

[root@bastion-01 ~]# oc get mcp master -o json | jq -r .spec.paused
false
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp worker -o json | jq -r .spec.paused
true
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp infra -o json | jq -r .spec.paused
true
[root@bastion-01 ~]#

(3) チャネルを`eus-4.10`に変更

今回はCLIではなくOCPのGUIからアップデートをしました。

(0) アップデートパスの確認で確認したように、eus-4.10 channelでは、「4.8.45 -> 4.9.40 -> 4.10.20」の順番のアップデートをします。

OCPのGUIのメニューから管理 -> クラスター設定を開き、チャネルのeus-4.8のリンクをクリックします。

表示されるチャネルの選択画面でeus-4.10に変更します。

チャネルがeus-4.10に更新され、アップデートできるバージョンが表示されますので「更新」をクリックします。

(4) バージョンを4.8.45 -> 4.9.40に更新

(0) アップデートパスの確認で確認したように、「4.8.45 -> 4.9.40 -> 4.10.20」というアップデートパスが表示されており、検証時点では、4.9.41にアップデートすると逆に4.10.xに直接アップデートできません。
ですので、今回はアップデートパスがある4.9.40を選択します。

4.9.40へのアップデートが始まります。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.45    True        True          4m50s   Working towards 4.9.40: 71 of 738 done (9% complete)
[root@bastion-01 ~]#

まずはCluster Operatorのアップデートが始まります。

Cluster Operatorのアップデートが大体終わると、新しいMCPのMCを適用するために、master nodeの再起動が始まります。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.8.45    True        True          70m     Working towards 4.9.40: 619 of 738 done (83% complete), waiting on machine-config
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd24e2400e059460c308e626771bc373    False     False      False      3              0                   0                     0                      21h
master   rendered-master-f192fab4dbcb44579e7df8408dba89a7   False     True       False      3              1                   1                     0                      22h
worker   rendered-worker-bd24e2400e059460c308e626771bc373   False     False      False      2              0                   0                     0                      22h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node
NAME        STATUS                     ROLES    AGE   VERSION
infra-01    Ready                      infra    22h   v1.21.11+6b3cbdd
infra-02    Ready                      infra    22h   v1.21.11+6b3cbdd
infra-03    Ready                      infra    22h   v1.21.11+6b3cbdd
master-01   Ready                      master   22h   v1.22.8+f34b40c
master-02   Ready,SchedulingDisabled   master   22h   v1.21.11+6b3cbdd
master-03   Ready                      master   22h   v1.21.11+6b3cbdd
worker-01   Ready                      worker   22h   v1.21.11+6b3cbdd
worker-02   Ready                      worker   22h   v1.21.11+6b3cbdd
[root@bastion-01 ~]#

ここでは、workerとinfraのMCPで再起動の一時停止処理(Paused)を実施したので、workerとinfra nodeはアップデートされずに再起動もされません。

(5) バージョンが4.9.40になる (*)masterのアップデートのみ(Masterの再起動1回目)

OCP 4.9.40へのアップデートが完了します。
workerとinfra nodeはまだ再起動されていないことがわかります。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.9.40    True        False         59s     Cluster version is 4.9.40
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd24e2400e059460c308e626771bc373    False     False      False      3              0                   0                     0                      21h
master   rendered-master-22186c18cde8e5fdc8d6dd770b997e24   True      False      False      3              3                   3                     0                      22h
worker   rendered-worker-bd24e2400e059460c308e626771bc373   False     False      False      2              0                   0                     0                      22h
[root@bastion-01 ~]#

master nodeのkuberntestのバージョンはv1.22にあがりましたが、workerとinfra nodeのバージョンはv1.21のままです。

[root@bastion-01 ~]# oc get node
NAME        STATUS   ROLES    AGE   VERSION
infra-01    Ready    infra    22h   v1.21.11+6b3cbdd
infra-02    Ready    infra    22h   v1.21.11+6b3cbdd
infra-03    Ready    infra    22h   v1.21.11+6b3cbdd
master-01   Ready    master   22h   v1.22.8+f34b40c
master-02   Ready    master   22h   v1.22.8+f34b40c
master-03   Ready    master   22h   v1.22.8+f34b40c
worker-01   Ready    worker   22h   v1.21.11+6b3cbdd
worker-02   Ready    worker   22h   v1.21.11+6b3cbdd
[root@bastion-01 ~]#

[root@bastion-01 ~]# oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.9.40    True        False         False      28m
baremetal                                  4.9.40    True        False         False      22h
cloud-controller-manager                   4.9.40    True        False         False      60m
cloud-credential                           4.9.40    True        False         False      22h
cluster-autoscaler                         4.9.40    True        False         False      22h
config-operator                            4.9.40    True        False         False      22h
console                                    4.9.40    True        False         False      31m
csi-snapshot-controller                    4.9.40    True        False         False      22h
dns                                        4.9.40    True        False         False      22h
etcd                                       4.9.40    True        False         False      22h
image-registry                             4.9.40    True        False         False      22h
ingress                                    4.9.40    True        False         False      3h27m
insights                                   4.9.40    True        False         False      22h
kube-apiserver                             4.9.40    True        False         False      22h
kube-controller-manager                    4.9.40    True        False         False      22h
kube-scheduler                             4.9.40    True        False         False      22h
kube-storage-version-migrator              4.9.40    True        False         False      22h
machine-api                                4.9.40    True        False         False      22h
machine-approver                           4.9.40    True        False         False      22h
machine-config                             4.9.40    True        False         False      78m
marketplace                                4.9.40    True        False         False      22h
monitoring                                 4.9.40    True        False         False      22h
network                                    4.9.40    True        False         False      22h
node-tuning                                4.9.40    True        False         False      49m
openshift-apiserver                        4.9.40    True        False         False      10h
openshift-controller-manager               4.9.40    True        False         False      22h
openshift-samples                          4.9.40    True        False         False      50m
operator-lifecycle-manager                 4.9.40    True        False         False      22h
operator-lifecycle-manager-catalog         4.9.40    True        False         False      22h
operator-lifecycle-manager-packageserver   4.9.40    True        False         False      22h
service-ca                                 4.9.40    True        False         False      22h
storage                                    4.9.40    True        False         False      22h
[root@bastion-01 ~]#

(6) バージョンを4.9.40 -> 4.10.20に更新

(0) アップデートパスの確認で確認したように、「4.8.45 -> 4.9.40 -> 4.10.20」という順番なので、次は4.10.20にアップデートします。

前述の画面の「更新」をクリックして表示される「クラスターの更新」で4.10.20を選択します。

4.10.20へのアップデートが始まります。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.9.40    True        True          66m     Working towards 4.10.20: 234 of 771 done (30% complete)
[root@bastion-01 ~]#

まずはCluster Operatorのアップデートが始まります。

Cluster Operatorのアップデートが大体終わると、新しいMCPのMCを適用するために、master nodeの再起動が始まります。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.9.40    True        True          61m     Working towards 4.10.20: 649 of 771 done (84% complete)
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd24e2400e059460c308e626771bc373    False     False      False      3              0                   0                     0                      27h
master   rendered-master-22186c18cde8e5fdc8d6dd770b997e24   False     True       False      3              2                   2                     0                      28h
worker   rendered-worker-bd24e2400e059460c308e626771bc373   False     False      False      2              0                   0                     0                      28h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node
NAME        STATUS                     ROLES    AGE   VERSION
infra-01    Ready                      infra    28h   v1.21.11+6b3cbdd
infra-02    Ready                      infra    28h   v1.21.11+6b3cbdd
infra-03    Ready                      infra    28h   v1.21.11+6b3cbdd
master-01   Ready                      master   28h   v1.23.5+3afdacb
master-02   Ready                      master   28h   v1.23.5+3afdacb
master-03   Ready,SchedulingDisabled   master   28h   v1.22.8+f34b40c
worker-01   Ready                      worker   28h   v1.21.11+6b3cbdd
worker-02   Ready                      worker   28h   v1.21.11+6b3cbdd
[root@bastion-01 ~]#

ここでは、workerとinfraのMCPで再起動の一時停止処理(Paused)を実施したので、workerとinfra nodeはアップデートされずに再起動もされません。
(OCP 4.10に上がったとにworkerとinfraのMCPのPauseをすぐにResumeしてくださいとのメッセージも表示されています。)

(7) バージョンが4.10.20になる (*)masterのアップデートのみ(masterの再起動2回目)

OCP 4.10.20へのアップデートが完了します。
workerとinfra nodeはまだ再起動されていないことがわかります。

CLIでの確認です。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.20   True        False         33s     Cluster version is 4.10.20
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd24e2400e059460c308e626771bc373    False     False      False      3              0                   0                     0                      27h
master   rendered-master-e5b532b6e0c8576f3ce2b2c986e299f7   True      False      False      3              3                   3                     0                      28h
worker   rendered-worker-bd24e2400e059460c308e626771bc373   False     False      False      2              0                   0                     0                      28h
[root@bastion-01 ~]#

[root@bastion-01 ~]# oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.10.20   True        False         False      3m31s
baremetal                                  4.10.20   True        False         False      28h
cloud-controller-manager                   4.10.20   True        False         False      6h45m
cloud-credential                           4.10.20   True        False         False      28h
cluster-autoscaler                         4.10.20   True        False         False      28h
config-operator                            4.10.20   True        False         False      28h
console                                    4.10.20   True        False         False      3m30s
csi-snapshot-controller                    4.10.20   True        False         False      43m
dns                                        4.10.20   True        False         False      28h
etcd                                       4.10.20   True        False         False      28h
image-registry                             4.10.20   True        False         False      28h
ingress                                    4.10.20   True        False         False      9h
insights                                   4.10.20   True        False         False      28h
kube-apiserver                             4.10.20   True        False         False      28h
kube-controller-manager                    4.10.20   True        False         False      28h
kube-scheduler                             4.10.20   True        False         False      28h
kube-storage-version-migrator              4.10.20   True        False         False      28h
machine-api                                4.10.20   True        False         False      28h
machine-approver                           4.10.20   True        False         False      28h
machine-config                             4.10.20   True        False         False      7h3m
marketplace                                4.10.20   True        False         False      28h
monitoring                                 4.10.20   True        False         False      28h
network                                    4.10.20   True        False         False      28h
node-tuning                                4.10.20   True        False         False      40m
openshift-apiserver                        4.10.20   True        False         False      15h
openshift-controller-manager               4.10.20   True        False         False      28h
openshift-samples                          4.10.20   True        False         False      42m
operator-lifecycle-manager                 4.10.20   True        False         False      28h
operator-lifecycle-manager-catalog         4.10.20   True        False         False      28h
operator-lifecycle-manager-packageserver   4.10.20   True        False         False      28h
service-ca                                 4.10.20   True        False         False      28h
storage                                    4.10.20   True        False         False      28h
[root@bastion-01 ~]#

Kubernetesのバージョンが、masterは、v1.23になっていますが、worekrとinfraはv1.21のままになっています。

[root@bastion-01 ~]# oc get node
NAME        STATUS   ROLES    AGE   VERSION
infra-01    Ready    infra    28h   v1.21.11+6b3cbdd
infra-02    Ready    infra    28h   v1.21.11+6b3cbdd
infra-03    Ready    infra    28h   v1.21.11+6b3cbdd
master-01   Ready    master   28h   v1.23.5+3afdacb
master-02   Ready    master   28h   v1.23.5+3afdacb
master-03   Ready    master   28h   v1.23.5+3afdacb
worker-01   Ready    worker   28h   v1.21.11+6b3cbdd
worker-02   Ready    worker   28h   v1.21.11+6b3cbdd
[root@bastion-01 ~]#

RHCOSのバージョンもmaster nodeは4.10になっていますが、workerとinfra nodeは、4.8のままになっています。

[root@bastion-01 ~]# ssh core@master-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.10
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.8
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@worker-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.8
[root@bastion-01 ~]#

(8) worker(Infra)のMCPのPauseの解除 (*)worker(infra)のアップデート(Worker(Infra)の再起動1回)

worker用のMachine Config Pool (MCP)にアップデートの一時停止処理(Pause)を実施していたので、これを解除します。
この検証環境では、infra nodeのMCPも作成しているため、worker nodeだけではなく、infra nodeにも更新の一時停止処理(Pause)の解除も併せて実施する必要があります。

[root@bastion-01 ~]# oc patch mcp/infra --type merge --patch '{"spec":{"paused":false}}'
machineconfigpool.machineconfiguration.openshift.io/infra patched
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
machineconfigpool.machineconfiguration.openshift.io/worker patched
[root@bastion-01 ~]#

worker nodeとinfra node用のMCPの一時停止処理(Pause)が解除されたことを確認します。

[root@bastion-01 ~]# oc get mcp master -o json | jq -r .spec.paused
false
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp worker -o json | jq -r .spec.paused
false
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp infra -o json | jq -r .spec.paused
false
[root@bastion-01 ~]#

workerとinfra nodeに対しても、新しいMCPのMCを適用するために、workerとinfra nodeの再起動が始まります。

[root@bastion-01 ~]# oc get node
NAME        STATUS                     ROLES    AGE   VERSION
infra-01    Ready                      infra    28h   v1.21.11+6b3cbdd
infra-02    Ready,SchedulingDisabled   infra    28h   v1.21.11+6b3cbdd
infra-03    Ready                      infra    28h   v1.21.11+6b3cbdd
master-01   Ready                      master   28h   v1.23.5+3afdacb
master-02   Ready                      master   28h   v1.23.5+3afdacb
master-03   Ready                      master   28h   v1.23.5+3afdacb
worker-01   Ready,SchedulingDisabled   worker   28h   v1.21.11+6b3cbdd
worker-02   Ready                      worker   28h   v1.21.11+6b3cbdd
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd24e2400e059460c308e626771bc373    False     True       False      3              0                   0                     0                      27h
master   rendered-master-e5b532b6e0c8576f3ce2b2c986e299f7   True      False      False      3              3                   3                     0                      28h
worker   rendered-worker-bd24e2400e059460c308e626771bc373   False     True       False      2              0                   0                     0                      28h
[root@bastion-01 ~]#

GUIで確認します。
workerとinfraのMCP毎に、nodeの再起動が実施されています。

(9) masterもworkerも4.10.20になる

workerとinfra nodeの再起動が完了し、workerとinfra nodeのアップデートも完了したことを確認します。

CLIでも正常にアップグレードしたことを確認します。

clusterversionのVERSIONは4.10.20です。

[root@bastion-01 ~]# oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.20   True        False         23m     Cluster version is 4.10.20
[root@bastion-01 ~]#

MCPで全てのnodeがUPDATEDがTrueになっています。

[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-8c91444541360f1a72459e601c493e77    True      False      False      3              3                   3                     0                      27h
master   rendered-master-e5b532b6e0c8576f3ce2b2c986e299f7   True      False      False      3              3                   3                     0                      28h
worker   rendered-worker-8c91444541360f1a72459e601c493e77   True      False      False      2              2                   2                     0                      28h
[root@bastion-01 ~]#

nodeは全てSTATUSがREADYになり、kubernetesのバージョンもv1.23になっています。

[root@bastion-01 ~]# oc get node
NAME        STATUS   ROLES    AGE   VERSION
infra-01    Ready    infra    28h   v1.23.5+3afdacb
infra-02    Ready    infra    28h   v1.23.5+3afdacb
infra-03    Ready    infra    28h   v1.23.5+3afdacb
master-01   Ready    master   28h   v1.23.5+3afdacb
master-02   Ready    master   28h   v1.23.5+3afdacb
master-03   Ready    master   28h   v1.23.5+3afdacb
worker-01   Ready    worker   28h   v1.23.5+3afdacb
worker-02   Ready    worker   28h   v1.23.5+3afdacb
[root@bastion-01 ~]#

clusteroperatorのVERSIONも全て4.10.20になっています。

[root@bastion-01 ~]# oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.10.20   True        False         False      2m27s
baremetal                                  4.10.20   True        False         False      28h
cloud-controller-manager                   4.10.20   True        False         False      7h8m
cloud-credential                           4.10.20   True        False         False      28h
cluster-autoscaler                         4.10.20   True        False         False      28h
config-operator                            4.10.20   True        False         False      28h
console                                    4.10.20   True        False         False      6m54s
csi-snapshot-controller                    4.10.20   True        False         False      66m
dns                                        4.10.20   True        False         False      28h
etcd                                       4.10.20   True        False         False      28h
image-registry                             4.10.20   True        False         False      4m57s
ingress                                    4.10.20   True        False         False      9h
insights                                   4.10.20   True        False         False      28h
kube-apiserver                             4.10.20   True        False         False      28h
kube-controller-manager                    4.10.20   True        False         False      28h
kube-scheduler                             4.10.20   True        False         False      28h
kube-storage-version-migrator              4.10.20   True        False         False      11m
machine-api                                4.10.20   True        False         False      28h
machine-approver                           4.10.20   True        False         False      28h
machine-config                             4.10.20   True        False         False      7h26m
marketplace                                4.10.20   True        False         False      28h
monitoring                                 4.10.20   True        False         False      28h
network                                    4.10.20   True        False         False      28h
node-tuning                                4.10.20   True        False         False      63m
openshift-apiserver                        4.10.20   True        False         False      16h
openshift-controller-manager               4.10.20   True        False         False      28h
openshift-samples                          4.10.20   True        False         False      65m
operator-lifecycle-manager                 4.10.20   True        False         False      28h
operator-lifecycle-manager-catalog         4.10.20   True        False         False      28h
operator-lifecycle-manager-packageserver   4.10.20   True        False         False      28h
service-ca                                 4.10.20   True        False         False      28h
storage                                    4.10.20   True        False         False      28h
[root@bastion-01 ~]#

RHCOSのバージョンもmaster、infra、worker nodeも全て4.10になっています。

[root@bastion-01 ~]# ssh core@master-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.10
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.10
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@worker-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.10
[root@bastion-01 ~]#

(10) CLI(oc)のアップデート

CLI(oc)も4.10.20のものにアップデートします。(手順は割愛します。)

Operator

OCPのアップデートが完了したら、追加で導入したOperatorやアプリケーションのアップデートなども適宜実施します。
ここでは、以下の作業を実施しました。

(1) 適宜必要なものをアップデート

(例 Local Storage Operator (stable-4.8 -> stable-4.10)など)

アップデート対象の検討

今回導入していたOperatorは以下になります。

OCP 4.8時に導入していたOperatorのバージョン

Operator	Channel	更新承認ストラテジー
OpenShift Elasticsearch Operator	stable-5.4	手動
Red Hat OpenShift Logging	stable-5.4	手動
Local Storage	4.8	手動

Red Hat OpenShift Container Platform のライフサイクルポリシーを確認すると、ロギング(OpenShift Elasticsearch Operator、OpenShift Logging)の5.4は、OCP 4.8、4.9、4.10と互換性があり、OCP 4.8の時点で5.4にしていたので、今回はOCP 4.10アップデート後には何もする必要はありません。

(※)例えばOCP 4.6でロギング4.6を入れていた場合は、OCPをひとつづつバージョンアップしてOCP 4.9にする前に、一旦ロギングを5.4などにアップデートする必要があったりします。

Local Storage Operatorに関しては、Red Hat OpenShift Container Platform のライフサイクルポリシーにはOCPとの互換性の記述の記載はありません。

ですが、一旦Local Storage Operatorは4.8のまま、OCP自体は4.10にアップデートはできたので、併せてここでLocal Storage Operatorも4.10にしておきます。

OCP 4.10アップデート後にOperatorもアップデートした場合のバージョン

Operator	Channel	更新承認ストラテジー
OpenShift Elasticsearch Operator	stable-5.4	手動
Red Hat OpenShift Logging	stable-5.4	手動
Local Storage	4.10	手動

(補足) Local Storage Opeartor自体のアップデートの範囲

Operatorのcsvのolm.skipRangeを確認すると、このOperatorのこのバージョンには、どのバージョンからアップデートできるかを表していると思われる情報があります。

(以下はLocal Storage Operatorを4.10にあげた後のcsvの表示)
Local Storage OperatorのChannel 4.10にした際の4.10.0-202206291026というバージョンは、Operatorの4.3.0からバージョンアップできることはわかります。
ですので、Local Storage Operator自体は4.8から4.10に一気に上げることができます。
[root@bastion-01 ~]# oc get csv -n openshift-local-storage
NAME                                         DISPLAY                            VERSION               REPLACES                                    PHASE
elasticsearch-operator.5.4.2                 OpenShift Elasticsearch Operator   5.4.2                                                             Succeeded
local-storage-operator.4.10.0-202206291026   Local Storage                      4.10.0-202206291026   local-storage-operator.4.8.0-202206281335   Succeeded
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-local-storage local-storage-operator.4.10.0-202206291026 -o json | jq -r .metadata.annotations | grep olm.skipRange
  "olm.skipRange": ">=4.3.0 <4.10.0-202206291026",
[root@bastion-01 ~]#
いずれにしてもこの範囲を確認するには、どこか別の環境で先にこのバージョンのOperatorを入れないとわからないので確認は難しいかもしれません。

Local Storage Operatorのアップデート

Local Storage OperatorのChannelを4.8から4.10に更新します。

アップデート前の確認

アップデート前の状態を確認します。

local-storage operatorのChannelは4.8になっています。

[root@bastion-01 ~]# oc get sub -n openshift-local-storage
NAME                     PACKAGE                  SOURCE             CHANNEL
local-storage-operator   local-storage-operator   redhat-operators   4.8
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-local-storage
NAME                                        DISPLAY                            VERSION              REPLACES   PHASE
elasticsearch-operator.5.4.2                OpenShift Elasticsearch Operator   5.4.2                           Succeeded
local-storage-operator.4.8.0-202206281335   Local Storage                      4.8.0-202206281335              Succeeded
[root@bastion-01 ~]#

更新承認ストラテジーは手動にしているので、より最新のinstallplanがあれば承認待ちになっているはずですが、ここではこのChannelの中で最新のバージョンになっていることがわかります。

[root@bastion-01 ~]# oc get installplan -n openshift-local-storage
NAME            CSV                                         APPROVAL    APPROVED
install-fq5qr   local-storage-operator.4.8.0-202206281335   Automatic   true
[root@bastion-01 ~]#

localvolumeリソース自体は3つ作成しており、infra-0[1-3]上でPVを作成するようにnodeSelectorを設定しています。

[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
NAME                           AGE
localvolume-alertmanagermain   17d
localvolume-elasticsearch      17d
localvolume-prometheusk8s      17d
[root@bastion-01 ~]#

それに従って、diskmaker-managerというDaemonsetのPodがinfra-0[1-3]に作成されています。
(4.6の頃は、localvolumeリソースのnodeSelectorでしたnode上に、localvolumeリソース毎にlocal-diskmakermとlocal-provisionerというペアのPodが作成され、ディスクのフォーマットとマウント/アンマウント処理を担っていました。
それが4.8ぐらいから？は、localvolume単位ではなく、複数のlocalvolumeのnodeSelectorで指定されたnode上には、1つのdiskmaker-managerというpodがあるだけで、これが複数のlocalvolumeリソースに紐づくPV用のディスクのフォーマットとマウント/アンマウント処理を一手に引き受けるようになったようです。)

[root@bastion-01 ~]# oc get pod -n openshift-local-storage -o wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
diskmaker-manager-2tjdb                   1/1     Running   3          17d   10.128.2.2   infra-02    <none>           <none>
diskmaker-manager-vd8tl                   1/1     Running   3          17d   10.129.2.3   infra-03    <none>           <none>
diskmaker-manager-xflxv                   1/1     Running   3          17d   10.130.2.5   infra-01    <none>           <none>
local-storage-operator-69864bc756-7t9gd   1/1     Running   0          16d   10.131.2.8   worker-01   <none>           <none>
[root@bastion-01 ~]#

OCP 4.10になってalertmanager-mainのPodはreplica数は2になりましたが、PVもPVCもまだ3つ残っています。

[root@bastion-01 ~]# oc get pv
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                                                           STORAGECLASS             REASON   AGE
image-registry-storage   100Gi      RWX            Retain           Bound       openshift-image-registry/image-registry-storage                 image-registry                    17d
local-pv-13e978f0        40Gi       RWO            Delete           Available                                                                   local-prometheusk8s               17d
local-pv-476b4e36        80Gi       RWO            Delete           Bound       openshift-logging/elasticsearch-elasticsearch-cdm-oqnqc785-1    local-elasticsearch               17d
local-pv-6a3a9d54        40Gi       RWO            Delete           Bound       openshift-monitoring/prometheus-k8s-db-prometheus-k8s-1         local-prometheusk8s               17d
local-pv-6cb91dfa        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-1   local-alertmanagermain            17d
local-pv-aec025c7        80Gi       RWO            Delete           Bound       openshift-logging/elasticsearch-elasticsearch-cdm-oqnqc785-2    local-elasticsearch               17d
local-pv-e646c476        40Gi       RWO            Delete           Bound       openshift-monitoring/prometheus-k8s-db-prometheus-k8s-0         local-prometheusk8s               17d
local-pv-e7a740c6        80Gi       RWO            Delete           Bound       openshift-logging/elasticsearch-elasticsearch-cdm-oqnqc785-3    local-elasticsearch               17d
local-pv-f209ee07        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-2   local-alertmanagermain            17d
local-pv-fc84cac         10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-0   local-alertmanagermain            17d
[root@bastion-01 ~]#

[root@bastion-01 ~]# oc get pvc -n openshift-monitoring
NAME                                       STATUS   VOLUME              CAPACITY   ACCESS MODES   STORAGECLASS             AGE
alertmanager-main-db-alertmanager-main-0   Bound    local-pv-fc84cac    10Gi       RWO            local-alertmanagermain   17d
alertmanager-main-db-alertmanager-main-1   Bound    local-pv-6cb91dfa   10Gi       RWO            local-alertmanagermain   17d
alertmanager-main-db-alertmanager-main-2   Bound    local-pv-f209ee07   10Gi       RWO            local-alertmanagermain   17d
prometheus-k8s-db-prometheus-k8s-0         Bound    local-pv-e646c476   40Gi       RWO            local-prometheusk8s      17d
prometheus-k8s-db-prometheus-k8s-1         Bound    local-pv-6a3a9d54   40Gi       RWO            local-prometheusk8s      17d
[root@bastion-01 ~]#

アップデート

CLIでSubscriptionリソースのChennelを更新しても良いのですが、ここではGUIでやりました。

OCPのGUIのメニューからOperator->インストール済みのOperatorを選択し、画面でopenshift-local-storageプロジェクトを選択し、表示されるLocal Storage Operatorのエントリーをクリックします。
サブスクリプションタブを選択します。

サブスクリプション画面で、更新チャネルの4.8のリンクをクリックします。

サブスクリプション更新チャネルの変更で4.10を選択し保存をクリックします。

更新チャネルが4.10になりました。
今回は「更新の承認」をManualにしているので、そのままではアップデートされません。アップグレードのステータスの横にある「1件に承認が必要」のリンクをクリックします。

該当InstallPlanの画面の「手動のInstallPlanの確認」欄の「InstallPlanのプレビュー」をクリックします。

アップデート対象のものを画面下部で確認し、承認をクリックします。

InstallPlanが適用され、アップデートが始まります。

しばらくするとLocal Storage Operatorのアップデートが完了しインストール済みのバージョンが先ほど承認したInstallPlanに表示されていたバージョンに変わっています。

アップデート後の確認

local-storage operatorのChannelは4.10になっています。
csvのVERSIONは、4.10.0-202206291026というバージョンになっています。

[root@bastion-01 ~]# oc get sub -n openshift-local-storage
NAME                     PACKAGE                  SOURCE             CHANNEL
local-storage-operator   local-storage-operator   redhat-operators   4.10
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-local-storage
NAME                                         DISPLAY                            VERSION               REPLACES                                    PHASE
elasticsearch-operator.5.4.2                 OpenShift Elasticsearch Operator   5.4.2                                                             Succeeded
local-storage-operator.4.10.0-202206291026   Local Storage                      4.10.0-202206291026   local-storage-operator.4.8.0-202206281335   Succeeded
[root@bastion-01 ~]#

4.10.0のInstallPlanのAPPROVED欄がtrueになっています。
アップデート直後なのであたりまですが4.10Channelのより新しいバージョンのInstallPlanはまだない状態です。

[root@bastion-01 ~]# oc get installplan -n openshift-local-storage
NAME            CSV                                          APPROVAL    APPROVED
install-fq5qr   local-storage-operator.4.8.0-202206281335    Automatic   true
install-zslmm   local-storage-operator.4.10.0-202206291026   Manual      true
[root@bastion-01 ~]#

localvolumeリソースはアップデート前のものがそのまま保持されています。

[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
NAME                           AGE
localvolume-alertmanagermain   17d
localvolume-elasticsearch      17d
localvolume-prometheusk8s      17d
[root@bastion-01 ~]#

alertmanager-main用のPVもPVCもアップデート前のものが保持されています。

[root@bastion-01 ~]# oc get pv | grep alertmanager-main
local-pv-6cb91dfa        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-1   local-alertmanagermain            17d
local-pv-f209ee07        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-2   local-alertmanagermain            17d
local-pv-fc84cac         10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-0   local-alertmanagermain            17d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pvc -n openshift-monitoring | grep alertmanager-main
alertmanager-main-db-alertmanager-main-0   Bound    local-pv-fc84cac    10Gi       RWO            local-alertmanagermain   17d
alertmanager-main-db-alertmanager-main-1   Bound    local-pv-6cb91dfa   10Gi       RWO            local-alertmanagermain   17d
alertmanager-main-db-alertmanager-main-2   Bound    local-pv-f209ee07   10Gi       RWO            local-alertmanagermain   17d
[root@bastion-01 ~]#

(2) alertmanagerのreplicasが3->2になるのでPVC/PVを一つ削除など

OCP 4.8から4.10にアップデートすると、モニタリングのコンポーネントのstatefulsetのreplica数は以下のように変更されます。

monitoring component	replica数 (OCP 4.8)	replica数 (OCP 4.10)
prometheus-k8s	2	2
alertmanager-main	3	2

[root@bastion-01 ~]# oc get statefulset -n openshift-monitoring
NAME                READY   AGE
alertmanager-main   2/2     34m
prometheus-k8s      2/2     34m
[root@bastion-01 ~]#

OCP 4.10になってalertmanager-mainのPodはreplica数は2になったので、必要に応じて、適宜alertmanager-mainの余ったPVを削除したりする必要があります。

今回の環境では、local-storage operatorで、3台のinfra nodeに仮想ディスクを追加し、alertmanager-main用のlocalvolumeリソースを作成してPVを作成していました。

alertmanager-mainのPodが稼働しなくなったため使用されなくなったPV/PVCを削除します。

alertmanager-mainのPodがどのnode上で稼働しているかを確認するとinfra-03からいなくなりました。

[root@bastion-01 ~]# oc get pod -n openshift-monitoring -o wide | grep prometheus-k8s
prometheus-k8s-0                               6/6     Running   0          16d    10.129.2.8      infra-03    <none>           <none>
prometheus-k8s-1                               6/6     Running   0          16d    10.130.2.8      infra-01    <none>           <none>
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-monitoring -o wide | grep alertmanager-main
alertmanager-main-0                            6/6     Running   0          16d    10.128.2.9      infra-02    <none>           <none>
alertmanager-main-1                            6/6     Running   0          16d    10.130.2.10     infra-01    <none>           <none>
[root@bastion-01 ~]#

但し、alertmanager-main用のPVもPVCもまだ3つ残っています。

[root@bastion-01 ~]# oc get pv | grep alertmanager-main
local-pv-6cb91dfa        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-1   local-alertmanagermain            17d
local-pv-f209ee07        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-2   local-alertmanagermain            17d
local-pv-fc84cac         10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-0   local-alertmanagermain            17d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pvc -n openshift-monitoring | grep alertmanager-main
alertmanager-main-db-alertmanager-main-0   Bound    local-pv-fc84cac    10Gi       RWO            local-alertmanagermain   17d
alertmanager-main-db-alertmanager-main-1   Bound    local-pv-6cb91dfa   10Gi       RWO            local-alertmanagermain   17d
alertmanager-main-db-alertmanager-main-2   Bound    local-pv-f209ee07   10Gi       RWO            local-alertmanagermain   17d
[root@bastion-01 ~]#

このPVは使われないだけなので、このまま残しておいても良いかと思います。
ただ、ちゃんと綺麗に使用していないものは削除しておきたい場合はlocalvolumeリソースを更新する必要があります。

今回は、alertmanager-mainのstatefulsetのreplica数が2になったことで、alertmanager-main-2というPodが削除されました。
この削除されたPodはinfra-03で稼働していたので、infra-03のPV/PVCを削除します。

まずalertmanager-main用の仮想ディスクはinfra nodeの/dev/sddをアサインしていたので、infra-03の/dev/sddの/dev/by-id/を調べます。

[root@bastion-01 ~]# ssh core@infra-03 -- sudo ls -l /dev/disk/by-id/ | grep scsi-36000 | grep sdd
lrwxrwxrwx. 1 root root  9 Jul 13 12:55 scsi-36000c29f96a0a5aa5dc5a6204d02874a -> ../../sdd
[root@bastion-01 ~]#

alertmanager-main用のlocalvolumeのマニフェストファイルを修正します。

[root@bastion-01 ~]# cd work/manifest/localvolume/
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l localvolume-alertmanagermain.yaml
-rw-r--r--. 1 root root 696  5月 17 17:08 localvolume-alertmanagermain.yaml
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# cp -p localvolume-alertmanagermain.yaml localvolume-alertmanagermain.yaml.bak.20220809
[root@bastion-01 localvolume]# vi localvolume-alertmanagermain.yaml
[root@bastion-01 localvolume]#

修正前

localvolume-alertmanagermain.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "localvolume-alertmanagermain"
  namespace: "openshift-local-storage"
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - infra-01
          - infra-02
          - infra-03
  storageClassDevices:
    - storageClassName: "local-alertmanagermain"
      volumeMode: Filesystem
      fsType: xfs
      devicePaths:
        - /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
        - /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887
        - /dev/disk/by-id/scsi-36000c29f96a0a5aa5dc5a6204d02874a

修正後

spec.nodeSelectorから、infra-03を削除する
spec.nodeSelectorから、infra-03の/dev/sddの/dev/disk/by-id/のエントリーを削除する。

localvolume-alertmanagermain.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "localvolume-alertmanagermain"
  namespace: "openshift-local-storage"
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - infra-01
          - infra-02
  storageClassDevices:
    - storageClassName: "local-alertmanagermain"
      volumeMode: Filesystem
      fsType: xfs
      devicePaths:
        - /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
        - /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887

修正したalertmanager-main用のlocalvolumeのマニフェストを適用します。

[root@bastion-01 localvolume]# oc apply -f localvolume-alertmanagermain.yaml
localvolume.local.storage.openshift.io/localvolume-alertmanagermain configured
[root@bastion-01 localvolume]#

infra-03のエントリーが消えたことが確認できます。

[root@bastion-01 localvolume]# oc get localvolume -n openshift-local-storage localvolume-alertmanagermain -o yaml
apiVersion: local.storage.openshift.io/v1
kind: LocalVolume
metadata:
  annotations:
    (略)
  creationTimestamp: "2022-07-12T14:47:59Z"
  finalizers:
  - storage.openshift.com/local-volume-protection
  generation: 3
  name: localvolume-alertmanagermain
  namespace: openshift-local-storage
  resourceVersion: "18376454"
  uid: 3d357158-8520-4624-aa55-d717f9eec7b9
spec:
  logLevel: Normal
  managementState: Managed
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
      - key: kubernetes.io/hostname
        operator: In
        values:
        - infra-01
        - infra-02
  storageClassDevices:
  - devicePaths:
    - /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
    - /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887
    fsType: xfs
    storageClassName: local-alertmanagermain
    volumeMode: Filesystem
status:
  conditions:
  - lastTransitionTime: "2022-07-12T14:47:59Z"
    message: Ready
    status: "True"
    type: Available
  generations:
  - group: apps
    lastGeneration: 5
    name: diskmaker-manager
    namespace: openshift-local-storage
    resource: DaemonSet
  managementState: Managed
  observedGeneration: 3
  readyReplicas: 0
[root@bastion-01 localvolume]#

但し、これだけではPV/PVCは削除されていないので、手動で削除する必要があります。

[root@bastion-01 localvolume]# oc get pv | grep alertmanager-main
local-pv-6cb91dfa        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-1   local-alertmanagermain            27d
local-pv-f209ee07        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-2   local-alertmanagermain            27d
local-pv-fc84cac         10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-0   local-alertmanagermain            27d
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get pvc -n openshift-monitoring | grep alertmanager-main
alertmanager-main-db-alertmanager-main-0   Bound    local-pv-fc84cac    10Gi       RWO            local-alertmanagermain   27d
alertmanager-main-db-alertmanager-main-1   Bound    local-pv-6cb91dfa   10Gi       RWO            local-alertmanagermain   27d
alertmanager-main-db-alertmanager-main-2   Bound    local-pv-f209ee07   10Gi       RWO            local-alertmanagermain   27d
[root@bastion-01 localvolume]#

今回は削除されたalertmanager-main-2のPodで使われていたPV、PVCを削除します。

[root@bastion-01 localvolume]# oc delete pvc -n openshift-monitoring alertmanager-main-db-alertmanager-main-2
persistentvolumeclaim "alertmanager-main-db-alertmanager-main-2" deleted
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc delete pv local-pv-f209ee07
persistentvolume "local-pv-f209ee07" deleted
[root@bastion-01 localvolume]#

alertmanager-mainのreplica数が2になり、使われなくなったPVとPVCが削除されたことを確認します。

[root@bastion-01 localvolume]# oc get pv | grep alertmanager-main
local-pv-6cb91dfa        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-1   local-alertmanagermain            27d
local-pv-fc84cac         10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-0   local-alertmanagermain            27d
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get pvc -n openshift-monitoring | grep alertmanager-main
alertmanager-main-db-alertmanager-main-0   Bound    local-pv-fc84cac    10Gi       RWO            local-alertmanagermain   27d
alertmanager-main-db-alertmanager-main-1   Bound    local-pv-6cb91dfa   10Gi       RWO            local-alertmanagermain   27d
[root@bastion-01 localvolume]#

Podも正常に稼働したままです。

[root@bastion-01 localvolume]# oc get statefulset -n openshift-monitoring
NAME                READY   AGE
alertmanager-main   2/2     27d
prometheus-k8s      2/2     27d
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get pod -n openshift-monitoring | grep alertmanager-main
alertmanager-main-0                            6/6     Running   0          27d
alertmanager-main-1                            6/6     Running   0          27d
[root@bastion-01 localvolume]#

(3) その他個別に導入していたものも対応

Operatorやその他のアプリケーションは、OCPとの互換性によっては、OCPを4.10にアップデートする前にアップデートをしておく必要がある場合もあるため、ご使用のコンポーネントのドキュメントなどを事前に十分確認し、アップデートの順番は適宜判断してください。

例えば、Local Storage Operatorは、Red Hat OpenShift Container Platform のライフサイクルポリシーにはOCPとの互換性は記載されていません。
実際にOCP 4.6 + Local Storage Operator (stable-4.6)、からOCPを4.7->4.8->4.9に上げようとすると、OCP 4.9に上げるタイミングでLocal Storage Operator (stable-4.6)と互換性がないのでOCP 4.9には上げられないとのメッセージが表示されるため、OCP 4.8の時点でLocal Storage Operatorもstable-4.8にアップデートし、その後EUS間アップデートでOCP 4.10にした後に、最後にLocal Storage Operatorをstable-4.10にする必要などがあります。

また、OperatorのAPIの互換性や、Operatorのインスタンスのspecのスキーマなどが変わったりして、一旦アンインストールして、OCPアップデート後にOperatorを再インストールした方が早いものもあるかもしれません。
この辺りは、事前にドキュメントで互換性の確認をするだけではなく、バージョンアップ検証用の環境を準備して実機で確認できるようにしておいた方が良いとおもます。
いずれにしても、基本的にはあまり幾つかのバージョンを一気にアップデートするよりは、適宜OCPをアップデートできるように運用を計画しておく方が良いかなとは思います。