Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

升級叢集

安裝新版 bmctl 時，您可以升級以舊版建立的現有叢集。將叢集升級至最新版 Google Distributed Cloud，可為叢集帶來更多功能和修正項目。並確保叢集持續受到支援。您可以使用 bmctl upgrade cluster 指令或 kubectl，升級管理員、混合、獨立或使用者叢集。

如要進一步瞭解升級程序和版本管理規則，請參閱「叢集升級的生命週期和階段」。

本頁面適用於管理基礎技術基礎架構生命週期的管理員、架構師和操作員。如要進一步瞭解 Google Cloud 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

規劃升級

本節提供升級叢集前應考量的資訊和相關連結。如要進一步瞭解升級作業，包括叢集和節點集區的版本管理規則，請參閱「叢集升級的生命週期和階段」。

最佳做法

如要瞭解如何準備升級叢集，請參閱「Google Distributed Cloud 叢集升級的最佳做法」。

升級預檢

系統會在叢集升級期間執行預檢，驗證叢集狀態和節點健康狀態。如果預檢失敗，叢集升級作業就不會繼續。如要進一步瞭解預檢，請參閱「瞭解預檢」。

執行升級作業前，您可以先執行預檢，確認叢集是否已準備好升級。詳情請參閱「升級預檢」。

已知問題

如要瞭解叢集升級相關的潛在問題，請參閱「Google Distributed Cloud for bare metal 已知問題」，並選取「Upgrades and updates」(升級和更新) 問題類別。

設定升級選項

開始升級叢集前，您可以設定下列升級選項，控管升級程序的運作方式：

選擇性升級 worker 節點集區：與叢集其他部分分開，單獨升級特定 worker 節點集區。
平行升級：設定升級程序，同時升級多個節點群組或節點集區。

這些選項可降低重要應用程式和服務中斷的風險，並大幅縮短整體升級時間。如果大型叢集有多個節點和節點集區，且執行重要工作負載，這些選項就特別實用。如要進一步瞭解這些選項的功能和使用方式，請參閱下列各節。

略過升級

從 1.33 版開始，Google Distributed Cloud 支援所有叢集類型的略過升級功能，可讓您在單一作業中，將叢集升級至比目前版本高兩個子版本的目標版本 (1.33 以上版本)。舉例來說，您可以透過單一作業，直接從 1.N.X 版升級至 1.N+2.Z 版。

下表列出這項功能在各版本中的推出階段，其中版本是指升級目標版本：

1.34 以上版本：正式發布
1.33：預先發布版
1.32 以下版本：不適用

與遞增升級相比，略過升級可讓您更快取得最新功能和修正。此外，跳過升級也能延長必要升級作業之間的間隔時間，減少潛在的中斷情形。您可以將略過升級與其他升級選項搭配使用，例如選擇性 worker 節點集區升級和平行升級。

在略過升級期間，系統會將叢集升級至中繼子版本，然後立即升級至目標版本。如果您使用登錄檔鏡像，這個中繼版本會產生影響。詳情請參閱「登錄檔鏡像的其他規定」。

略過叢集升級功能目前為 1.33 版的預先發布版。建議您不要在正式版叢集上，執行從 1.31 到 1.33 的略過升級。

略過升級必要條件

執行略過升級的程序與執行依序升級相同，但有一些額外的必要條件：

確認叢集狀態符合叢集和節點集區版本規則，可略過升級：
- 開始對管理員或混合式叢集進行跨版本升級前，請確認所有代管使用者叢集的子版本，都與管理叢集相同。
- 開始略過使用者叢集的升級作業前，請確認叢集符合下列條件：
  - 相關聯的管理員或混合叢集比使用者叢集高兩個子版本。
  - 使用者叢集的所有 worker 節點集區，都與使用者叢集位於相同的子版本。

將 preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade 註解新增至叢集設定檔：

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/skip-minor-version-cluster-upgrade: "enable"
spec:
  type: user
  profile: default
  anthosBareMetalVersion:   1.36.200-gke.118
  ...

將叢集設定檔中的 anthosBareMetalVersion 更新為略過升級的升級目標版本。

與依序升級一樣，您可以使用 bmctl upgrade cluster 或 kubectl apply 啟動略過升級。

登錄檔鏡像的其他規定

