《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/[email protected]: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 [email protected]: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 [email protected]: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/[email protected]: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/[email protected]:50583514d28ef1f4bfea9dbbae9e083026cf95491b5d4dfdc375e7ffc037f861
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202008010929-0 (2020-08-01T09:33:23Z)
pivot://quay.io/openshift-release-dev/[email protected]: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/[email protected]:50583514d28ef1f4bfea9dbbae9e083026cf95491b5d4dfdc375e7ffc037f861
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202008010929-0 (2020-08-01T09:33:23Z)
* pivot://quay.io/openshift-release-dev/[email protected]:77e9ace116cec652637a79449dea00c6b4af5463ca2474463549cf145bc44438
CustomOrigin: Managed by machine-config-operator
Version: 45.82.202007240629-0 (2020-07-24T06:33:19Z)