OpenShift 4 - OpenShift是如何升级RHCOS的
《OpenShift 4.x HOL教程汇总》
文章目录
- RHCOS是如何升级的？
-
- 查看OpenShift集群的RHCOS环境
- 升级OpenShift
- 确认升级更新后的RHCOS版本
- 可以对RHCOS手动降级么？
我们在《OpenShift 4 - Fedora CoreOS (1) - (6)》中了解了Fedora CoreOS（FCOS）的更新机制。由于Red Hat Enterprise Linux CoreOS（RHCOS）的上游项目，因此RHCOS使用了同样的机制进行升级更新。但是RHCOS和FCOS升级还是有些区别，其中FCOS的灵活度比较高，我们可以让FCOS定时或手动触发升级过程；而RHCOS升级的灵活度比价有限，因为我们不能单独只对RHCOS进行手动升级，RHCOS只能在OpenShift升级过程中通过machine operator被触发。
RHCOS是如何升级的？
查看OpenShift集群的RHCOS环境
查看OpenShift集群版本和Kubernetes版本，它们分别是“4.5.4”和“v1.18.3+012b3ec”。
$ oc get clusterversions
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.5.4 True False 16h Cluster version is 4.5.4
$ oc get node
NAME STATUS ROLES AGE VERSION
ip-10-0-152-6.ap-southeast-1.compute.internal Ready master 16h v1.18.3+012b3ec
ip-10-0-154-93.ap-southeast-1.compute.internal Ready worker 16h v1.18.3+012b3ec
ip-10-0-162-122.ap-southeast-1.compute.internal Ready worker 16h v1.18.3+012b3ec
ip-10-0-176-41.ap-southeast-1.compute.internal Ready master 16h v1.18.3+012b3ec
ip-10-0-203-175.ap-southeast-1.compute.internal Ready master 16h v1.18.3+012b3ec
进入OpenShift集群中的一个节点，然后进入“/host”。
$ oc debug node/ip-10-0-152-6.ap-southeast-1.compute.internal
Starting pod/ip-10-0-152-6ap-southeast-1computeinternal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.152.6
If you don't see a command prompt, try pressing enter.
sh-4.2# chroot /host
查看rpm-ostree的状态，确认当前操作系统RHCOS使用的版本是“45.82.202007240629-0”，根据“Managed by machine-config-operator”的提示可以知道这个ostree是受到OpenShift的machine-config-operator管理的。另外在下面2个Deployment中，下面“ortree”一行代表RHCOS刚安装好的原始环境，而上面一行“pivot”代表从当前环境已经升级到指定的OpenShift对应的RHCOS版本了。
sh-4.4# rpm-ostree status
State: idle
Deployments:
* pivot://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:77e9ace116cec652637a79449dea00c6b4af5463ca2474463549cf145bc44438
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202007240629-0 (2020-07-24T06:33:19Z)
ostree://67315b4b010341ffd396fe699287defe530830b17879d695fec0243b87e97c82
Version: 45.82.202007141718-0 (2020-07-14T17:21:59Z)
另外，我们还可从OpenShift的控制台中的Administration->Cluster Settings页面（下图）看出当前OpenShift是从原始（RHCOS）环境升级到适合OpenShift 4.5.4运行的环境。
执行以下命令尝试更新当前RHCOS，根据返回提示确认无法升级，这是因为必须要通过machine-config-operator才能发起对OpenShift的RHCOS升级。
sh-4.4# rpm-ostree upgrade
Pinned to commit by custom origin: Managed by machine-config-operator
升级OpenShift
登录OpenShift控制台，然后进入Administration->Cluster Settings，将OpenShift从当前版本（v4.5.4）升级一个小本（到 v4.5.5）。
OpenShift的升级过程大致如下：
- 首先在原有版本的OpenShift环境中升级更新除machine-config以及和网络相关的其他Cluster Operator。
- 然后再升级更新和网络相关Cluster Operator，主要包括dns和network这两个Cluster Operator。
- 最后升级更新的Cluster Operator就是machine-config，它升级的是更新底层的RHCOS（见下图）。
- 在完成全部更新后OpenShift会循环重启RHCOS，这样整个OpenShift集群升级就完成了。
在RHCOS升级的时候会以容器镜像的方式获得更新的内容。更新内容会从容器中被取出写入磁盘，然后RHCOS的bootloader会指向新版，这样在重启后就完成RHCOS升级了。
当升级machine-config Cluster Operator的时候可以持续在OpenShift节点中执行以下命令，幸运的话可以看到升级该节点RHCOS的中间状态。可以从以下信息看出升级RHCOS是作为Transaction执行的，当前正在基于新的“pivot://quay.io/openshift-release-dev/ocp-v4.0-a rt-dev@sha256:50583514d28ef1f4bfea9dbbae9e083026cf95491b5d4dfdc375e7ffc037f861”替换现有RHCOS。
sh-4.4# rpm-ostree status
State: busy
Transaction: rebase --experimental '/var/lib/containers/storage/overlay/31d1175712bfb3186635fc6c5bdc7c5097ce5cd70f607641305421965974cc19/merged/ srv/repo:f9d88d07921009f524c39773d0935a7d1642a02bd37e0d621696bf4f766a0540' --custom-origin-url 'pivot://quay.io/openshift-release-dev/ocp-v4.0-a rt-dev@sha256:50583514d28ef1f4bfea9dbbae9e083026cf95491b5d4dfdc375e7ffc037f861' --custom-origin-description 'Managed by machine-config-operator'
Initiator: client(id:cli dbus:1.980 unit:machine-config-daemon-host.service uid:0)
Deployments:
* pivot://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:77e9ace116cec652637a79449dea00c6b4af5463ca2474463549cf145bc44438
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202007240629-0 (2020-07-24T06:33:19Z)
ostree://67315b4b010341ffd396fe699287defe530830b17879d695fec0243b87e97c82
Version: 45.82.202007141718-0 (2020-07-14T17:21:59Z)
确认升级更新后的RHCOS版本
当OpenShift集群升级完成后再次进入其中的一个节点，在进入“/host”后执行以下命令查看rpm-ostree状态。此时确认带有*的已经指向新版“45.82.202008010929”的RHCOS了，而原有45.82.202007240629-0版本已经不是最新的了。
sh-4.4# rpm-ostree status
State: idle
Deployments:
* pivot://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:50583514d28ef1f4bfea9dbbae9e083026cf95491b5d4dfdc375e7ffc037f861
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202008010929-0 (2020-08-01T09:33:23Z)
pivot://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:77e9ace116cec652637a79449dea00c6b4af5463ca2474463549cf145bc44438
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202007240629-0 (2020-07-24T06:33:19Z)
注意：RHCOS的ostree只记录了2个成功的Deployment，因此最开始的ostree部署记录就已经不在了。如果再对OpenShift集群做一次升级，则rpm-ostree只会记录新版和“45.82.202008010929-0”，而“45.82.202007240629-0”会被丢弃。
执行以下命令可以查看本次RHCOS升级涉及到更新了哪些操作系统的rpm。
sh-4.4# rpm-ostree db diff
ostree diff commit from: rollback deployment (6be58e334103982d73c0aec860c5b52cd6f2cbd542c57a66be34d2cab63e6693)
ostree diff commit to: booted deployment (f9d88d07921009f524c39773d0935a7d1642a02bd37e0d621696bf4f766a0540)
Upgraded:
conmon 2:2.0.17-1.rhaos4.5.el8 -> 2:2.0.20-1.rhaos4.5.el8
containers-common 1:1.0.0-1.module+el8.2.1+6676+604e1b26 -> 1:1.1.1-1.rhaos4.5.el8
cri-o 1.18.3-5.rhaos4.5.git1c13d1d.el8 -> 1.18.3-8.rhaos4.5.gitbefe37e.el8
grub2-common 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
grub2-efi-x64 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
grub2-pc 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
grub2-pc-modules 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
grub2-tools 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
grub2-tools-extra 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
grub2-tools-minimal 1:2.02-82.el8_2.1 -> 1:2.02-87.el8_2
kernel 4.18.0-193.13.2.el8_2 -> 4.18.0-193.14.3.el8_2
kernel-core 4.18.0-193.13.2.el8_2 -> 4.18.0-193.14.3.el8_2
kernel-devel 4.18.0-193.13.2.el8_2 -> 4.18.0-193.14.3.el8_2
kernel-headers 4.18.0-193.13.2.el8_2 -> 4.18.0-193.14.3.el8_2
kernel-modules 4.18.0-193.13.2.el8_2 -> 4.18.0-193.14.3.el8_2
kernel-modules-extra 4.18.0-193.13.2.el8_2 -> 4.18.0-193.14.3.el8_2
machine-config-daemon 4.5.0-202007240519.p0.git.2535.1a1687b.el8 -> 4.5.0-202007301938.p0.git.2540.b8d50fe.el8
openshift-hyperkube 4.5.0-202007240519.p0.git.0.d5f9457.el8 -> 4.5.0-202007301645.p0.git.0.a5dde9c.el8
openvswitch2.13 2.13.0-39.el8fdp -> 2.13.0-49.el8fdp
shim-x64 15-11 -> 15-15.el8_2
skopeo 1:1.0.0-1.module+el8.2.1+6676+604e1b26 -> 1:1.1.1-1.rhaos4.5.el8
toolbox 0.0.7-1.rhaos4.5.el8 -> 0.0.8-1.rhaos4.5.el8
可以对RHCOS手动降级么？
我们可以在FCOS中对FCOS更新进行手动rollback回退操作，而是实现降级。然而RHCOS的升级只能通过OpenShift的machine-operator，因此即便是是在升级RHCOS出现问题，也需要由OpenShift发起rollback回退。不过不像执行“rpm-ostree upgrade”那样会被禁止，在RHCOS中可以手动执行“rpm-ostree rollback”。不过根据本人测试虽然可以成功降级OpenShift中所有节点的RHCOS，但是在reboot RHCOS后OpenShift集群就不能成功启动了。
- 以下是回退操作。最后显示只有在reboot才能生效。
sh-4.4# rpm-ostree rollback
Moving 'cc6b04c267773909d8ff26db1aa185ff30c0d953a54aa80f3ef6b092ed658465.0' to be first deployment
Bootloader updated; bootconfig swap: yes; deployment count change: 0
Downgraded:
machine-config-daemon 4.5.0-202009260105.p0.git.2568.f76ca42.el8 -> 4.5.0-202009111813.p0.git.2563.7c12c13.el8
openshift-hyperkube 4.5.0-202009261118.p0.git.0.1637ada.el8 -> 4.5.0-202009172050.p0.git.0.fe2f5b1.el8
runc 1.0.0-71.rhaos4.5.git5101761.el8 -> 1.0.0-70.rhaos4.5.gite677e8b.el8
Run "systemctl reboot" to start a reboot
- 在reboot RHCOS前可查看rpm-ostree 状态。可以看到当前*指向的是上一个版本“45.82.202007240629-0”。
sh-4.4# rpm-ostree status
State: idle
Deployments:
pivot://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:50583514d28ef1f4bfea9dbbae9e083026cf95491b5d4dfdc375e7ffc037f861
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202008010929-0 (2020-08-01T09:33:23Z)
* pivot://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:77e9ace116cec652637a79449dea00c6b4af5463ca2474463549cf145bc44438
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202007240629-0 (2020-07-24T06:33:19Z)