如果您從登錄檔鏡像提取容器映像檔來升級叢集，登錄檔鏡像必須同時具備目標版本和略過升級的中繼版本映像檔。

如要準備登錄檔鏡像，以便略過升級，請按照下列步驟操作：

使用與略過升級目標版本相對應的 bmctl 版本，找出略過升級的中繼版本：
```
bmctl upgrade intermediate-version
```
指令回應包含系統在略過升級期間，做為中繼版本的特定 Google Distributed Cloud 修補程式版本。舉例來說，如果是 bmctl 1.33.0-gke.799 版，回應會如下所示：
```
1.32.200-gke.104
```
下載目標版本和中繼版本的映像檔套件。

詳情請參閱「下載圖片套件」。
在開始略過升級之前，請將目標版本和中繼版本的映像檔套件推送至登錄檔鏡像。

如要託管目標和中繼版本的容器映像檔，登錄檔鏡像需要額外的磁碟空間。

與依序升級一樣，您可以使用 bmctl upgrade cluster 或 kubectl apply 啟動略過升級。

選擇性升級 worker 節點集區

根據預設，叢集升級作業會升級叢集中的每個節點和節點集區。叢集升級作業會導致每個節點都遭到清空，且所有相關聯的 Pod 都會重新啟動及重新排程，因此可能會造成服務中斷，且相當耗時。本節說明如何納入或排除特定 worker 節點集區，以便升級叢集，盡可能減少工作負載中斷。管理員叢集不允許 worker 節點集區，因此這項功能僅適用於使用者、混合和獨立叢集。

在下列情況下，您可以使用選擇性節點集區升級：

如要套用安全性修正，而不中斷工作負載：您可以只升級控制層節點 (和負載平衡器節點)，套用 Kubernetes 漏洞修正，而不中斷 worker 節點集區。
在升級所有 worker 節點前，確認升級後的 worker 節點子集運作正常：您可以選擇性升級 worker 節點集區，確保工作負載在升級後的節點集區上正常運作，再升級其他節點集區。
縮短維護期間：升級大型叢集可能相當耗時，且難以準確預測升級完成的時間。叢集升級時間與升級的節點數量成正比。排除節點集區可減少升級的節點數量，進而縮短升級時間。您需要多次升級，但較短且更可預測的維護期間可能有助於排程。

兩個子版本節點集區版本偏差

如果是 1.28 以上版本的叢集，worker 節點集區版本最多可比叢集 (控制層) 版本低兩個子版本。有了 n-2 版本偏斜支援，您也可以在將 worker 節點集區從叢集前兩個子版本升級至與叢集相同的子版本時，略過子版本。

worker 節點集區支援 n-2 版本偏移，讓您能更靈活地規劃機群升級。

舉例來說，如果您有 1.36 版叢集，可以選取 1.36、1.35 和 1.34 版的 worker 節點集區。

升級叢集前，所有 worker 節點集區的版本都必須與目前的叢集版本和目標叢集版本相容。

舉例來說，如果叢集版本為 1.29，worker 節點集區版本為 1.29、1.28 和 1.16，您必須先將 1.16 版節點集區升級至 1.28 或 1.29 版，才能將叢集升級至 1.30 版。

如需更多資訊，包括特定叢集版本支援的 worker 節點集區版本清單 (適用於 1.29 以下版本)，請參閱「節點集區版本管理規則」。

1.30 以上

在 1.30 版中，所有叢集類型的 worker 節點集區都正式支援 n-2 版本偏誤。1.30 版叢集預設會啟用這項功能。

如果節點集區版本與叢集版本相同或較低，則 1.28 和 1.29 子版本中任何修補程式版本的節點集區，都可以升級至 1.30 的任何修補程式版本。

1.29

在 1.29 版中，所有叢集類型的 worker 節點集區都已正式發布 n-2 版本偏誤支援。1.29 版叢集預設會啟用這項功能。

這項功能從公開測試版轉換為正式發布版時，混合式叢集在下列情況下仍需要預先發布版註解。如果您的混合叢集版本為 1.28.x，且 worker 節點集區版本為 1.16.y，則必須先將 preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable 註解新增至叢集，再升級至 1.29.z 版：

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

