跳至主要内容

從 v1.4.2/v1.4.3 升級到 v1.5.0

一般資訊​

每當有可供升級的新 Harvester 版本時,Dashboard 畫面上就會出現 Upgrade 按鈕。如需更多資訊,請參閱開始升級。

您可以直接從 v1.4.2 升級到 v1.5.0,因為 Harvester 允許底層元件最多升級一個次要版本。Harvester v1.4.2 和 v1.4.3 使用相同的 RKE2 次要版本(v1.31),而 Harvester v1.5.0 使用下一個次要版本(v1.32)。

有關在離線環境中升級 Harvester 的資訊,請參閱準備離線升級。

在 Rancher v2.11.0 上更新 Harvester UI Extension​

您必須使用 Harvester UI Extension 的 v1.5.0 版本才能在 Rancher v2.11.0 上匯入 Harvester v1.5.0 叢集。

  1. 在 Rancher UI 上,前往 local > Apps > Repositories。

  2. 找到名為 harvester 的儲存庫,然後選擇 ⋮ > Refresh。

  3. 前往 Extensions 畫面。

  4. 找到名為 Harvester 的擴充功能,然後點擊 Update。

  5. 選擇版本 1.5.0,然後點擊 Update。

  6. 等待一段時間讓擴充功能更新,然後重新整理畫面。

已知問題​

1. 升級期間管理 URL 狀態為「NotReady」​

在升級過程中,某些節點上的 Harvester 控制台可能會顯示 Status: NotReady。

升級到 v1.5.0 完成後會顯示正確的狀態。

相關 issue:#7963

2. 離線升級因 Fluentd 和 Fluent Bit Pod 的 ImagePullBackOff 錯誤而卡住​

升級可能會在過程的一開始就卡住,如 Harvester UI 的 Upgrade 對話框中顯示的 0% 進度和標記為 Pending 的項目所示。

具體來說,Fluentd 和 Fluent Bit Pod 可能會卡在 ImagePullBackOff 狀態。要檢查 Pod 的狀態,請執行以下命令:

$ kubectl -n harvester-system get upgrades -l harvesterhci.io/latestUpgrade=true
NAME                 AGE
hvst-upgrade-x2hz8   7m14s

$ kubectl -n harvester-system get upgradelogs -l harvesterhci.io/upgrade=hvst-upgrade-x2hz8
NAME                            UPGRADE
hvst-upgrade-x2hz8-upgradelog   hvst-upgrade-x2hz8

$ kubectl -n harvester-system get pods -l harvesterhci.io/upgradeLog=hvst-upgrade-x2hz8-upgradelog
NAME                                                        READY   STATUS             RESTARTS   AGE
hvst-upgrade-x2hz8-upgradelog-downloader-6cdb864dd9-6bw98   1/1     Running            0          7m7s
hvst-upgrade-x2hz8-upgradelog-infra-fluentbit-2nq7q         0/1     ImagePullBackOff   0          7m42s
hvst-upgrade-x2hz8-upgradelog-infra-fluentbit-697wf         0/1     ImagePullBackOff   0          7m42s
hvst-upgrade-x2hz8-upgradelog-infra-fluentbit-kd8kl         0/1     ImagePullBackOff   0          7m42s
hvst-upgrade-x2hz8-upgradelog-infra-fluentd-0               0/2     ImagePullBackOff   0          7m42s

這是因為以下容器映像檔既未在叢集節點中預載,也未從網際網路拉取:

  • ghcr.io/kube-logging/fluentd:v1.15-ruby3
  • ghcr.io/kube-logging/config-reloader:v0.0.5
  • fluent/fluent-bit:2.1.8

