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

升級叢集

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

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

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

規劃升級作業

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

最佳做法

如需叢集升級準備工作相關資訊，請參閱「Google Distributed Cloud 叢集升級最佳做法」。

升級前檢查

預檢是叢集升級程序的一部分，用於驗證叢集狀態和節點健康狀態。如果預檢失敗，叢集升級作業就不會繼續。如要進一步瞭解預檢檢查，請參閱「瞭解預檢檢查」。

您可以在升級前執行預檢，確認叢集是否已準備就緒。詳情請參閱「升級前檢查」。

已知問題

如要瞭解叢集升級可能導致的問題，請參閱「Google Distributed Cloud for bare metal 已知問題」，然後選取「升級和更新」問題類別。

設定升級選項

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

選擇性升級 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.35.100
  ...

將叢集設定檔中的 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 節點集區。

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

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

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

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

工作站節點集區支援 n-2 版本偏移，可讓您更彈性地規劃機群升級作業。

舉例來說，如果叢集版本為 1.35，工作節點集區可選用 1.35、1.34 和 1.33 版。

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

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

如要進一步瞭解相關資訊，包括特定叢集版本支援的 worker 節點集區版本清單 (適用於 1.29 版和更早版本)，請參閱「節點集區版本管理規則」。

1.30 以上版本

在 1.30 版中，工作站節點集區的 n-2 版本偏差支援功能已正式推出，適用於所有叢集類型。對於 1.30 版的叢集，這項功能預設為啟用。

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

1.29

在 1.29 版中，所有叢集類型都可正式使用工作站節點集區的 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 節點集區納入叢集升級作業，請對 NodePool 規格進行下列其中一項變更：
- 在 NodePool 規格中，將 anthosBareMetalVersion 設為叢集目標升級版本。
- 從 NodePool 規格中省略 anthosBareMetalVersion 欄位，或將其設為空白字串。根據預設，叢集升級時會一併升級 worker 節點集區。
如要排除工作站節點集區，不要升級，請將 anthosBareMetalVersion 設為叢集的目前 (升級前) 版本：
按照「啟動叢集升級」一文所述，繼續升級。

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

舉例來說，假設叢集版本為 1.34.0，且有兩個 worker 節點集區：wpool01 和 wpool02。此外，假設您想將控制層和 wpool01 升級至 1.35.100，但想讓 wpool02 維持在 1.34.0 版。

下列叢集設定檔摘錄內容顯示如何修改叢集設定，以支援這項部分升級：

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.35.100
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.100
  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.34.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 欄位會設為先前的 (升級前) 叢集版本。

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

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

如果選取多個工作節點集區進行升級，叢集規格中的 spec.nodePoolUpgradeStrategy.concurrentNodePools 值會決定要平行升級多少個節點集區 (如有)。如不想同時升級 worker 節點集區，請一次選取一個節點集區進行升級。
按照「啟動叢集升級」一文所述，繼續升級。

叢集升級作業只會升級先前排除的背景工作節點集區，且您已將這些集區的 anthosBareMetalVersion 設為目前的升級叢集版本。

舉例來說，假設您將叢集升級至 1.35.100 版，但節點集區 wpool02 仍停留在升級前的舊版叢集 1.34.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.35.100
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.35.100
  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 指令套用變更：

在叢集設定檔中，編輯要還原至先前版本的工作站節點集區的 NodePool 規格。將 anthosBareMetalVersion 設為先前的 (升級前) 叢集版本。
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.34.600-gke.53
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
如果選取多個要回溯的節點集區，叢集規格中的 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 會為每個節點執行下列活動：
- 讓節點進入維護模式。
- 在節點上執行重設工作，將節點恢復為乾淨狀態。
- 在節點上執行機器預檢。
- 在節點上執行機器初始化作業，以目標復原 (升級前) 版本重新安裝節點。
- 將節點從維護模式中移除。
成功復原後，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.34.600-gke.53
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

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

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

平行升級

在典型的預設叢集升級中，每個叢集節點會依序升級。本節說明如何設定叢集和工作站節點集區，以便在升級叢集時，同步升級多個節點。平行升級節點可大幅加快叢集升級速度，尤其是擁有數百個節點的叢集。

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

並行節點升級：您可以設定工作站節點集區，讓多個節點並行升級。節點的平行升級作業是在 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 節點集區和 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.35.100
  ...
  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.35.100
```
使用 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.35

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

Google Distributed Cloud 1.34

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

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

在叢集設定檔中新增 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.35

Google Distributed Cloud 1.34

暫停升級

繼續進行已暫停的升級作業

升級叢集

`bmctl`

`kubectl`

`bmctl`

`kubectl`