1.28 版預先發布版支援 worker 節點集區的 n-2 版本偏差。如要啟用這項預先發布版功能，請在叢集設定檔中新增 preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable 註解：

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

如未啟用這項預先發布版功能，worker 節點集區與叢集之間的最大版本差異為一個子版本。

如要進一步瞭解選擇性升級 worker 節點集區的版本管理規則，請參閱「叢集升級的生命週期和階段」中的「節點集區版本管理規則」。

升級叢集控制層和所選節點集區

如要在初始叢集升級期間，選擇性升級 worker 節點集區，請按照下列步驟操作：

如要將 worker 節點集區納入叢集升級作業，請對 NodePool 規格進行下列任一變更：
- 將 NodePool 規格中的 anthosBareMetalVersion 設為叢集目標升級版本。
- 從 NodePool 規格中省略 anthosBareMetalVersion 欄位，或將其設為空白字串。根據預設，worker 節點集區會納入叢集升級。
如要排除 worker 節點集區，請將 anthosBareMetalVersion 設為叢集的目前版本 (升級前)：
按照「開始升級叢集」一節的說明繼續升級。

叢集升級作業會升級下列節點：
- 叢集控制層節點。
- 負載平衡器節點集區 (如果叢集有使用) (spec.loadBalancer.nodePoolSpec)。根據預設，負載平衡器節點可以執行一般工作負載。您無法選擇性升級負載平衡器節點集區，因為它一律會包含在初始叢集升級中。
- 未排除在升級作業之外的 worker 節點集區。

舉例來說，假設叢集版本為 1.35.0，且有兩個 worker 節點集區：wpool01 和 wpool02。此外，假設您想將控制層和 wpool01 升級至 1.36.200-gke.118，但希望 wpool02 保持在 1.35.0 版。

以下叢集設定檔摘錄說明如何修改叢集設定，以支援這項部分升級：

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

將節點集區升級至目前的叢集版本

如果您在叢集升級時排除節點集區，可以執行叢集升級，將這些節點集區升級至目標叢集版本。如果 worker 節點集區已從叢集升級作業中排除，其 NodePool 規格中的 anthosBareMetalVersion 欄位會設為先前的叢集版本 (升級前)。

如要將 worker 節點集區升級至目前的叢集版本，請按照下列步驟操作：

在叢集設定檔中，編輯要升級至目前叢集版本的 worker 節點集區 NodePool 規格。將 anthosBareMetalVersion 設為目前的 (升級後) 叢集版本。

如果選取多個 worker 節點集區進行升級，叢集規格中的 spec.nodePoolUpgradeStrategy.concurrentNodePools 值會決定平行升級的節點集區數量 (如有)。如果不想同時升級 worker 節點集區，請一次選取一個節點集區進行升級。
按照「開始升級叢集」一節的說明繼續升級。

叢集升級作業只會將先前排除的 worker 節點集區 (anthosBareMetalVersion 已設為目前升級後的叢集版本) 升級。

舉例來說，假設您將叢集升級至 1.36.200-gke.118 版，但節點集區 wpool02 仍是升級前的舊叢集版本 1.35.0。工作負載在升級後的節點集區 wpool01 上正常運作，因此您現在也想將 wpool02 升級至目前的叢集版本。如要升級 wpool02，您可以移除 anthosBareMetalVersion 欄位，或將其值設為空字串。

以下叢集設定檔摘錄說明如何修改叢集設定，以支援這項部分升級：

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.36.200-gke.118
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

復原節點集區升級

有許多依附元件 (例如與 kubelet 或外掛程式的相容性) 可能會影響工作負載的效能。如果升級 worker 節點集區後發生問題，可以將節點集區復原至先前的版本。

這項功能在所有支援的叢集版本中，並非處於相同的推出階段：

1.30 以上

1.30 版叢集 (控制層節點為 1.30 版) 的節點集區復原功能已正式發布，且預設為啟用。

1.29

節點集區復原功能目前為預先發布版，適用於 1.29 版叢集 (控制層節點為 1.29 版的叢集)。這項功能目前處於預先發布版階段，您必須在 Cluster 資源中加入下列註解，才能啟用這項功能：

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1.28

如果叢集是 1.28 以下的子版本，則無法使用節點集區復原功能。

如要復原節點集區升級，請按照下列步驟操作：

`bmctl`

