天天看點

OpenShift 4 - OpenShift是如何更新RHCOS的RHCOS是如何更新的?可以對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/[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運作的環境。

OpenShift 4 - OpenShift是如何更新RHCOS的RHCOS是如何更新的?可以對RHCOS手動降級麼?

執行以下指令嘗試更新目前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 4 - OpenShift是如何更新RHCOS的RHCOS是如何更新的?可以對RHCOS手動降級麼?

OpenShift的更新過程大緻如下:

  1. 首先在原有版本的OpenShift環境中更新更新除machine-config以及和網絡相關的其他Cluster Operator。
  2. 然後再更新更新和網絡相關Cluster Operator,主要包括dns和network這兩個Cluster Operator。
  3. 最後更新更新的Cluster Operator就是machine-config,它更新的是更新底層的RHCOS(見下圖)。
  4. 在完成全部更新後OpenShift會循環重新開機RHCOS,這樣整個OpenShift叢集更新就完成了。
    OpenShift 4 - OpenShift是如何更新RHCOS的RHCOS是如何更新的?可以對RHCOS手動降級麼?
    在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叢集就不能成功啟動了。

  1. 以下是回退操作。最後顯示隻有在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
           
  1. 在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)
           

繼續閱讀