概要
OpenShift Container Platform (OCP) 4.11からOCP 4.12にアップデートした際のメモを残しておきます。
今回はstable-4.11チャネルのOCP 4.11.16から、fast-4.12チャネルのOCP 4.12.3にアップデートしました。
(検証時点ではstable-4.12やeus-4.12 Channelは出てこなかったので、fast-4.12 Channelでやっていますが、実環境ではstableやeusのアップデートパスが出るまでアップデートはしない方が良いと思います。)
参考リンク
全般
4.12に上げるための準備(削除されたAPI対応)
- OCP 4.12 Docs / クラスターの更新 / 5. OpenShift Container Platform 4.12 への更新の準備
- KB / Preparing to upgrade to OpenShift Container Platform 4.12
- KB / Navigating Kubernetes API deprecations and removals
アップデートパスの確認
- 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
検証構成
OCP構成
「Qiita / ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた」で作成した環境を使用しています。
node構成
MCPはinfra node用のMCPも作成しています。
[root@bastion-01 ~]# oc get mcp
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
infra rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88 True False False 6 6 6 0 219d
master rendered-master-60815c158d00703013c8ffa0f9090be0 True False False 3 3 3 0 219d
worker rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88 True False False 2 2 2 0 219d
[root@bastion-01 ~]#
master node x3、infra node x3、infra node (ODF用) x3、worker node x2の構成です。
[root@bastion-01 ~]# oc get node
NAME STATUS ROLES AGE VERSION
infra-01 Ready infra 219d v1.24.6+5157800
infra-02 Ready infra 219d v1.24.6+5157800
infra-03 Ready infra 219d v1.24.6+5157800
master-01 Ready master 219d v1.24.6+5157800
master-02 Ready master 219d v1.24.6+5157800
master-03 Ready master 219d v1.24.6+5157800
storage-01 Ready infra 73d v1.24.6+5157800
storage-02 Ready infra 73d v1.24.6+5157800
storage-03 Ready infra 73d v1.24.6+5157800
worker-01 Ready worker 219d v1.24.6+5157800
worker-02 Ready worker 219d v1.24.6+5157800
[root@bastion-01 ~]#
OCPバージョン
現在のバージョンはstable-4.11チャネルのOCP 4.11.16です。
[root@bastion-01 ~]# oc version
Client Version: 4.11.16
Kustomize Version: v4.5.4
Server Version: 4.11.16
Kubernetes Version: v1.24.6+5157800
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.11.16 True False 73d Cluster version is 4.11.16
[root@bastion-01 ~]#
Operator
導入しているOperatorは以下になります。
| Operator | Channel | 更新承認ストラテジー | CSV | 備考 |
|---|---|---|---|---|
| Local Storage | stable |
Manual | local-storage-operator.4.11.0-202211072116 |
|
| OpenShift Data Foundation | stable-4.11 |
Manual | odf-operator.v4.11.4 |
| Operator | Channel | 更新承認ストラテジー | CSV | 備考 |
|---|---|---|---|---|
| Red Hat OpenShift Logging | stable-5.5 |
Manual | cluster-logging.5.5.5 |
以前はCluster Logging Operatorという名称だったが変更されたもの |
| Loki Operator | stable-5.5 |
Manual | loki-operator.5.5.5 |
こちらもOCP 4.12 アップデート後にOCP 4.12に対応している最新のチャネルのものにアップデートします。
手順の流れ
ベアメタルUPIのOCPでOCP 4.11.16からOCP 4.12.3にアップデートする流れは以下のようになります。
アップデートパスの確認
- (0)アップデートパスの確認
OCP本体
- (1) 4.11 -> 4.12に上げるための準備(削除されたAPI対応) (一部Operatorのアップデート)
- (2) チャネルを
stable-4.12に変更し4.12.3にアップデート (今回はfast-4.12) - (3) バージョンが4.12.3になる
- (4) CLI(oc)のアップデート
Operator
- (1) 適宜必要なものをアップデート
- (2) その他個別に導入していたものも対応
- ((*) Operatorやその他アプリは、OCPとの互換性によっては、OCPを4.12に上げる前にアップデートしておく必要があるものがある場合もありますので適宜判断ください。)
実際の手順
アップデートパスの確認
(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」をstable-4.11を選択し、「Current OpenShift Version」に4.11.16を選択すると、「Target OpenShift Version」のプルダウンからはOCP 4.12の全てのバージョンが (no update path available) と表示されていました。
fast-4.11とした場合は、アップデートパスとして4.12.2が選択できました。
ここで「Generate」をクリックすると、fast-4.12 Channelでは、「4.11.16 -> 4.12.2」の順番のアップデートパスがあることがわかります。
今回はあくまでも検証環境なのでstableチャネルではなくfastチャネルでアップデートしてみます。
(そもそも検証した日は、まだこの画面ではstable-4.12やeus-4.12 Channelが表示されていなかったというのもあります。)
!
OCP本体
(1) 4.11 -> 4.12に上げるための準備(削除されたAPI対応) (一部Operatorのアップデート)
OCPのGUIの管理->クラスター設定画面上部にもメッセージが出ているように、まず初めに、以下の手順に従ってOCP 4.12に上げるための準備(削除されたAPI対応)を実施する必要があります。
OCP 4.12に上げるための削除されたAPI対応は以下のリンクを見て実施します。
OCP 4.12 Docs / クラスターの更新 / 5. OpenShift Container Platform 4.12 への更新の準備
KB / Preparing to upgrade to OpenShift Container Platform 4.12
KB / Navigating Kubernetes API deprecations and removals
削除される予定のAPIが使用されているかの確認
cluster-adminロールを持つユーザーとしてクラスターにログインします。
APIRequestCountを使用し、削除されるAPIを使用しているかを特定します。
以下のコマンドを実行すると、REMOVEDINRELEASE列で、現在使用中の削除されるAPIを確認することができます。
oc get apirequestcounts
(出力例)
[root@bastion-01 ~]# oc get apirequestcounts
NAME REMOVEDINRELEASE REQUESTSINCURRENTHOUR REQUESTSINLAST24H
# REMOVEDINRELEASEに値がある行以外を削除して記載
cronjobs.v1beta1.batch 1.25 0 8
flowschemas.v1beta1.flowcontrol.apiserver.k8s.io 1.26 23 3487
horizontalpodautoscalers.v2beta1.autoscaling 1.25 0 0
horizontalpodautoscalers.v2beta2.autoscaling 1.26 1 175
ingresses.v1beta1.extensions 1.22 0 0
poddisruptionbudgets.v1beta1.policy 1.25 0 0
podsecuritypolicies.v1beta1.policy 1.25 2 178
prioritylevelconfigurations.v1beta1.flowcontrol.apiserver.k8s.io 1.26 3 318
以下のように-o jsonフィルターをして確認すると使用されているAPIだけを抽出して表示することができます。
oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.status.requestCount}{"\t"}{.metadata.name}{"\n"}{end}'
(出力例)
[root@bastion-01 ~]# oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.status.requestCount}{"\t"}{.metadata.name}{"\n"}{end}'
1.25 8 cronjobs.v1beta1.batch
1.26 3498 flowschemas.v1beta1.flowcontrol.apiserver.k8s.io
1.25 0 horizontalpodautoscalers.v2beta1.autoscaling
1.26 176 horizontalpodautoscalers.v2beta2.autoscaling
1.22 0 ingresses.v1beta1.extensions
1.25 0 poddisruptionbudgets.v1beta1.policy
1.25 179 podsecuritypolicies.v1beta1.policy
1.26 319 prioritylevelconfigurations.v1beta1.flowcontrol.apiserver.k8s.io
[root@bastion-01 ~]#
洗い出されたAPIをどのワークロードが使用しているかを特定します。
-o jsonpathを使用して、APIRequestCountリソースからusernameおよびuserAgentの値を抽出することができます、
(今回は、OCP 4.12のドキュメントの.status.currentHourではなく、KBの方にあった24時間以下に使用されたものを表示する.status.last24hの方でフィルターして確認しました。)
oc get apirequestcounts ingresses.v1beta1.networking.k8s.io \
-o jsonpath='{range .status.last24h..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
| sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT
こちらを、KBのComment欄にあったfor文で実行して、一覧を表示しました。
[root@bastion-01 ~]# for i in $(oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.metadata.name}{"\n"}{end}'); do
> oc get apirequestcounts $i -o jsonpath='{range .status.last24h..byUser[*]}{..byVerb[*].verb}{","}{"'$i',"}{.username}{","}{.userAgent}{"\n"}{end}' \
> | sort -k 2 -t, -u
> done | column -t -s, -NVERBS,API,USERNAME,USERAGENT
VERBS API USERNAME USERAGENT
delete cronjobs.v1beta1.batch system:serviceaccount:openshift-storage:rook-ceph-system rook/v0.0.0
get flowschemas.v1beta1.flowcontrol.apiserver.k8s.io system:serviceaccount:openshift-cluster-version:default cluster-version-operator/v0.0.0
watch horizontalpodautoscalers.v2beta2.autoscaling system:serviceaccount:openshift-monitoring:kube-state-metrics v2.5.0
watch podsecuritypolicies.v1beta1.policy system:kube-controller-manager kube-controller-manager/v1.24.6+5157800
get prioritylevelconfigurations.v1beta1.flowcontrol.apiserver.k8s.io system:serviceaccount:openshift-cluster-version:default cluster-version-operator/v0.0.0
[root@bastion-01 ~]#
上述のコマンド出力から、今回は以下の対応をしました。
(1) ドキュメントに記載のある以下のエントリーは無視しても良いとのことなので、今回は無視します。
podsecuritypolicies.v1beta1.policy
(ドキュメント抜粋)
重要
結果に表示される以下のエントリーは無視しても問題はありません。system:serviceaccount:kube-system:generic-garbage-collector および system:serviceaccount:kube-system:namespace-controller ユーザーは、削除するリソースの検索時に登録されたすべての API を呼び出すので、結果に表示される可能性があります。
system:kube-controller-manager および system:cluster-policy-controller ユーザーは、さまざまなポリシーを適用しながらすべてのリソースをウォークスルーするため、結果に表示される場合があります。
(2) 以下のAPIは、前述の確認コマンドの出力から1.25ではなく1.26で削除予定のため、一旦今回は無視しました。
flowschemas.v1beta1.flowcontrol.apiserver.k8s.iohorizontalpodautoscalers.v2beta2.autoscalingprioritylevelconfigurations.v1beta1.flowcontrol.apiserver.k8s.io
(3) 残ったのはcronjobs.v1beta1.batchです。
これはopenshift-storage namespaceに導入している、「OpenShift Data Foudation」のrookが使用していると思われます。
現在の状況は、OCP 4.11に、ODF 4.11を導入しています。
OCPとODFの互換性を確認すると、ODF 4.12は、OCP 4.12でしかサポートされていませんでしたので、ODFを先に4.12に上げることはできないと思われます。
Red Hat OpenShift Container Platform Life Cycle Policy / Red Hat OpenShift Data Foundation
KB / Red Hat OpenShift Data Foundation(previously known as OpenShift Container Storage) Supportability and Interoperability Guide
一方でODF 4.11は、OCP4.12でもサポートされます。
(バージョン互換性とAPI互換性が矛盾している気もしますが)、今回は影響があるのは、rookのcronjobだけなので、とりあえずこの時点ではcronjobのAPIの対応は何もせず、一旦OCPを4.12にアップデートしてからODFも追いつきですぐに4.12にアップデートをするという対応をすることにしました。
以上から、これで一旦影響のあるAPIの確認が終わったということで、確認終了の処理をします。
管理者の確認
削除される予定のAPIを使用しているかを確認して全ての移行の対応が完了したら、管理者は明示的に確認をしたという処理をする必要があります。
以下のコマンドを実行して、評価を完了し、OCP 4.12にアップデートできることを確認したフラグを立てます。
(admin-acksというconfigmapに"ack-4.11-kube-1.25-api-removals-in-4.12":"true"}というフラグをつける)
oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.11-kube-1.25-api-removals-in-4.12":"true"}}' --type=merge
実施前
[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: "17694913"
uid: e1f88089-0a23-40dc-8daf-36704714ec71
[root@bastion-01 ~]#
フラグを立てる
[root@bastion-01 ~]# oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.11-kube-1.25-api-removals-in-4.12":"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"
ack-4.11-kube-1.25-api-removals-in-4.12: "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: "270106618"
uid: e1f88089-0a23-40dc-8daf-36704714ec71
[root@bastion-01 ~]#
こうすることで、OCPのGUIから先ほどのメッセージが表示されなくなり、OCP 4.12にアップデートすることができるようことが出来るようになりました。
(参考)クラスター設定画面上部に表示されていたメッセージも消える。
(2) チャネルをstable-4.12に変更し4.12.3にアップデート (今回はfast-4.12)
今回はCLIではなくOCPのGUIからアップデートをしました。
また、(0)アップデートパスの確認でも記載したように、まだstable-4.12 Channelがないので、fast-4.12を選択し、「4.11.16 -> 4.12.3」にアップデートします。
アップデート前の状態
[root@bastion-01 ~]# oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.11.16 True False 75d Cluster version is 4.11.16
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node
NAME STATUS ROLES AGE VERSION
infra-01 Ready infra 221d v1.24.6+5157800
infra-02 Ready infra 221d v1.24.6+5157800
infra-03 Ready infra 221d v1.24.6+5157800
master-01 Ready master 221d v1.24.6+5157800
master-02 Ready master 221d v1.24.6+5157800
master-03 Ready master 221d v1.24.6+5157800
storage-01 Ready infra 75d v1.24.6+5157800
storage-02 Ready infra 75d v1.24.6+5157800
storage-03 Ready infra 75d v1.24.6+5157800
worker-01 Ready worker 221d v1.24.6+5157800
worker-02 Ready worker 221d v1.24.6+5157800
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
infra rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88 True False False 6 6 6 0 221d
master rendered-master-60815c158d00703013c8ffa0f9090be0 True False False 3 3 3 0 221d
worker rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88 True False False 2 2 2 0 221d
[root@bastion-01 ~]#
fast-4.12に変更し、アップデートパスがある4.12.3を選択します。
(「(0)アップデートパスの確認」で確認した時はTargetのバージョンは4.12.2しか選択できなかったですが、この操作の実施時には、4.12.3が選択できるようになっていたので、今回は4.12.3を選択しました。)
OCPのGUIのメニューから管理 -> クラスター設定を開き、チャネルのstable-4.11のリンクをクリックします。
表示されるチャネルの選択画面でfast-4.12に変更します。
チャネルがfast-4.12に更新され、アップデートできるバージョンが表示されますので「バージョンの更新」をクリックします。
「新規バージョンの選択」のプルダウンメニューでは、推奨とサポート対象(ただし非推奨)のバージョンが選べます。
今回は推奨の中で最新の4.12.3を選択します。
また、master nodeもworker/infra nodeも一緒にアップデートするので「クラスターの完全な更新」を選択して、「更新」をクリックします。
4.12.3へのアップデートが始まります。
[root@bastion-01 ~]# oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.11.16 True True 3m35s Working towards 4.12.3: 104 of 829 done (12% complete), waiting on etcd, kube-apiserver
[root@bastion-01 ~]#
まずはCluster Operatorのアップデートが始まります。
Cluster Operatorのアップデートが大体終わると、新しいMCPのMCを適用するために、master nodeと、worker node、infra nodeの再起動が始まります。
[root@bastion-01 ~]# oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.11.16 True True 54m Working towards 4.12.3: 374 of 829 done (45% complete)
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
infra rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88 False True False 6 1 1 0 221d
master rendered-master-60815c158d00703013c8ffa0f9090be0 False True False 3 1 1 0 221d
worker rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88 False True False 2 1 1 0 221d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node
NAME STATUS ROLES AGE VERSION
infra-01 Ready infra 221d v1.24.6+5157800
infra-02 Ready,SchedulingDisabled infra 221d v1.24.6+5157800
infra-03 Ready infra 221d v1.25.4+a34b9e9
master-01 Ready master 221d v1.25.4+a34b9e9
master-02 Ready,SchedulingDisabled master 221d v1.24.6+5157800
master-03 Ready master 221d v1.24.6+5157800
storage-01 Ready infra 75d v1.24.6+5157800
storage-02 Ready infra 75d v1.24.6+5157800
storage-03 Ready infra 75d v1.24.6+5157800
worker-01 Ready,SchedulingDisabled worker 221d v1.25.4+a34b9e9
worker-02 Ready worker 221d v1.25.4+a34b9e9
[root@bastion-01 ~]#
(3) バージョンが4.12.3になる
master、infra、worker nodeの再起動が完了し、OCP 4.12.3へのアップデートが完了したことを確認します。
CLIでも正常にアップデートしたことを確認します。
clusterversionのVERSIONは4.12.3です。
[root@bastion-01 ~]# oc get clusterversion
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.12.3 True False 13m Cluster version is 4.12.3
[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-74f981727fab0316702889103c90d475 True False False 6 6 6 0 221d
master rendered-master-66bd7c1e50b9cd63ddc138121fdd26ca True False False 3 3 3 0 221d
worker rendered-worker-74f981727fab0316702889103c90d475 True False False 2 2 2 0 221d
[root@bastion-01 ~]#
nodeは全てSTATUSがREADYになり、kubernetesのバージョンもv1.25になっています。
[root@bastion-01 ~]# oc get node
NAME STATUS ROLES AGE VERSION
infra-01 Ready infra 221d v1.25.4+a34b9e9
infra-02 Ready infra 221d v1.25.4+a34b9e9
infra-03 Ready infra 221d v1.25.4+a34b9e9
master-01 Ready master 221d v1.25.4+a34b9e9
master-02 Ready master 221d v1.25.4+a34b9e9
master-03 Ready master 221d v1.25.4+a34b9e9
storage-01 Ready infra 75d v1.25.4+a34b9e9
storage-02 Ready infra 75d v1.25.4+a34b9e9
storage-03 Ready infra 75d v1.25.4+a34b9e9
worker-01 Ready worker 221d v1.25.4+a34b9e9
worker-02 Ready worker 221d v1.25.4+a34b9e9
[root@bastion-01 ~]#
clusteroperatorのVERSIONも全て4.12.3になっています。
[root@bastion-01 ~]# oc get co
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
authentication 4.12.3 True False False 6m39s
baremetal 4.12.3 True False False 221d
cloud-controller-manager 4.12.3 True False False 220d
cloud-credential 4.12.3 True False False 221d
cluster-autoscaler 4.12.3 True False False 221d
config-operator 4.12.3 True False False 221d
console 4.12.3 True False False 8d
control-plane-machine-set 4.12.3 True False False 62m
csi-snapshot-controller 4.12.3 True False False 220d
dns 4.12.3 True False False 115d
etcd 4.12.3 True False False 96d
image-registry 4.12.3 True False False 25m
ingress 4.12.3 True False False 8d
insights 4.12.3 True False False 221d
kube-apiserver 4.12.3 True False False 221d
kube-controller-manager 4.12.3 True False False 221d
kube-scheduler 4.12.3 True False False 221d
kube-storage-version-migrator 4.12.3 True False False 35m
machine-api 4.12.3 True False False 221d
machine-approver 4.12.3 True False False 221d
machine-config 4.12.3 True False False 62d
marketplace 4.12.3 True False False 221d
monitoring 4.12.3 True False False 62d
network 4.12.3 True False False 221d
node-tuning 4.12.3 True False False 58m
openshift-apiserver 4.12.3 True False False 8d
openshift-controller-manager 4.12.3 True False False 58m
openshift-samples 4.12.3 True False False 61m
operator-lifecycle-manager 4.12.3 True False False 221d
operator-lifecycle-manager-catalog 4.12.3 True False False 221d
operator-lifecycle-manager-packageserver 4.12.3 True False False 41m
service-ca 4.12.3 True False False 221d
storage 4.12.3 True False False 221d
[root@bastion-01 ~]#
RHCOSのバージョンもmaster、infra、worker nodeとも全て4.12になっています。
[root@bastion-01 ~]# ssh core@master-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.12
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.12
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@storage-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.12
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@worker-01 -- cat /etc/redhat-release
Red Hat Enterprise Linux CoreOS release 4.12
[root@bastion-01 ~]#
(4) CLI(oc)のアップデート
CLI(oc)も4.12.3のものにアップデートします。
[root@bastion-01 4.12.3]# curl -s -O https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.12.3/openshift-client-linux-4.12.3.tar.gz
[root@bastion-01 4.12.3]# curl -s -O https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.12.3/release.txt
[root@bastion-01 4.12.3]# curl -s -O https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.12.3/sha256sum.txt
[root@bastion-01 4.12.3]#
[root@bastion-01 4.12.3]# ls -l
合計 53908
-rw-r--r--. 1 root root 55162055 2月 18 21:09 openshift-client-linux-4.12.3.tar.gz
-rw-r--r--. 1 root root 31959 2月 18 21:09 release.txt
-rw-r--r--. 1 root root 1277 2月 18 21:09 sha256sum.txt
[root@bastion-01 4.12.3]#
[root@bastion-01 4.12.3]# sha256sum openshift-client-linux-4.12.3.tar.gz
41eb5f7557017396e8dae48352c64a840eed46fc552a2888d44534bdbeb1f561 openshift-client-linux-4.12.3.tar.gz
[root@bastion-01 4.12.3]# grep openshift-client-linux-4.12.3.tar.gz sha256sum.txt
41eb5f7557017396e8dae48352c64a840eed46fc552a2888d44534bdbeb1f561 openshift-client-linux-4.12.3.tar.gz
[root@bastion-01 4.12.3]#
[root@bastion-01 4.12.3]# tar zxf openshift-client-linux-4.12.3.tar.gz
[root@bastion-01 4.12.3]#
[root@bastion-01 4.12.3]# mv oc kubectl /usr/local/bin/
mv: '/usr/local/bin/oc' を上書きしますか? y
mv: '/usr/local/bin/kubectl' を上書きしますか? y
[root@bastion-01 4.12.3]#
[root@bastion-01 4.12.3]# oc version
Client Version: 4.12.3
Kustomize Version: v4.5.7
Server Version: 4.12.3
Kubernetes Version: v1.25.4+a34b9e9
[root@bastion-01 4.12.3]#
タブ補完
[root@bastion-01 4.12.3]# oc completion bash > oc_bash_completion
[root@bastion-01 4.12.3]# mv oc_bash_completion /etc/bash_completion.d/
mv: '/etc/bash_completion.d/oc_bash_completion' を上書きしますか? y
[root@bastion-01 4.12.3]#
Operator
(1) 適宜必要なものをアップデート
アップデートが必要なOperatorがあればアップデートします。
アップデート対象のOperator (ストレージ関連)
導入しているOperatorは以下になります。
| Operator | Channel | 更新承認ストラテジー | CSV | 備考 |
|---|---|---|---|---|
| Local Storage | stable |
Manual | local-storage-operator.4.11.0-202211072116 |
|
| OpenShift Data Foundation | stable-4.11 |
Manual | odf-operator.v4.11.4 |
Local Storage Operatorに関しては、Red Hat OpenShift Container Platform のライフサイクルポリシーにはOCPとの互換性の記述の記載はありません。
ですが、一旦Local Storage Operatorは4.11のまま、OCP自体は4.12にアップデートはできたので、併せてここでLocal Storage Operatorも4.12にしておきます。
OpenShift Data Foundationは、OCP 4.12で、ODF 4.11、4.12をサポートしているので、4.12にアップデートします。
特にcronjobを使用していたODFは、APIが削除されているのでバージョンアップしておく必要があります。
アップデート対象のOperator (ロギング関連)
次にLogging関連のOperatorもアップデートします。
現在導入していたバージョンは以下です。
| Operator | Channel | 更新承認ストラテジー | CSV | 備考 |
|---|---|---|---|---|
| Red Hat OpenShift Logging | stable-5.5 |
Manual | cluster-logging.5.5.5 |
以前はCluster Logging Operatorという名称だったが変更されたもの |
| Loki Operator | stable-5.5 |
Manual | loki-operator.5.5.5 |
Loggingは、「Red Hat OpenShift Container Platform のライフサイクルポリシー」を見ると、5.5は、OCP 4.11、4.12でもサポートされており、5.6はOCP 4.12でサポートされているので、ここで、Red Hat OpenShift Loggingと、Loki Operatorも、5.6にアップデートします。
(補足)
OCP 4.12.3にアップグレードしたところ、画面上部にCluster Logging Operatorと、Loki Operator、(あとは使用していないけど消していなかったElasticsearch Operator)の5.5.5が、OCP 4.12と互換性がないとの記載があります。
ですので、これらを5.5.6にアップデートします。
(というか、ライフサイクルポリシーで確認したときはOCP 4.12で Logging 5.5のサポートがある、、との記載がある気がするのだけれど、、、)
Local Storage Operatorのアップデート
Local Storage OperatorのChannelを4.11から4.12に更新します。
アップデート前の確認
アップデート前の状態を確認します。
local-storage operatorのChannelはstableになっており、CSVのバージョンは4.11.0-202211072116となっています。
[root@bastion-01 ~]# oc get sub -n openshift-local-storage
NAME PACKAGE SOURCE CHANNEL
local-storage-operator local-storage-operator redhat-operators stable
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-local-storage
NAME DISPLAY VERSION REPLACES PHASE
elasticsearch-operator.5.5.5 OpenShift Elasticsearch Operator 5.5.5 elasticsearch-operator.5.4.9 Succeeded
local-storage-operator.4.11.0-202211072116 Local Storage 4.11.0-202211072116 local-storage-operator.4.10.0-202207192148 Succeeded
loki-operator.5.5.5 Loki Operator 5.5.5 Succeeded
[root@bastion-01 ~]#
更新承認ストラテジーは手動にしているので、より最新のinstallplanがあれば承認待ちになっています。
[root@bastion-01 ~]# oc get installplan -n openshift-local-storage
NAME CSV APPROVAL APPROVED
install-8979p local-storage-operator.4.11.0-202212070335 Manual false
install-f2rfw local-storage-operator.4.11.0-202211072116 Manual true
install-fq5qr local-storage-operator.4.8.0-202206281335 Automatic true
install-zdsfg local-storage-operator.4.10.0-202207192148 Manual true
install-zslmm local-storage-operator.4.10.0-202206291026 Manual true
[root@bastion-01 ~]#
アップデート前の状況です。
この時点ではモニタリング用のPVは、ODFに移行しておらず、Local Storage Operatorのみで作成していたので、Localvolumeリソースがあります。
ODF用には、storage nodeの追加ディスクで、ODFがlocalvolumesetを作成しているので、それに関する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-discovery-2t98b 2/2 Running 22 74d 10.131.0.6 worker-02 <none> <none>
diskmaker-discovery-8hwtb 2/2 Running 22 74d 10.131.2.3 worker-01 <none> <none>
diskmaker-discovery-bclhw 2/2 Running 22 74d 10.128.4.5 storage-01 <none> <none>
diskmaker-discovery-cv27d 2/2 Running 12 64d 10.128.2.4 infra-02 <none> <none>
diskmaker-discovery-f7whm 2/2 Running 16 64d 10.130.2.2 infra-01 <none> <none>
diskmaker-discovery-jqc5h 2/2 Running 22 67d 10.129.2.3 infra-03 <none> <none>
diskmaker-discovery-m4nvp 2/2 Running 24 74d 10.129.4.5 storage-02 <none> <none>
diskmaker-discovery-wdkv5 2/2 Running 22 74d 10.130.4.3 storage-03 <none> <none>
diskmaker-manager-2v4zh 2/2 Running 4 44d 10.130.4.4 storage-03 <none> <none>
diskmaker-manager-8q8q7 2/2 Running 4 44d 10.129.4.2 storage-02 <none> <none>
diskmaker-manager-bqfhw 2/2 Running 4 44d 10.130.2.6 infra-01 <none> <none>
diskmaker-manager-fdh9f 2/2 Running 4 44d 10.128.2.3 infra-02 <none> <none>
diskmaker-manager-gjvhf 2/2 Running 4 44d 10.129.2.5 infra-03 <none> <none>
diskmaker-manager-tf7zw 2/2 Running 4 44d 10.128.4.3 storage-01 <none> <none>
local-storage-operator-98d79687d-czvvm 1/1 Running 0 34m 10.130.2.14 infra-01 <none> <none>
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
NAME AGE
localvolume-alertmanagermain 220d
localvolume-prometheusk8s 220d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get localvolumesets -n openshift-local-storage
NAME STORAGECLASS PROVISIONED AGE
localblock localblock 3 44d
[root@bastion-01 ~]#
[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 221d
local-pv-13e978f0 40Gi RWO Delete Available local-prometheusk8s 220d
local-pv-6a3a9d54 40Gi RWO Delete Bound openshift-monitoring/prometheus-k8s-db-prometheus-k8s-1 local-prometheusk8s 220d
local-pv-6b3c4558 1Ti RWO Delete Bound openshift-storage/ocs-deviceset-localblock-0-data-022zww localblock 44d
local-pv-6cb91dfa 10Gi RWO Delete Bound openshift-monitoring/alertmanager-main-db-alertmanager-main-1 local-alertmanagermain 220d
local-pv-d94c27a1 1Ti RWO Delete Bound openshift-storage/ocs-deviceset-localblock-0-data-1mpknn localblock 44d
local-pv-e646c476 40Gi RWO Delete Bound openshift-monitoring/prometheus-k8s-db-prometheus-k8s-0 local-prometheusk8s 220d
local-pv-faa39169 1Ti RWO Delete Bound openshift-storage/ocs-deviceset-localblock-0-data-2mz7zn localblock 44d
local-pv-fc84cac 10Gi RWO Delete Bound openshift-monitoring/alertmanager-main-db-alertmanager-main-0 local-alertmanagermain 220d
pvc-1efa22ea-6ceb-4ca1-96dc-28538c711e6d 150Gi RWO Delete Bound openshift-logging/wal-logging-lokistack-ingester-1 ocs-storagecluster-ceph-rbd 44d
pvc-3e3abe0f-90fb-4116-b643-f7dcada73612 50Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-index-gateway-1 ocs-storagecluster-ceph-rbd 44d
pvc-43fca63a-21cf-4b88-936b-bec1fa58a027 100Gi RWO Delete Bound openshift-storage/loki-backingstore-noobaa-pvc-40a78edf ocs-storagecluster-ceph-rbd 44d
pvc-5517c083-4115-438d-850e-69e8748f0fb0 10Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-ingester-1 ocs-storagecluster-ceph-rbd 44d
pvc-63859b3f-ad89-4470-a481-e9bfaf5aaa03 100Gi RWO Delete Bound openshift-storage/loki-backingstore-noobaa-pvc-933a9ff4 ocs-storagecluster-ceph-rbd 44d
pvc-a1274593-7864-4ce4-826f-6a1c809dbc76 10Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-compactor-0 ocs-storagecluster-ceph-rbd 44d
pvc-a5937d8a-6bbb-4914-b8c9-cccf3048f87e 100Gi RWO Delete Bound openshift-storage/loki-backingstore-noobaa-pvc-3fea5969 ocs-storagecluster-ceph-rbd 44d
pvc-b96220ee-4671-4b6e-bde2-2449c9a5016d 150Gi RWO Delete Bound openshift-logging/wal-logging-lokistack-ingester-0 ocs-storagecluster-ceph-rbd 44d
pvc-c437bda3-1431-4124-82ae-662ee2a54a33 50Gi RWO Delete Bound openshift-storage/db-noobaa-db-pg-0 ocs-storagecluster-ceph-rbd 44d
pvc-d3d6b2b2-e14d-4a5c-9a46-d1b668ce8bd5 50Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-index-gateway-0 ocs-storagecluster-ceph-rbd 44d
pvc-f97a47b6-b76c-41be-b8d5-0f4273dc2111 10Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-ingester-0 ocs-storagecluster-ceph-rbd 44d
[root@bastion-01 ~]#
アップデート
CLIでSubscriptionリソースのChennelを更新しても良いのですが、ここではGUIでやりました。
OCPのGUIのメニューからOperator->インストール済みのOperatorを選択し、画面でopenshift-local-storageプロジェクトを選択し、表示されるLocal Storage Operatorのエントリーをクリックします。
サブスクリプションタブを選択します。
サブスクリプション更新チャネルのstableのリンクをクリックします。
このLocal Storage Operatorは更新チャネルがstableしかありませんでした。
また最新のバージョンとしてlocal-storage-operator.v4.12.0-202302061702が表示されていました。
今回は「更新の承認」をManualにしているので、そのままではアップデートされません。アップグレードのステータスの横にある「1件に承認が必要」のリンクをクリックします。
該当InstallPlanの画面が表示されます。ただ、このInstallPlanのバージョンが、先ほど表示された最新のバージョンより小さいので、このInstallPlanを削除して、あたらしInstallPlanを作成します。
左上のInstallPlanのリンクをクリックします。
InstallPlanの一覧が表示されます。
ステータスがRequiresApprovalで、バージョンがlocal-storage-operator.4.11.0-202212070335のInstallPlanを削除します。
右側の3点のリンクをクリックし「InstallPlanの削除」をクリックします。
確認のメッセージが出たら「削除」をクリックします。
先ほどstableのChannelで表示されていた、作業時の最新のCSVバージョンのlocal-storage-operator.v4.12.0-202302061702のInstallPlanが表示されます。
このInstallPlanのリンクをクリックします。
該当InstallPlanの画面の「手動のInstallPlanの確認」欄の「InstallPlanのプレビュー」をクリックします。
アップデート対象のものを画面下部で確認し、「承認」をクリックします。
InstallPlanが適用され、アップデートが始まります。
しばらくするとLocal Storage Operatorのアップデートが完了しインストール済みのバージョンが先ほど承認したInstallPlanに表示されていたバージョンに変わっています。
アップデート後の確認
local-storage operatorのChannelはstableのままです。
csvのVERSIONは、v4.12.0-202302061702というバージョンになっています。
[root@bastion-01 ~]# oc get sub -n openshift-local-storage
NAME PACKAGE SOURCE CHANNEL
local-storage-operator local-storage-operator redhat-operators stable
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-local-storage
NAME DISPLAY VERSION REPLACES PHASE
elasticsearch-operator.5.5.5 OpenShift Elasticsearch Operator 5.5.5 elasticsearch-operator.5.4.9 Succeeded
local-storage-operator.v4.12.0-202302061702 Local Storage 4.12.0-202302061702 local-storage-operator.4.11.0-202211072116 Succeeded
loki-operator.5.5.5 Loki Operator 5.5.5 Succeeded
[root@bastion-01 ~]#
4.12.0のInstallPlanのAPPROVED欄がtrueになっています。
アップデート直後なのでstable Channelのより新しいInstallPlanはまだない状態です。
[root@bastion-01 ~]# oc get installplan -n openshift-local-storage
NAME CSV APPROVAL APPROVED
install-f2rfw local-storage-operator.4.11.0-202211072116 Manual true
install-fq5qr local-storage-operator.4.8.0-202206281335 Automatic true
install-rz8lq local-storage-operator.v4.12.0-202302061702 Manual true
install-zdsfg local-storage-operator.4.10.0-202207192148 Manual true
install-zslmm local-storage-operator.4.10.0-202206291026 Manual true
[root@bastion-01 ~]#
Local Storage OperatorのPodは再作成されています。
モニタリング用のPVやLocalvolumeリソース、ODF用のlocalvolumesetなども正常に保持されています。
[root@bastion-01 ~]# oc get pod -n openshift-local-storage -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
diskmaker-discovery-6c4n2 2/2 Running 0 97s 10.128.4.23 storage-01 <none> <none>
diskmaker-discovery-b55pk 2/2 Running 0 2m16s 10.128.2.25 infra-02 <none> <none>
diskmaker-discovery-cg89v 2/2 Running 0 84s 10.130.2.22 infra-01 <none> <none>
diskmaker-discovery-h7vv7 2/2 Running 0 101s 10.129.2.24 infra-03 <none> <none>
diskmaker-discovery-j7mrk 2/2 Running 0 92s 10.131.2.12 worker-01 <none> <none>
diskmaker-discovery-lldjg 2/2 Running 0 2m7s 10.129.4.16 storage-02 <none> <none>
diskmaker-discovery-qtwgr 2/2 Running 0 119s 10.130.4.10 storage-03 <none> <none>
diskmaker-discovery-v9n9j 2/2 Running 0 110s 10.131.0.21 worker-02 <none> <none>
diskmaker-manager-5snlc 2/2 Running 0 116s 10.128.2.26 infra-02 <none> <none>
diskmaker-manager-8r2s4 2/2 Running 0 2m8s 10.130.2.21 infra-01 <none> <none>
diskmaker-manager-bnf59 2/2 Running 0 2m16s 10.128.4.22 storage-01 <none> <none>
diskmaker-manager-k9xn5 2/2 Running 0 2m 10.129.4.17 storage-02 <none> <none>
diskmaker-manager-kbxs9 2/2 Running 0 103s 10.130.4.11 storage-03 <none> <none>
diskmaker-manager-tjths 2/2 Running 0 112s 10.129.2.23 infra-03 <none> <none>
local-storage-operator-585f8d5b5-wqqld 1/1 Running 0 4m47s 10.130.2.20 infra-01 <none> <none>
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
NAME AGE
localvolume-alertmanagermain 220d
localvolume-prometheusk8s 220d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get localvolumesets -n openshift-local-storage
NAME STORAGECLASS PROVISIONED AGE
localblock localblock 3 44d
[root@bastion-01 ~]#
[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 221d
local-pv-13e978f0 40Gi RWO Delete Available local-prometheusk8s 220d
local-pv-6a3a9d54 40Gi RWO Delete Bound openshift-monitoring/prometheus-k8s-db-prometheus-k8s-1 local-prometheusk8s 220d
local-pv-6b3c4558 1Ti RWO Delete Bound openshift-storage/ocs-deviceset-localblock-0-data-022zww localblock 44d
local-pv-6cb91dfa 10Gi RWO Delete Bound openshift-monitoring/alertmanager-main-db-alertmanager-main-1 local-alertmanagermain 220d
local-pv-d94c27a1 1Ti RWO Delete Bound openshift-storage/ocs-deviceset-localblock-0-data-1mpknn localblock 44d
local-pv-e646c476 40Gi RWO Delete Bound openshift-monitoring/prometheus-k8s-db-prometheus-k8s-0 local-prometheusk8s 220d
local-pv-faa39169 1Ti RWO Delete Bound openshift-storage/ocs-deviceset-localblock-0-data-2mz7zn localblock 44d
local-pv-fc84cac 10Gi RWO Delete Bound openshift-monitoring/alertmanager-main-db-alertmanager-main-0 local-alertmanagermain 220d
pvc-1efa22ea-6ceb-4ca1-96dc-28538c711e6d 150Gi RWO Delete Bound openshift-logging/wal-logging-lokistack-ingester-1 ocs-storagecluster-ceph-rbd 44d
pvc-3e3abe0f-90fb-4116-b643-f7dcada73612 50Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-index-gateway-1 ocs-storagecluster-ceph-rbd 44d
pvc-43fca63a-21cf-4b88-936b-bec1fa58a027 100Gi RWO Delete Bound openshift-storage/loki-backingstore-noobaa-pvc-40a78edf ocs-storagecluster-ceph-rbd 44d
pvc-5517c083-4115-438d-850e-69e8748f0fb0 10Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-ingester-1 ocs-storagecluster-ceph-rbd 44d
pvc-63859b3f-ad89-4470-a481-e9bfaf5aaa03 100Gi RWO Delete Bound openshift-storage/loki-backingstore-noobaa-pvc-933a9ff4 ocs-storagecluster-ceph-rbd 44d
pvc-a1274593-7864-4ce4-826f-6a1c809dbc76 10Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-compactor-0 ocs-storagecluster-ceph-rbd 44d
pvc-a5937d8a-6bbb-4914-b8c9-cccf3048f87e 100Gi RWO Delete Bound openshift-storage/loki-backingstore-noobaa-pvc-3fea5969 ocs-storagecluster-ceph-rbd 44d
pvc-b96220ee-4671-4b6e-bde2-2449c9a5016d 150Gi RWO Delete Bound openshift-logging/wal-logging-lokistack-ingester-0 ocs-storagecluster-ceph-rbd 44d
pvc-c437bda3-1431-4124-82ae-662ee2a54a33 50Gi RWO Delete Bound openshift-storage/db-noobaa-db-pg-0 ocs-storagecluster-ceph-rbd 44d
pvc-d3d6b2b2-e14d-4a5c-9a46-d1b668ce8bd5 50Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-index-gateway-0 ocs-storagecluster-ceph-rbd 44d
pvc-f97a47b6-b76c-41be-b8d5-0f4273dc2111 10Gi RWO Delete Bound openshift-logging/storage-logging-lokistack-ingester-0 ocs-storagecluster-ceph-rbd 44d
[root@bastion-01 ~]#
OpenShift Data Foundationのアップデート
ODFも同様な手順でアップデートします。
手順は以下の通りに実施します。
ODF 4.12 Docs / OpenShift Data Foundation の更新 / 3. Red Hat OpenShift Data Foundation 4.11 から 4.12 への更新
アップデート前の確認
ODF 4.12 Docs / OpenShift Data Foundation の更新 / 3. Red Hat OpenShift Data Foundation 4.11 から 4.12 への更新に記載のあるように、ステータスが正常なことを確認してからアップデートをします。
(この検証環境はアップデート前から5.5のLokiの使用するMSGのオブジェクトストレージが容量不足でエラーになっている状況なので、一旦ステータスやアップデート後の状況は無視して、Operatorのアップデートができることのみ確認します。)
OpenShift Data Foundation Operator自体は、OCP 4.12の削除されたAPIの確認でも確認していたように、rook関連のcronjobのAPIが削除されて新しいAPIに置き換える必要がありました。
OpenShift Data Foundation OperatorのSubscription画面では、それに関連すると思われるメッセージが表示されていました。またInstallPlanも1件が失敗となっていました。
ここは一旦無視してアップデートします。
アップデート
サブスクリプション更新チャネルのstable-4.11のリンクをクリックします。
サブスクリプション更新チャネルの変更でstable-4.12を選択し保存をクリックします。
また最新のバージョンとしてodf-operator.v4.12.0が表示されていました。
今回は「更新の承認」をManualにしているので、そのままではアップデートされません。アップグレードのステータスの横にある「1件が失敗」のリンクをクリックします。
該当InstallPlanの画面が表示されます。ただ、このInstallPlanのバージョンが、先ほど表示された最新のバージョンより小さい、かつ、失敗しているのでこのInstallPlanを削除して、あたらしInstallPlanを作成します。
左上のInstallPlanのリンクをクリックします。
InstallPlanの一覧が表示されます。
ステータスがFailedのInstallPlanを削除します。
右側の3点のリンクをクリックし「InstallPlanの削除」をクリックします。
確認のメッセージが出たら「削除」をクリックします。
先ほどstable-4.12のChannelで表示されていた、作業時の最新のCSVバージョンのodf-operator.v4.12.0のInstallPlanが表示されます。
このInstallPlanのリンクをクリックします。
該当InstallPlanの画面の「手動のInstallPlanの確認」欄の「InstallPlanのプレビュー」をクリックします。
アップデート対象のものを画面下部で確認し、「承認」をクリックします。
InstallPlanが適用され、アップデートが始まります。
しばらくするとOpenShift Data Foundation Operatorのアップデートが完了しインストール済みのバージョンが先ほど承認したInstallPlanに表示されていたバージョンに変わっています。
また、先ほど表示されていたOCP 4.12の削除されたcronjobのAPIに関連するエラーメッセージも消えていました。
アップデート後の確認
先ほどインストールされたInstallPlanを見ると、関連した幾つかのCSVがあり、今回はodf-operatorだけ4.12.0になり、ocs-operator、mcg-operator、odf-csi-addons-operatorは、4.11.5のままで、全てが正常にアップデートされいないようでした。
[root@bastion-01 ~]# oc get sub -n openshift-storage
NAME PACKAGE SOURCE CHANNEL
mcg-operator-stable-4.11-redhat-operators-openshift-marketplace mcg-operator redhat-operators stable-4.12
ocs-operator-stable-4.11-redhat-operators-openshift-marketplace ocs-operator redhat-operators stable-4.12
odf-csi-addons-operator-stable-4.11-redhat-operators-openshift-marketplace odf-csi-addons-operator redhat-operators stable-4.12
odf-operator odf-operator redhat-operators stable-4.12
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-storage
NAME DISPLAY VERSION REPLACES PHASE
elasticsearch-operator.5.5.5 OpenShift Elasticsearch Operator 5.5.5 elasticsearch-operator.5.4.9 Succeeded
loki-operator.5.5.5 Loki Operator 5.5.5 Succeeded
mcg-operator.v4.11.5 NooBaa Operator 4.11.5 mcg-operator.v4.11.4 Succeeded
ocs-operator.v4.11.4 OpenShift Container Storage 4.11.4 ocs-operator.v4.11.3 Replacing
ocs-operator.v4.11.5 OpenShift Container Storage 4.11.5 ocs-operator.v4.11.4 Pending
odf-csi-addons-operator.v4.11.5 CSI Addons 4.11.5 odf-csi-addons-operator.v4.11.4 Succeeded
odf-operator.v4.12.0 OpenShift Data Foundation 4.12.0 odf-operator.v4.11.4 Succeeded
[root@bastion-01 ~]#
ずっとocs-operator.v4.11.4がずっとReplacingで、v4.11.5がPendingになっていたので、v4.11.4を手動で削除しました。
[root@bastion-01 ~]# oc delete csv -n openshift-storage ocs-operator.v4.11.4
clusterserviceversion.operators.coreos.com "ocs-operator.v4.11.4" deleted
[root@bastion-01 ~]#
しばらくすると、odf-operatorだけではなく、ocs-operator、mcg-operator、odf-csi-addons-operatorのCSVも4.12.0になりました。
[root@bastion-01 ~]# oc get sub -n openshift-storage
NAME PACKAGE SOURCE CHANNEL
mcg-operator-stable-4.11-redhat-operators-openshift-marketplace mcg-operator redhat-operators stable-4.12
ocs-operator-stable-4.11-redhat-operators-openshift-marketplace ocs-operator redhat-operators stable-4.12
odf-csi-addons-operator-stable-4.11-redhat-operators-openshift-marketplace odf-csi-addons-operator redhat-operators stable-4.12
odf-operator odf-operator redhat-operators stable-4.12
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-storage
NAME DISPLAY VERSION REPLACES PHASE
elasticsearch-operator.5.5.5 OpenShift Elasticsearch Operator 5.5.5 elasticsearch-operator.5.4.9 Succeeded
loki-operator.5.5.5 Loki Operator 5.5.5 Succeeded
mcg-operator.v4.12.0 NooBaa Operator 4.12.0 mcg-operator.v4.11.5 Succeeded
ocs-operator.v4.12.0 OpenShift Container Storage 4.12.0 ocs-operator.v4.11.5 Succeeded
odf-csi-addons-operator.v4.12.0 CSI Addons 4.12.0 odf-csi-addons-operator.v4.11.5 Succeeded
odf-operator.v4.12.0 OpenShift Data Foundation 4.12.0 odf-operator.v4.11.4 Succeeded
[root@bastion-01 ~]#
Loki Operator、Red Hat OpenShift Loggingをアップデート
Loki OperatorとRed Hat OpenShift Loggingをアップデートします。
Elasticsearch OperatorとRed Hat OpenShift Loggingの時も、Elasticsearch Operator -> Red Hat OpenShift Loggingの順番でアップデートする必要があったので、今回もLoki Operator -> Red Hat OpenShift Loggingの順番でアップデートしました。
(Loki Operatorのアップデート手順はドキュメントには載っていませんでしたが、普通に他と同じやり方でやっています。)
(あとはもっと早くやっておけばよかったですが、Lokiにしてもう不要だったElasticsearch Operatorもこのタイミングでちゃんと消しておきました。(手順は割愛))
OCP 4.12 Docs / ロギング / 14. OpenShift Logging のアンインストール / 14.1. Red Hat のロギングサブシステムのアンインストール
アップデート前の確認
(こちらもこの検証環境の問題でアップデート前のLokiのステータスが正常ではないので、ただ単にOperatorのアップデートの手順のみ記載します。)
アップデート (Loki Operator)
OCPのGUIのメニューからOperator->インストール済みのOperatorを選択し、画面でopenshift-operators-redhatプロジェクトを選択し、表示されるLoki Operatorのエントリーをクリックします。
サブスクリプションタブを選択します。
サブスクリプション画面で、更新チャネルのstable-5.5のリンクをクリックします。
サブスクリプション更新チャネルの変更でstable-5.6を選択し保存をクリックします。
更新チャネルがstable-5.6になりました。
今回は「更新の承認」をManualにしているので、そのままではアップデートされません。stable-5.5の際のまだ承認されていなかったInstallPlanがあるので削除します。1件の承認が必要のリンクをクリックします。
該当InstallPlanの画面が表示されます。このInstallPlanはstable-5.5の時のものなのでこのInstallPlanを削除して、stable-5.6の最新のInstallPlanを作成します。
左上のInstallPlanのリンクをクリックします。
InstallPlanの一覧が表示されます。
ステータスがRequiresApprovalのInstallPlanを削除します。
右側の3点のリンクをクリックし「InstallPlanの削除」をクリックします。
確認のメッセージが出たら「削除」をクリックします。
先ほどstable-5.6のChannelで表示されていた、作業時の最新のCSVバージョンのloki-operator.v5.6.2のInstallPlanが表示されます。
該当InstallPlanの画面の「手動のInstallPlanの確認」欄の「InstallPlanのプレビュー」をクリックします。
アップデート対象のものを画面下部で確認し、承認をクリックします。
InstallPlanが適用され、アップデートが始まります。
しばらくするとLoki Operatorのアップデートが完了しインストール済みのバージョンが先ほど承認したInstallPlanに表示されていたバージョンに変わっています。
アップデート後の確認 (Loki Operator)
Loki OperatorののChannelはstable-5.6になっています。
csvのVERSIONは、loki-operator.v5.6.2というバージョンになっています。
[root@bastion-01 ~]# oc get sub -n openshift-operators-redhat
NAME PACKAGE SOURCE CHANNEL
loki-operator loki-operator redhat-operators stable-5.6
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-operators-redhat
NAME DISPLAY VERSION REPLACES PHASE
loki-operator.v5.6.2 Loki Operator 5.6.2 loki-operator.5.5.5 Succeeded
[root@bastion-01 ~]#
5.6のInstallPlanのAPPROVED欄がtrueになっています。
アップデート直後なのでstable-5.6 Channelのより新しいInstallPlanはまだない状態です。
[root@bastion-01 ~]# oc get installplan -n openshift-operators-redhat
NAME CSV APPROVAL APPROVED
install-l5xp2 loki-operator.v5.6.2 Manual true
install-xj6j8 loki-operator.5.5.5 Manual true
[root@bastion-01 ~]#
OperatorのPodは作り直されています。
[root@bastion-01 ~]# oc get pod -n openshift-operators-redhat
NAME READY STATUS RESTARTS AGE
loki-operator-controller-manager-6877778965-4k2s4 2/2 Running 0 2m40s
[root@bastion-01 ~]#
アップデート (Red Hat OpenShift Logging)
OCPのGUIのメニューからOperator->インストール済みのOperatorを選択し、画面でopenshift-logingプロジェクトを選択し、表示されるRed Hat OpenShift Logging Operatorのエントリーをクリックします。
サブスクリプションタブを選択します。
サブスクリプション画面で、更新チャネルのstable-5.5のリンクをクリックします。
サブスクリプション更新チャネルの変更でstable-5.6を選択し保存をクリックします。
更新チャネルがstable-5.6になりました。
今回は「更新の承認」をManualにしているので、そのままではアップデートされません。stable-5.5の際のまだ承認されていなかったInstallPlanがあるので削除します。1件の承認が必要のリンクをクリックします。
該当InstallPlanの画面が表示されます。このInstallPlanはstable-5.5の時のものなのでこのInstallPlanを削除して、stable-5.6の最新のInstallPlanを作成します。
左上のInstallPlanのリンクをクリックします。
InstallPlanの一覧が表示されます。
ステータスがRequiresApprovalのInstallPlanを削除します。
右側の3点のリンクをクリックし「InstallPlanの削除」をクリックします。
確認のメッセージが出たら「削除」をクリックします。
先ほどstable-5.6のChannelで表示されていた、作業時の最新のCSVバージョンのcluster-logging.v5.6.2のInstallPlanが表示されます。
該当InstallPlanの画面の「手動のInstallPlanの確認」欄の「InstallPlanのプレビュー」をクリックします。
アップデート対象のものを画面下部で確認し、承認をクリックします。
InstallPlanが適用され、アップデートが始まります。
しばらくするとRed Hat OpenShift Logging Operatorのアップデートが完了しインストール済みのバージョンが先ほど承認したInstallPlanに表示されていたバージョンに変わっています。
アップデート後の確認 (Red Hat OpenShift Logging)
Red Hat OpenShift Loging OperatorののChannelはstable-5.6になっています。
csvのVERSIONは、5.6.2というバージョンになっています。
[root@bastion-01 ~]# oc get sub -n openshift-logging
NAME PACKAGE SOURCE CHANNEL
cluster-logging cluster-logging redhat-operators stable-5.6
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-logging
NAME DISPLAY VERSION REPLACES PHASE
cluster-logging.v5.6.2 Red Hat OpenShift Logging 5.6.2 cluster-logging.5.5.5 Succeeded
loki-operator.v5.6.2 Loki Operator 5.6.2 loki-operator.5.5.5 Succeeded
[root@bastion-01 ~]#
5.6のInstallPlanのAPPROVED欄がtrueになっています。
アップデート直後なのでstable-5.6 Channelのより新しいInstallPlanはまだない状態です。
[root@bastion-01 ~]# oc get installplan -n openshift-logging
NAME CSV APPROVAL APPROVED
install-4pnl7 cluster-logging.v5.6.2 Manual true
install-lr49f cluster-logging.5.4.2 Automatic true
install-v2gq7 cluster-logging.5.5.5 Manual true
[root@bastion-01 ~]#
Cluster Loggingインスタンスの状態を確認します。
(こちらはバージョンアップ前も正常ではなかったので、ここでは割愛します。。あとでCluster Loggingのインスタンスは一旦削除して、Loki用のオブジェクトストレージを再作成して、再度Lokiを使用したCluster Loggingインスタンスを作成します。。Cluster Loggingの5.6からはLokiのデータ保存期間を設定できるので、ディスクが溢れないようにできます。)
[root@bastion-01 ~]# oc get clusterlogging -n openshift-logging
NAME MANAGEMENT STATE
instance Managed
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-logging
NAME READY STATUS RESTARTS AGE
cluster-logging-operator-75f4d8848d-gl6w7 1/1 Running 0 106s
#(以下略、この環境では幾つか正常でないPodがあるけど環境依存なので省略)