使用 bmctl 復原節點集區升級時，請編輯叢集設定檔，並使用 bmctl update 指令套用變更：

在叢集設定檔中，編輯要復原至先前版本的 worker 節點集區 NodePool 規格。將 anthosBareMetalVersion 設為先前的 (升級前) 叢集版本。
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.600-gke.141
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
如果選取多個 worker 節點集區進行復原，叢集規格中的 spec.nodePoolUpgradeStrategy.concurrentNodePools 值會決定平行復原的節點集區數量。如果不想同時復原 worker 節點集區，請一次選取一個節點集區進行復原，或更新 nodePoolUpgradeStrategy 設定。同樣地，NodePool 規格中的 spec.upgradeStrategy.parallelUpgrade.concurrentNodes 值會決定平行復原的節點數量。
使用 bmctl update 套用 NodePool 規格變更：
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
更改下列內容：
- CLUSTER_NAME：要更新的叢集名稱。
- ADMIN_KUBECONFIG：管理叢集 (管理員、混合或獨立) 的 kubeconfig 檔案路徑。
系統會自動開始復原。bmctl update cluster 指令會立即結束，但復原作業會繼續進行。復原期間，請勿對叢集執行任何其他作業。
復原作業執行時，Google Distributed Cloud 會對每個節點執行下列活動：
- 將節點切換至維護模式。
- 在節點上執行重設工作，將節點恢復為乾淨狀態。
- 對節點執行機器預檢。
- 在節點上執行 machine-init 工作，以目標復原 (升級前) 版本重新安裝節點。
- 將節點從維護模式中移除。
復原成功後，NodePool 資源中的 nodePool.status.anthosBareMetalVersion 值會設為目標復原版本。

編輯叢集設定檔時，請勿交替使用 bmctl update 和 kubectl apply -f。如果交替使用這些指令，叢集規格標頭填入的內容可能會遭到意外移除。舉例來說，您可以使用 bmctl update 更新叢集設定檔，設定登錄檔鏡像。協調後，叢集會填入 spec.nodeConfig.registryMirrors。

如果之後嘗試使用 kubectl apply -f 指令，透過叢集設定變更叢集，則協調器在叢集上填入的 spec.nodeConfig.registryMirrors 會遭到移除。之所以會發生這種情況，是因為叢集設定規格中沒有這項設定，但叢集中有。

`kubectl`

您可以使用 kubectl 直接編輯 NodePool 資源，復原節點集區升級作業：

如要復原 worker 節點集區，請開啟 NodePool 資源進行編輯：
```
kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
```
更改下列內容：
- NODE_POOL_NAME：要復原的節點集區名稱。
- CLUSTER_NAMESPACE：部署節點集區的命名空間名稱。這是叢集命名空間。
- ADMIN_KUBECONFIG：管理叢集 (管理員、混合或獨立) 的 kubeconfig 檔案路徑。

將 spec.anthosBareMetalVersion 的值變更為先前的版本 (升級前)。

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.600-gke.141
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

在編輯器中儲存並關閉 NodePool 資源。

系統會自動開始復原。復原期間，請勿對叢集執行任何其他作業。
復原作業執行時，Google Distributed Cloud 會對每個節點執行下列活動：
- 將節點切換至維護模式。
- 在節點上執行重設工作，將節點恢復為乾淨狀態。
- 對節點執行機器預檢。
- 在節點上執行 machine-init 工作，以目標復原 (升級前) 版本重新安裝節點。
- 將節點從維護模式中移除。
成功復原後，NodePool 資源中的 nodePool.status.anthosBareMetalVersion 值會設為目標復原版本。

平行升級

在一般的預設叢集升級作業中，每個叢集節點會依序升級。本節說明如何設定叢集和 worker 節點集區，以便在升級叢集時平行升級多個節點。平行升級節點可大幅加快叢集升級速度，尤其是具有數百個節點的叢集。

您可以使用兩種平行升級策略，加快叢集升級速度：

並行節點升級：您可以設定 worker 節點集區，同時升級多個節點。節點的平行升級作業是在 NodePool 規格 (spec.upgradeStrategy.parallelUpgrade) 中設定，且只有 worker 節點集區中的節點可以平行升級。控制層或負載平衡器節點集區中的節點，一次只能升級一個。詳情請參閱「節點升級策略」。
並行節點集區升級：您可以設定叢集，讓多個節點集區平行升級。只有 worker 節點集區可以平行升級。控制層和負載平衡器節點集區只能逐一升級。

