OpenShift的EUS区更新（从eus-4.8到eus-4.10）
简要介绍
OpenShift容器平台（OCP）4.8及以上的所有偶数次次要更新（例如：4.8、4.10、4.12）都将成为延长更新支持（EUS）的版本。
在OCP 4.8及之后的版本中，可以在ESU之间进行更新，例如从4.8更新到4.10。但是，确切来说，并非一次更新的处理，主节点会逐个版本升级，如4.8 -> 4.9 -> 4.10，并进行两次重新启动。
另一方面，工作节点只需一次更新，如4.8 -> 4.10，因此重新启动的次数减少，从而缩短了整个更新过程的时间。
尽管如此，实际上，在OCP 4.10 GA之后，好像一段时间内没有OCP的微版本可以通过EUS进行4.8->4.10的更新。
然而，大约在七月中旬左右，终于出现了可以进行EUS更新的路径，所以我将把这次实际进行EUS更新的步骤作为备忘录记录下来。
请提供相关链接。
EUS之间的更新
-
- 4.9 Docs
OCP 4.9 Docs / クラスターの更新 / 5. EUS から EUS への更新を実行するための準備
4.10 Docs
OCP 4.10 Docs / クラスターの更新 / 4. EUS から EUS への更新を実行するための準備
為了將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
Deprecated API Migration Guide / Removed APIs by release / v1.22
OCP和运营商版本的兼容性
- 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で、ロギング、モニタリングの永続ボリュームを作成する
操作员
为了采用上述结构，追加引入的运算符如下。
流程的步驟
将从OCP 4.8.45升级到OCP 4.10.20的EUS Bear Metal UPI的OCP升级流程如下所示。
确认更新路径
- (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)のアップデート
操作员
-
- (1) 適宜必要なものをアップデート(例 Local Storage Operator (stable-4.8 -> stable-4.10)など)
-
- (2) alertmanagerのreplicasが3->2になるのでPVC/PVを一つ削除など
-
- (3) その他個別に導入していたものも対応
- ((*) Operatorやその他アプリは、OCPとの互換性によっては、OCPを4.10に上げる前にアップデートしておく必要があるものがある場合もありますので適宜判断ください。)
实际步骤
确认更新路径
确认更新路径
你可以在以下的链接中确认更新路径。
-
- 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
点击此处的“生成”按钮后，您可以看到在eus-4.10通道中，存在按照“4.8.45 -> 4.9.40 -> 4.10.20”的更新路径。
这次我将尝试在这个版本中进行EUS之间的更新。
OCP的基本实体
(1) 为了升级到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版本相关的问题风险。
请提供参考链接
-
- 4.8 -> 4.9に上げるための準備(削除されたAPI対応)
4.9 Docs
OCP 4.9 Docs / リリースノート / 1.5.2. 削除された機能 / 1.5. 非推奨および削除された機能 / 1.5.2.2. ベータ版 API が Kubernetes 1.22 から削除
OCP 4.9 Docs / クラスターの更新 / 4. OpenShift Container Platform 4.9 への更新の準備
kB
KB 6329921 / Preparing to upgrade to OpenShift Container Platform 4.9
KB 6955985 / Navigating Kubernetes API deprecations and removals
Kubernetes Docs
Deprecated API Migration Guide / Removed APIs by release / v1.22
我将按照 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。
使用APIRequestCount资源的-o jsonpath命令，可以提取username和userAgent的值，从而确定哪个工作负载正在使用洗出的ingresses.v1beta1.extensions API。现在执行以下命令来确认：
[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的转移将被预计删除。
由于我们在本次更新中没有部署任何Operator或应用程序，因此几乎没有使用即将在Kubernetes v1.22中删除的API，我们无需进行任何迁移适配。
然而，如果用户部署了操作员或应用程序，可能需要使用相应的API来进行处理。
-
- 対象となるAPI
OCP 4.9 Docs / リリースノート / 1.5.2. 削除された機能 / 1.5. 非推奨および削除された機能 / 1.5.2.2. ベータ版 API が Kubernetes 1.22 から削除
OCP 4.9 Docs / クラスターの更新 / 4. OpenShift Container Platform 4.9 への更新の準備 / 4.1. Kubernetes API の削除
KB 6329921 / Preparing to upgrade to OpenShift Container Platform 4.9
如果在上述的确认步骤中出现需要处理的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 ~]#
(2) 准备EUS区更新（停止工人基础设施MCP）
在ESU升级中，主节点将逐个升级为4.8-> 4.9-> 4.10，并运行两次重新启动。
与此同时，工作节点可以在一次升级中从4.8直接升级到4.10，将重新启动的次数减少到一次。
为了防止在主节点更新期间工作节点也进行更新，需要在工作节点的机器配置池（MCP）中执行更新暂停操作（Pause）。
在这个验证环境中，由于还创建了基础设施节点的MCP，所以不仅需要对工作节点进行更新暂停，还需要对基础设施节点进行更新暂停。
[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 ~]#
确认工人节点和基础设施节点上的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。
这一次我们选择了通过OCP的图形用户界面进行更新，而不是使用CLI。
根据刚刚确认的更新路径，我们将在eus-4.10频道上进行以下顺序的更新：从4.8.45版本升级到4.9.40版本，再升级到4.10.20版本。
(4) 将版本更新为4.8.45 -> 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 ~]#
[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 ~]#
(5) 版本升级至4.9.40，仅限于主分支的更新（主分支重新启动1次）。
[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 ~]#
主节点的Kubernetes版本已升级至v1.22，但工作节点和基础设施节点的版本仍为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。
根据更新路径的确认，我们确认了顺序为「4.8.45 -> 4.9.40 -> 4.10.20」，所以下一步将更新至4.10.20。
4月10日将开始进行更新。
[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 ~]#
[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 ~]#
(7) 只需更新(*)master版本（第二次master重启），版本号变为4.10.20。
这是通过命令行界面进行确认。
[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，但工作节点(worker)和基础设施节点(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版本同样是主节点升级到了4.10，但是工作节点和基础设施节点仍保持在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（基础设施）MCP的暂停(*)更新worker（基础设施）（worker（基础设施）重新启动1次）
因为worker使用的Machine Config Pool（MCP）已经实施了更新暂停操作（Pause），所以我们现在将解除这个操作。
在这个验证环境中，我们还创建了infra节点的MCP，因此不仅需要对worker节点，还需要对infra节点进行更新暂停操作（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 ~]#
确认工人节点和基础设施节点上的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和基础架构节点，为了应用新的MCP主控程序，将开始重新启动worker和基础架构节点。
[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 ~]#
(9) 师傅和工人都将在4月10日变成四十二。
我将通过CLI验证升级已成功完成。
版本号 clusterversion 的版本是 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的所有节点都被更新为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 ~]#
所有的节点都已经准备就绪，而且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 ~]#
集群操作员的 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节点都是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。(省略步骤。)
操作员
一旦OCP的升级完成后，我们会相应地进行附加操作，例如运算符和应用程序的更新。在这里，我们已经完成了以下工作。
(1) 更新合适必要的事项
（示例：本地存储操作员（稳定版4.8转至稳定版4.10）等）
考虑更新的对象
这次引入的运营商如下。
在OCP 4.8版本中引入的运算符版本。
当确认Red Hat OpenShift Container Platform的生命周期策略时，发现Logging（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などにアップデートする必要があったりします。
关于本地存储运算符，Red Hat OpenShift容器平台的生命周期政策中没有提到与OCP的兼容性。
然而，尽管Local Storage Operator仍然保持在4.8版本，但我已经成功将OCP本身升级到了4.10版本，所以我也会将这里的Local Storage Operator一同升级至4.10版本。
如果在OCP 4.10更新后升级Operator，版本将如何？
（補足）Local Storage Operator自身的更新范围
当确认Operator的csv文件的olm.skipRange时，可以看到这个Operator的这个版本能够从哪个版本进行更新的信息。
（以下是将Local Storage Operator升级到4.10后的csv显示）
当将Local Storage Operator通道升级到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，否则很难确认。
本地存储运营商的更新。
将本地存储操作员的Channel从4.8更新到4.10。
更新前的确认
我们将确认更新之前的状态。
本地存储操作员的通道已经达到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，它应该会处于等待批准状态。然而，在这个频道中，我们可以确认它已经是最新的版本。
[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 ~]#
本地卷资源本身创建了3个，设置了nodeSelector以在infra-0 [1-3]上创建PV。
[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
NAME AGE
localvolume-alertmanagermain 17d
localvolume-elasticsearch 17d
localvolume-prometheusk8s 17d
[root@bastion-01 ~]#
根据这个，Daemonset中的Pod被创建到infra-0[1-3]。
（在4.6版本中，通过localvolume资源的nodeSelector，在每个node上创建了local-diskmakerm和local-provisioner的Pod对，负责磁盘的格式化和挂载/卸载处理。
从4.8版本开始，不再是基于每个localvolume资源，而是在通过多个localvolume的nodeSelector指定的node上只有一个名为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副本数变为了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来更新订阅资源的通道，但在这里我们选择使用GUI完成。
确认更新后情况
本地存储运营商的频道已经更新到4.10。
CSV的版本已经更新为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 Channel中尚未有比4.10.0更新的版本的InstallPlan，因此4.10.0的InstallPlan的APPROVED欄位設為true。
[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 ~]#
本地卷资源保留了更新之前的内容不变。
[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主目录的持久卷（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 ~]#
由于alertmanager的副本减少了从3个变为2个，因此需要删除一个PVC/PV等。
将OCP 4.8升级到4.10后，监控组件的statefulset副本数量将如下所示发生变化。
[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副本数量增至2，因此根据需要，必要时需要删除多余的alertmanager-main持久卷（PV）。
这次的环境中，我们使用了local-storage operator，在3个基础设施节点上添加了虚拟磁盘，并创建了适用于alertmanager-main的localvolume资源，以及相应的PV。
由于alertmanager-main的Pod停止运行，将删除不再使用的PV/PVC。
当确认Alertmanager-main的Pod在哪个节点上运行时发现，它已经从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专用的持久卷和持久卷声明还未使用。
[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 ~]#
我认为这个视频可能只是未被使用，所以我认为保留它不动也可以。
然而，如果你想删除没有被妥善使用的东西，你需要更新localvolume资源。
由于alertmanager-main的statefulset的副本数量变为2，导致了名为alertmanager-main-2的Pod被删除。
由于被删除的Pod在infra-03上运行，因此将删除infra-03的PV/PVC。
首先，我们需要找出分配给alertmanager-main的虚拟磁盘在infra节点中的/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
修订后 (xiū
-
- 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 的副本数量已经减少至 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) 对于其他单独引入的事项也作出了相应调整。
操作员和其他应用程序可能需要在更新OCP到4.10之前先更新，因为它们与OCP的兼容性可能需要提前确认您使用的组件的文档等，并根据情况适当判断更新的顺序。
举个例子，Local Storage Operator在Red Hat OpenShift Container Platform的生命周期策略中没有提到与OCP的兼容性。
实际上，当尝试将OCP从4.6升级到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。
另外，操作员的API兼容性以及操作员实例的规范模式可能会发生变化，可能需要先卸载，然后在OCP更新后重新安装操作员可能更快。
在这方面，不仅仅需要在文档中进行兼容性确认，还应该准备版本升级验证环境并在实际设备上进行确认。
无论如何，基本上与其一次性将多个版本升级，还是最好将OCP的更新纳入运营计划以便根据需求及时进行更新。
