概要
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.9 Docs
- 4.10 Docs
4.8 -> 4.9に上げるための準備(削除されたAPI対応)
- 4.9 Docs
- OCP 4.9 Docs / クラスターの更新 / 4. OpenShift Container Platform 4.9 への更新の準備
- OCP 4.9 Docs / クラスターの更新 / 4. OpenShift Container Platform 4.9 への更新の準備 / 4.2. 削除された API に関するクラスターの評価
- KB 6329921 / Preparing to upgrade to OpenShift Container Platform 4.9
- KB 6955985 / Navigating Kubernetes API deprecations and removals
- Kubernetes Docs
OCPとOperatorのバージョンの互換性
検証構成
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は以下の手順で作成しています。
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対応)
-
4.9 Docs
-
kB
-
Kubernetes Docs
-
ここでは、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
管理者の確認
削除される予定の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をひとつづつバージョンアップしてOCP4.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のChannel4.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]#
修正前
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/のエントリーを削除する。
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をアップデートできるように運用を計画しておく方が良いかなとは思います。