節點升級策略

您可以設定 worker 節點集區，讓多個節點同時升級 (concurrentNodes)。您也可以設定最低門檻，指定在整個升級過程中，可執行工作負載的節點數量 (minimumAvailableNodes)。這項設定是在 NodePool 規格中進行。如要進一步瞭解這些欄位，請參閱「叢集設定欄位參考資料」。

節點升級策略僅適用於 worker 節點集區。您無法為控制層或負載平衡器節點集區指定節點升級策略。在叢集升級期間，控制層和負載平衡器節點集區中的節點會依序升級，一次一個。控制層節點集區和負載平衡器節點集區是在叢集規格 (controlPlane.nodePoolSpec.nodes 和 loadBalancer.nodePoolSpec.nodes) 中指定。

設定節點平行升級時，請注意下列限制：

concurrentNodes 的值不得超過節點集區中節點數量的 50%，或固定數量 15，以較小者為準。舉例來說，如果節點集區有 20 個節點，您就無法指定大於 10 的值。如果節點集區有 100 個節點，則可指定的最大值為 15。
如果同時使用 concurrentNodes 和 minimumAvailableNodes，合併值不得超過節點集區中的節點總數。舉例來說，如果節點集區有 20 個節點，且 minimumAvailableNodes 設為 18，則 concurrentNodes 不得超過 2。同樣地，如果 concurrentNodes 設為 10，minimumAvailableNodes 就不能超過 10。

以下範例顯示含有 10 個節點的 worker 節點集區 np1。升級時，節點會一次升級 5 個，且至少須有 4 個節點保持可用狀態，升級作業才能繼續進行：

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

節點集區升級策略

您可以設定叢集，讓多個 worker 節點集區平行升級。叢集規格中的 nodePoolUpgradeStrategy.concurrentNodePools 布林值欄位，會指定是否要同時升級叢集的所有 worker 節點集區。根據預設 (1)，節點集區會依序升級。如果將 concurrentNodePools 設為 0，叢集中的每個 worker 節點集區都會同時升級。

控制層和負載平衡節點集區不受這項設定影響。這些節點集區一律會依序升級，一次一個。控制層節點集區和負載平衡器節點集區是在叢集規格 (controlPlane.nodePoolSpec.nodes 和 loadBalancer.nodePoolSpec.nodes) 中指定。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

如何執行平行升級

本節說明如何設定叢集和 worker 節點集區，以便進行平行升級。

如要平行升級 worker 節點集區和當中的節點，請執行下列操作：

在 NodePool 規格中新增 upgradeStrategy 區段。

執行叢集更新時，您可以單獨套用這個資訊清單，也可以將其做為叢集設定檔的一部分套用。

