從 v1.4.0 升級到 v1.4.1
一般資訊
每當有可供升級的新 Harvester 版本時,Dashboard 畫面上就會出現 Upgrade 按鈕。如需更多資訊,請參閱開始升級。
對於離線環境,請參閱準備離線升級。
在開始升級之前,請檢查每個節點上作業系統映像檔的磁碟使用情況。要執行此操作,請透過 SSH 存取節點並執行命令 du -sh /run/initramfs/cos-state/cOS/*。
範例:
# du -sh /run/initramfs/cos-state/cOS/*
1.7G /run/initramfs/cos-state/cOS/active.img
3.1G /run/initramfs/cos-state/cOS/passive.img
如果 passive.img(代表先前安裝的 Harvester v1.4.0 映像檔)消耗 3.1G 磁碟空間,請使用 root 帳戶執行以下命令:
# mount -o remount,rw /run/initramfs/cos-state
# fallocate --dig-holes /run/initramfs/cos-state/cOS/passive.img
# mount -o remount,ro /run/initramfs/cos-state
passive.img 會轉換為稀疏檔案,應該只消耗 1.7G 磁碟空間(與 active.img 相同)。這確保每個節點有足夠的可用空間,防止升級過程卡在「Waiting Reboot」狀態。
在 Rancher v2.10.1 上更新 Harvester UI Extension
要在 Rancher v2.10.1 上匯入 Harvester v1.4.1 叢集,您必須使用 Rancher UI extension for Harvester 的 v1.0.3 版本。
-
在 Rancher UI 上,前往 local > Apps > Repositories。
-
找到名為 harvester 的儲存庫,然後選擇 ⋮ > Refresh。 此儲存庫具有以下屬性:
- URL:https://github.com/harvester/harvester-ui-extension
- Branch:gh-pages
-
前往 Extensions 畫面。
-
找到名為 Harvester 的擴充功能,然後點擊 Update。
-
選擇版本 1.0.3,然後點擊 Update。
-
等待一段時間讓擴充功能更新,然後重新整理畫面。
擴充功 能更新後,Rancher UI 會顯示錯誤訊息。當您重新整理畫面時,錯誤訊息會消失。
此問題存在於 Rancher v2.10.0 和 v2.10.1 中,將在 v2.10.2 中修復。
已知問題
1. 升級卡在「Pre-drained」狀態
升級過程可能會卡在「Pre-drained」狀態。Kubernetes 應該清空節點上的工作負載,但某些因素可能會導致過程停滯。
一個可能的原因是與 Longhorn Instance Manager 的孤立引擎相關的程序。要確定這是否適用於您的情況,請執行以下步驟:
-
檢查卡住節點上
instance-managerPod 的名稱。範例:
卡住的節點是
harvester-node-1,Instance Manager Pod 的名稱是instance-manager-d80e13f520e7b952f4b7593fc1883e2a。$ kubectl get pods -n longhorn-system --field-selector spec.nodeName=harvester-node-1 | grep instance-manager
instance-manager-d80e13f520e7b952f4b7593fc1883e2a 1/1 Running 0 3d8h -
檢查 Longhorn Manager 日誌以獲取資訊訊息。
範例:
$ kubectl -n longhorn-system logs daemonsets/longhorn-manager
...
time="2025-01-14T00:00:01Z" level=info msg="Node instance-manager-d80e13f520e7b952f4b7593fc1883e2a is marked unschedulable but removing harvester-node-1 PDB is blocked: some volumes are still attached InstanceEngines count 1 pvc-9ae0e9a5-a630-4f0c-98cc-b14893c74f9e-e-0" func="controller.(*InstanceManagerController).syncInstanceManagerPDB" file="instance_manager_controller.go:823" controller=longhorn-instance-manager node=harvester-node-1instance-managerPod 無法被清空是因為引擎pvc-9ae0e9a5-a630-4f0c-98cc-b14893c74f9e-e-0。 -
檢查引擎是否仍在卡住的節點上執行。
範例:
$ kubectl -n longhorn-system get engines.longhorn.io pvc-9ae0e9a5-a630-4f0c-98cc-b14893c74f9e-e-0 -o jsonpath='{"Current state: "}{.status.currentState}{"\nNode ID: "}{.spec.nodeID}{"\n"}'
Current state: stopped
Node ID:如果輸出顯示引擎未執行或甚至未找到引擎,則問題可能存在。
-
檢查所有卷是否健康。
kubectl get volumes -n longhorn-system -o yaml | yq '.items[] | select(.status.state == "attached")| .status.robustness'所有卷必須標記為
healthy。如果不是這種情況,請協助報告問題。 -
刪除
instance-managerPod 的 PodDisruptionBudget(PDB)。範例:
kubectl delete pdb instance-manager-d80e13f520e7b952f4b7593fc1883e2a -n longhorn-system
2. 使用非 harvester-longhorn 的預設 StorageClass 升級
Harvester 為 harvester-longhorn 新增註釋 storageclass.kubernetes.io/is-default-class: "true",這是原始的預設 StorageClass。當您將 harvester-longhorn 替換為另一個 StorageClass 時,會發生以下情況:
-
Harvester ManagedChart 顯示錯誤訊息
cannot patch "harvester-longhorn" with kind StorageClass: admission webhook "validator.harvesterhci.io" denied the request: default storage class %!s(MISSING) already exists, please reset it first。 -
Webhook 拒絕升級請求。
您可以執行以下任一解決方法:
-
將
harvester-longhorn設定 為預設 StorageClass。 -
將
spec.values.storageClass.defaultStorageClass: false新增到harvesterManagedChart。kubectl edit managedchart harvester -n fleet-local -
將
timeoutSeconds: 600新增到 Harvester ManagedChart spec。kubectl edit managedchart harvester -n fleet-local
相關 issue:#7375
3. 升級卡在「Waiting Reboot」狀態
在節點上安裝 Harvester v1.4.1 映像檔並啟動重新啟動後,升級過程可能會卡在「Waiting Reboot」狀態。此時,升級控制器觀察 Harvester v1.4.1 作業系統是否正在執行。
如果 Harvester v1.4.1 映像檔(以下稱為 active.img)因任何原因無法啟動,節點會自動以回退模式重新啟動並啟動先前安裝的 Harvester v1.4.0 映像檔(以下稱為 passive.img)。升級控制器無法偵測到預期的作業系統,因此升級會保持卡住狀態,直到管理員修復 active.img 的問題。
active.img 可能會因升級期間 COS_STATE 分割區磁碟空間不足而損壞且無法啟動。如果 Harvester v1.4.0 最初安裝在節點上且系統配置為使用單獨的資料磁碟,就會發生這種情況。在以下情況下不會發生此問題:
- 系統具有作業系統和資料共用的單個磁碟。
- 最初安裝了較早的 Harvester 版本,然後升級到 v1.4.0。
要檢查問題是否存在於您的環境中,請執行以下步驟:
-
透過 SSH 存取節點並使用 root 帳戶登入。
-
執行命令
cat /proc/cmdline和head -n1 /etc/harvester-release.yaml。範例:
# cat /proc/cmdline
BOOT_IMAGE=(loop0)/boot/vmlinuz console=tty1 root=LABEL=COS_STATE cos-img/filename=/cOS/passive.img panic=0 net.ifnames=1 rd.cos.oemlabel=COS_OEM rd.cos.mount=LABEL=COS_OEM:/oem rd.cos.mount=LABEL=COS_PERSISTENT:/usr/local rd.cos.oemtimeout=120 audit=1 audit_backlog_limit=8192 intel_iommu=on amd_iommu=on iommu=pt multipath=off upgrade_failure
# head -n1 /etc/harvester-release.yaml
harvester: v1.4.0輸出中出現
cos-img/filename=/cOS/passive.img和upgrade_failure表示系統以回退模式啟動。/etc/harvester-release.yaml中的 Harvester 版本確認系統目前使用 v1.4.0 映像檔。 -
執行命令
fsck.ext2 -nf /run/initramfs/cos-state/cOS/active.img檢查active.img是否損壞。範例:
# fsck.ext2 -nf /run/initramfs/cos-state/cOS/active.img
e2fsck 1.46.4 (18-Aug-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
[...a list of various different errors may appear here...]
e2fsck: aborted
COS_ACTIVE: ********** WARNING: Filesystem still has errors ********** -
執行命令
lsblk -o NAME,LABEL,SIZE檢查分割區大小。範例:
# lsblk -o NAME,LABEL,SIZE
NAME LABEL SIZE
loop0 COS_ACTIVE 3G
sr0 1024M
vda 250G
├─vda1 COS_GRUB 64M
├─vda2 COS_OEM 64M
├─vda3 COS_RECOVERY 4G
├─vda4 COS_STATE 8G
└─vda5 COS_PERSISTENT 237.9G
vdb HARV_LH_DEFAULT 128G範例中的輸出顯示 COS_STATE 分割區大小為 8G。在這種特定情況下,涉及升級嘗試失敗和
active.img損壞,分割區可能沒有足夠的可用空間以使升級成功。
要修復問題,請執行以下步驟:
-
如果您的叢集有兩個或更多節點,請透過 SSH 存取其餘節點並檢查
active.img和passive.img的磁碟使用情況。# du -sh /run/initramfs/cos-state/cOS/*
1.7G /run/initramfs/cos-state/cOS/active.img
3.1G /run/initramfs/cos-state/cOS/passive.img如果
passive.img消耗 3.1G 磁碟空間,請使用 root 帳戶執行以下命令:# mount -o remount,rw /run/initramfs/cos-state
# fallocate --dig-holes /run/initramfs/cos-state/cOS/passive.img
# mount -o remount,ro /run/initramfs/cos-statepassive.img會轉換為稀疏檔案,應該只消耗 1.7G 磁碟空間(與active.img相同)。這確保其他節點有足夠的可用空間,防止升級過程再次卡住。 -
透過 SSH 存取卡住的節點,然後使用 root 帳戶執行以下命令:
# mount -o remount,rw /run/initramfs/cos-state
# cp /run/initramfs/cos-state/cOS/passive.img \
/run/initramfs/cos-state/cOS/active.img
# tune2fs -L COS_ACTIVE /run/initramfs/cos-state/cOS/active.img
# mount -o remount,ro /run/initramfs/cos-state現有的(乾淨的)
passive.img會複製到損壞的active.img上,並正確設定標籤。 -
重新啟動卡住的節點,然後在 GRUB 啟動畫面上選擇第一 個項目(「Harvester v1.4.1」)。
GRUB 啟動畫面最初預設顯示「Harvester v1.4.1 (fallback)」。儘管顯示版本,系統會啟動到 Harvester v1.4.0。
-
將 Harvester v1.4.1 ISO 中的
rootfs.squashfs複製到卡住節點上的方便位置。ISO 可以掛載在卡住的節點或另一個系統上。您可以使用
scp命令複製檔案。 -
透過 SSH 存取卡住的節點,然後使用 root 帳戶執行以下命令:
# mkdir /tmp/manual-os-upgrade
# mkdir /tmp/manual-os-upgrade/config
# mkdir /tmp/manual-os-upgrade/rootfs
# mount -o loop rootfs.squashfs /tmp/manual-os-upgrade/rootfs
# cat > /tmp/manual-os-upgrade/config/config.yaml <<EOF
upgrade:
system:
size: 3072
EOF
# elemental upgrade \
--logfile /tmp/manual-os-upgrade/upgrade.log \
--directory /tmp/manual-os-upgrade/rootfs \
--config-dir /tmp/manual-os-upgrade/config \
--debug備註您必須將第四行中的範例路徑替換為複製的
rootfs.squashfs的實際路徑。會根據 Harvester v1.4.1 ISO 中的 root 映像檔產生新的(乾淨的)
active.img。如果發生任何錯誤,請儲存
/tmp/manual-os-upgrade/upgrade.log的副本。 -
執行以下命令:
# umount /tmp/manual-os-upgrade/rootfs
# reboot節點應該成功啟動到 Harvester v1.4.1,升級應該按預期進行。
4. 點擊「Dismiss it」按鈕後升級意外重新啟動
當您使用 Rancher 升級 Harvester 時,Rancher UI 會顯示一個帶有標記為「Dismiss it」按鈕的對話框。點擊此按鈕可能會導致以下問題:
harvesterhci.io/v1beta1/upgradeCR 的status部分被清除,導致丟失所有關於升級的重要資訊。- 升級過程意外重新啟動。
此問題影響使用 v1.0.2、v1.0.3 和 v1.0.4 的 Harvester UI Extension 的 Rancher v2.10.x。所有 Harvester UI 版本不受影響。此問題將在 Harvester UI Extension v1.0.5 和 v1.5.0 中修復。
要避免此問題,請執行以下任一操作:
- 使用 Harvester UI 升級 Harvester。在 Harvester UI 上點擊「Dismiss it」按鈕不會導致意外行為。
- 不要點擊 Rancher UI 上的按鈕,而是對叢集執行以下命令:
kubectl -n harvester-system label upgrades -l harvesterhci.io/latestUpgrade=true harvesterhci.io/read-message=true
相關 issue:#7791
5. 使用可遷移 RWX 卷的虛擬機意外重新啟動
Longhorn 問題導致使用可遷移 RWX 卷的虛擬機在 CSI 外掛 Pod 重新啟動時意外重新啟動。此問題影響 Harvester v1.4.x、v1.5.0 和 v1.5.1。
解決方法是在開始升級之前在 Longhorn UI 上停用設定 Automatically Delete Workload Pod When The Volume Is Detached Unexpectedly。升級完成後,您必須再次啟用該設定。
此問題將在 Longhorn v1.8.3、v1.9.1 及更高版本中修復。Harvester v1.6.0 將包含 Longhorn v1.9.1。