要修復此問題,請執行以下任一操作:

  • 更新 Logging CR 以使用已在叢集節點中預載的映像檔。要執行此操作,請對叢集執行以下命令:

    # Get the Logging CR names
    OPERATOR_LOGGING_NAME=$(kubectl get loggings -l app.kubernetes.io/name=rancher-logging -o jsonpath="{.items[0].metadata.name}")
    INFRA_LOGGING_NAME=$(kubectl get loggings -l harvesterhci.io/upgradeLogComponent=infra -o jsonpath="{.items[0].metadata.name}")

    # Gather image info from operator's Logging CR
    FLUENTD_IMAGE_REPO=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.image.repository}")
    FLUENTD_IMAGE_TAG=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.image.tag}")

    FLUENTBIT_IMAGE_REPO=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentbit.image.repository}")
    FLUENTBIT_IMAGE_TAG=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentbit.image.tag}")

    CONFIG_RELOADER_IMAGE_REPO=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.configReloaderImage.repository}")
    CONFIG_RELOADER_IMAGE_TAG=$(kubectl get loggings $OPERATOR_LOGGING_NAME -o jsonpath="{.spec.fluentd.configReloaderImage.tag}")

    # Patch the Logging CR
    kubectl patch logging $INFRA_LOGGING_NAME --type=json -p="[{\"op\":\"replace\",\"path\":\"/spec/fluentbit/image\",\"value\":{\"repository\":\"$FLUENTBIT_IMAGE_REPO\",\"tag\":\"$FLUENTBIT_IMAGE_TAG\"}}]"
    kubectl patch logging $INFRA_LOGGING_NAME --type=json -p="[{\"op\":\"replace\",\"path\":\"/spec/fluentd/image\",\"value\":{\"repository\":\"$FLUENTD_IMAGE_REPO\",\"tag\":\"$FLUENTD_IMAGE_TAG\"}}]"
    kubectl patch logging $INFRA_LOGGING_NAME --type=json -p="[{\"op\":\"replace\",\"path\":\"/spec/fluentd/configReloaderImage\",\"value\":{\"repository\":\"$CONFIG_RELOADER_IMAGE_REPO\",\"tag\":\"$CONFIG_RELOADER_IMAGE_TAG\"}}]"

    Logging CR 更新後,Fluentd 和 Fluent Bit Pod 的狀態應該會立即變為 Running,升級過程應該會繼續。如果 Fluentd Pod 仍處於 ImagePullBackOff 狀態,請嘗試使用以下命令刪除它以強制重新啟動:

    UPGRADE_NAME=$(kubectl -n harvester-system get upgrades -l harvesterhci.io/latestUpgrade=true -o jsonpath='{.items[0].metadata.name}')
    UPGRADELOG_NAME=$(kubectl -n harvester-system get upgradelogs -l harvesterhci.io/upgrade=$UPGRADE_NAME -o jsonpath='{.items[0].metadata.name}')

    kubectl -n harvester-system delete pods -l harvesterhci.io/upgradeLog=$UPGRADELOG_NAME,harvesterhci.io/upgradeLogComponent=aggregator

  • 在可以存取網際網路的電腦上,拉取所需的容器映像檔,然後將它們匯出到 TAR 檔案。接下來,將 TAR 檔案傳輸到叢集節點,然後透過在每個節點上執行以下命令匯入映像檔:

    # Pull down the three container images
    docker pull ghcr.io/kube-logging/fluentd:v1.15-ruby3
    docker pull ghcr.io/kube-logging/config-reloader:v0.0.5
    docker pull fluent/fluent-bit:2.1.8

    # Export the images to a tar file
    docker save \
      ghcr.io/kube-logging/fluentd:v1.15-ruby3 \
      ghcr.io/kube-logging/config-reloader:v0.0.5 \
      fluent/fluent-bit:2.1.8 > upgradelog-images.tar

    # After transferring the tar file to the cluster nodes, import the images (need to be run on each node)
    ctr -n k8s.io images import upgradelog-images.tar

    映像檔預載後,升級過程應該會繼續。

  • (不建議)在停用日誌記錄的情況下重新啟動升級過程。確保未選中 Upgrade 對話框中的 Enable Logging 核取方塊。

相關 issue:#7955

3. 升級卡在等待 mcc-harvester Bundle CR​

當您從舊版 Harvester(例如 v1.0.x、v1.1.x 和 v1.2.x)升級時,升級過程可能會卡在等待 mcc-harvester bundle CR 變為就緒狀態。

> kubectl get bundles -n fleet-local
NAME                                          BUNDLEDEPLOYMENTS-READY   STATUS
mcc-harvester                                 0/1                       Modified(1) [Cluster fleet-local/local]; kubevirt.kubevirt.io harvester-system/kubevirt modified {"spec":{"configuration":{"vmStateStorageClass":"vmstate-persistence"}}}

根本原因是未套用最新的 dependency_charts CRD,這是因為 Helm 不為 Harvester 管理 CRD。要讓升級繼續,請執行以下腳本:

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/kubevirt-operator/crds/crd-kubevirt.yaml

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/csi-snapshotter/crds/volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/csi-snapshotter/crds/volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/csi-snapshotter/crds/volumesnapshots.yaml

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/whereabouts/crds/whereabouts.cni.cncf.io_ippools.yaml
kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/whereabouts/crds/whereabouts.cni.cncf.io_overlappingrangeipreservations.yaml

五分鐘後,檢查 bundle.fleet.cattle.io/v1alpha1 的 mcc-harvester bundle CR 中的狀態。如果仍顯示相同的錯誤,您必須使用以下腳本重新同步 bundle CR:

#!/bin/bash

patch_fleet_bundle() {
  local bundleName=$1
  local generation=$(kubectl get -n fleet-local bundle ${bundleName} -o jsonpath='{.spec.forceSyncGeneration}')
  local new_generation=$((generation+1))
  patch_manifest="$(mktemp)"
  cat > "$patch_manifest" <<EOF
{
  "spec": {
    "forceSyncGeneration": $new_generation
  }
}
EOF
  echo "patch bundle to new generation: $new_generation"
  kubectl patch -n fleet-local bundle ${bundleName}  --type=merge --patch-file $patch_manifest
  rm -f $patch_manifest
}

for bundle in mcc-harvester
do
  patch_fleet_bundle ${bundle}
done

您還必須確保 cdi CRD 存在。

> kubectl get bundle -n fleet-local
NAMESPACE     NAME                                          BUNDLEDEPLOYMENTS-READY   STATUS
fleet-local   mcc-harvester                                 0/1                       Modified(1) [Cluster fleet-local/local]; cdi.cdi.kubevirt.io cdi missing

如果 cdi CRD 存在,請執行 patch_fleet_bundle 腳本以重新同步 mcc-harvester bundle CR。否則,請執行以下腳本以建立 cdi CRD:

kubectl apply -f https://raw.githubusercontent.com/harvester/harvester/refs/tags/v1.5.0/deploy/charts/harvester/dependency_charts/cdi/crds/cdi.yaml

相關 issue:#8163

4. 使用可遷移 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。

相關 issue:#8534 和 #11158