範例如下：
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10
```
在本範例中，concurrentNodes 欄位的值為 5，表示 5 個節點會平行升級。minimumAvailableNodes 欄位設為 10，表示在整個升級過程中，至少須有 10 個節點可供工作負載使用。

注意： 您無法為控制層或負載平衡器節點集區指定節點升級策略。

在叢集設定檔的叢集規格中，新增 nodePoolUpgradeStrategy 區段。

---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.36.200-gke.118
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

在這個範例中，concurrentNodePools 欄位設為 0，表示在叢集升級期間，所有 worker 節點集區都會同時升級。節點集區中節點的升級策略，是在 NodePool 規格中定義。

按照前述「升級管理員、獨立、混合或使用者叢集」一節的說明升級叢集。

平行升級預設值

平行升級預設為停用，且與平行升級相關的欄位可變動。您隨時可以移除這些欄位，或將其設為預設值，在後續升級前停用這項功能。

下表列出平行升級欄位及其預設值：

欄位	預設值	意義
`nodePoolUpgradeStrategy.concurrentNodePools` (叢集規格)	`1`	依序升級 worker 節點集區。
`upgradeStrategy.parallelUpgrade.concurrentNodes` (NodePool 規格)	`1`	依序升級節點，一個接一個。
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (NodePool 規格)	`minimumAvailableNodes` 的預設值取決於 `concurrentNodes` 的值。如未指定 `concurrentNodes`，則 `minimumAvailableNodes` 預設為節點集區大小的 2/3。如果指定 `concurrentNodes`，則 `minimumAvailableNodes` 預設為節點集區大小減去 `concurrentNodes`。	達到 `minimumAvailableNodes` 後，升級作業會暫停，直到可用節點數量大於 `minimumAvailableNodes` 才會繼續。

開始升級叢集

本節說明如何升級叢集。

`bmctl`

下載並安裝新版 bmctl 後，您可以升級使用舊版建立的管理員、混合、獨立和使用者叢集。對於特定版本的 bmctl，叢集只能升級至相同版本。

將使用者憑證設為應用程式預設憑證 (ADC)：
```
gcloud auth application-default login
```
按照提示選取要用於 ADC 的 Google 帳戶。詳情請參閱「設定應用程式預設憑證」。
按照「Google Distributed Cloud 下載」中的說明，下載最新版 bmctl。
將叢集設定檔中的 anthosBareMetalVersion 更新為升級目標版本。

升級目標版本必須與下載的 bmctl 檔案版本相符。下列叢集設定檔程式碼片段顯示 anthosBareMetalVersion 欄位已更新為最新版本：
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.36.200-gke.118
```
使用 bmctl upgrade cluster 指令完成升級：
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
更改下列內容：
- CLUSTER_NAME：要升級的叢集名稱。
- ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。
注意： bmctl upgrade 指令只會更新叢集自訂資源中的 anthosBareMetalVersion 值和預先發布版註解。如要修改叢集規格的其他欄位，請使用 bmctl update 指令。詳情請參閱「更新叢集」。
叢集升級作業會執行預檢，驗證叢集狀態和節點健康狀態。如果預檢失敗，叢集升級作業就不會繼續。如需疑難排解資訊，請參閱「排解叢集安裝或升級問題」。

所有叢集元件都成功升級後，叢集升級作業會執行叢集健康狀態檢查。最後一個步驟是確認叢集運作狀況良好。如果叢集未通過所有健康狀態檢查，系統會持續執行檢查，直到通過為止。所有健康狀態檢查都通過後，升級作業即順利完成。

如要進一步瞭解叢集升級的事件順序，請參閱「叢集升級的生命週期和階段」。

`kubectl`

如要使用 kubectl 升級叢集，請按照下列步驟操作：

編輯叢集設定檔，將 anthosBareMetalVersion 設為升級目標版本。
如要啟動升級作業，請執行下列指令：
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
將 CLUSTER_CONFIG_PATH 替換為編輯後的叢集設定檔路徑。

與 bmctl 的升級程序相同，系統會在叢集升級期間執行預檢，驗證叢集狀態和節點健康狀態。如果預檢失敗，叢集升級作業就會停止。如要排解任何失敗問題，請檢查叢集和相關記錄，因為系統不會建立啟動叢集。詳情請參閱「排解叢集安裝或升級問題」。

雖然您不需要最新版本的 bmctl 即可使用 kubectl 升級叢集，但建議您下載最新版本的 bmctl。您需要 bmctl 執行其他工作 (例如健康狀態檢查和備份)，確保叢集保持良好運作狀態。

暫停及繼續升級

您可以使用升級暫停和恢復功能，在叢集升級完成前暫停升級。叢集升級作業暫停時，系統不會觸發新的 worker 節點升級作業，直到升級作業恢復為止。

這項功能為預先發布版，適用於所有控制層節點皆為 1.28 以上子版本的叢集。如果叢集的所有控制層節點都採用 1.29 以上的子版本，這項功能即正式發布。

您可能基於下列原因而想暫停升級：

升級期間，您發現叢集工作負載有問題，想暫停升級來調查問題
維護期間很短，因此您想在維護期間之間暫停升級

叢集升級作業暫停期間，支援下列作業：

如果在升級作業暫停期間新增節點，系統不會在該節點上執行機器檢查工作，直到升級作業恢復並完成為止。

叢集升級作業暫停期間，不支援下列叢集作業：

如果叢集升級作業暫停，您就無法啟動新的叢集升級作業。

啟用升級暫停和繼續功能

Google Distributed Cloud 1.36

如果叢集的所有控制層節點都採用 1.29 以上子版本，系統預設會啟用升級暫停和繼續功能。

Google Distributed Cloud 1.35

升級暫停和繼續功能目前為預先發布版，您可以在叢集資源中加入註解來啟用。

如要啟用升級暫停和繼續功能，請按照下列步驟操作：

將 preview.baremetal.cluster.gke.io/upgrade-pause-and-resume 註解新增至叢集設定檔：

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume: enable
spec:
...

如要套用變更，請更新叢集：
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
更改下列內容：
- CLUSTER_NAME：要更新的叢集名稱。
- ADMIN_KUBECONFIG：如果是管理員、混合或獨立叢集，請輸入叢集 kubeconfig 檔案的路徑。如果是使用者叢集，請輸入管理員叢集 kubeconfig 檔案的路徑。
nodePoolUpgradeStrategy.pause 欄位可變更。您隨時可以新增及更新這項資訊。

暫停升級

如要暫停叢集升級，請在叢集規格中將 nodePoolUpgradeStrategy.pause 設為 true。

如要暫停進行中的叢集升級作業，請按照下列步驟操作：

將 nodePoolUpgradeStrategy.pause 新增至叢集設定檔，並設為 true：

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...

如果您使用 bmctl 啟動升級，則需要新的終端機視窗來執行下一個步驟。

如要套用變更，請更新叢集：
```
bmctl update CLUSTER_NAME
```
升級作業已暫停。不會觸發新的節點升級作業。
如果您使用 bmctl 啟動升級作業，且打算長時間暫停，請按下 Control+C 鍵退出 bmctl，否則請讓 bmctl 保持執行狀態。

bmctl CLI 不會偵測升級暫停狀態的變更，因此不會自動結束。不過，當您結束 bmctl 時，系統會停止將升級進度記錄到管理員工作站叢集資料夾中的 cluster-upgrade-TIMESTAMP 記錄檔，以及 Cloud Logging。因此，如果只是短暫暫停，建議您讓 bmctl 保持執行狀態。如果在升級作業暫停期間，讓 bmctl 執行過久，最終會逾時。

繼續暫停的升級作業

如要繼續執行已暫停的叢集升級作業，請在叢集規格中將 nodePoolUpgradeStrategy.pause 設為 false，或從規格中移除 nodePoolUpgradeStrategy.pause。

如要繼續執行已暫停的叢集升級作業，請按照下列步驟操作：

將 nodePoolUpgradeStrategy.pause 設為叢集設定檔，並設為 false：

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  ...
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

或者，您也可以移除 pause 欄位，因為預設值為 false。

如要套用變更，請更新叢集：
```
bmctl update CLUSTER_NAME
```
升級作業會從上次中斷的位置繼續執行。

如要查看升級狀態，請先取得 status 中含有 anthosBareMetalVersion 的資源清單：

kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

更改下列內容：

RESOURCE：要取得的資源名稱。Cluster、NodePool 和 BareMetalMachine 資源都包含 anthosBareMetalVersion 狀態資訊。
ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。

以下範例顯示 BareMetalMachine 自訂資源的回應格式。每個 BareMetalMachine 都對應一個叢集節點。

NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2

如要查看 status.anthosBareMetalVersion (資源的目前版本)，請擷取個別資源的詳細資料：

kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

以下範例顯示 IP 位址為 192.0.2.53 的叢集節點 BareMetalMachine 詳細資料：

Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

在本例中，節點採用 Google Distributed Cloud 1.16.2 版。

升級叢集 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

規劃升級

最佳做法

升級預檢

已知問題

設定升級選項

略過升級

略過升級必要條件

登錄檔鏡像的其他規定

選擇性升級 worker 節點集區

兩個子版本節點集區版本偏差

1.30 以上

1.29

1.28

升級叢集控制層和所選節點集區

將節點集區升級至目前的叢集版本

復原節點集區升級

1.30 以上

1.29

1.28

bmctl

kubectl

平行升級

節點升級策略

節點集區升級策略

如何執行平行升級

平行升級預設值

開始升級叢集

bmctl

kubectl

暫停及繼續升級

啟用升級暫停和繼續功能

Google Distributed Cloud 1.36

Google Distributed Cloud 1.35

暫停升級

繼續暫停的升級作業

升級叢集

`bmctl`

`kubectl`

`bmctl`

`kubectl`