從 Azure CLI 升級叢集執行階段

發行項
09/26/2024

本操作指南說明安裝必要 Azure 命令列介面和與運算子連接點互動所需延伸模組的步驟。

必要條件

必須安裝 Azure 命令列介面。
需要 networkcloud CLI 延伸模組。如果未安裝 networkcloud 延伸模組，可遵循此處所列的步驟進行安裝。
要升級之目標叢集的 Microsoft Azure 入口網站存取權。
您必須透過 az login 登入與目標叢集相同的訂用帳戶
目標叢集必須處於執行中狀態、所有控制平面節點狀況良好，而且 80+% 計算節點處於執行中健全狀態。

尋找可用的執行階段版本

透過入口網站

若要尋找可用的可升級執行階段版本，請在 Microsoft Azure 入口網站瀏覽至目標叢集。在叢集的概觀窗格，瀏覽至 [可用升級版本] 索引標籤。

從 [可用升級版本] 索引標籤，我們可以看到目前可用於升級的不同叢集版本。操作員可以從列出的目標執行階段版本選取。選取之後，繼續升級叢集。

透過 Azure CLI

可透過 Azure 命令列介面擷取可用的升級：

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

在輸出中，您可以找到 availableUpgradeVersions 屬性及查看 targetClusterVersion 欄位：

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

如果沒有可用的叢集升級，清單會是空的。

使用命令列介面升級叢集執行階段

若要升級執行階段，請使用下列 Azure 命令列介面命令：

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

執行階段升級是漫長的流程。升級會先升級管理節點，然後循序逐一機架為背景工作角色節點升級。每個機架有 80% 的背景工作角色節點和 100% 的管理節點順利升級時，升級便視同完成。機架中的背景工作角色節點正在升級時，工作負載可能會受到影響，不過所有其他機架中的工作負載不會受到影響。建議您根據此實作設計斟酌工作負載放置方式。

升級所有節點需要數小時，但如果其他流程，例如韌體更新，也屬於升級的一部分，則可能需要更長的時間。由於升級流程漫長，建議您定期檢查叢集的詳細狀態，取得升級的最新狀態。若要檢查升級的狀態，請觀察叢集的詳細狀態。透過入口網站或 az 命令列介面可完成此檢查。

若要透過 Microsoft Azure 入口網站檢視升級狀態，請瀏覽至目標叢集資源。叢集的 [概觀] 畫面提供詳細狀態，以及詳細的狀態訊息。

當 detailedStatus 設定為 Updating，且 detailedStatusMessage 顯示部署的進度時，表示叢集升級正在進行中。 detailedStatusMessage 中顯示的一些升級進度範例為 Waiting for control plane upgrade to complete...、Waiting for nodepool "<rack-id>" to finish upgrading... 等。

當 detailedStatus 設定為 Running 且 detailedStatusMessage 顯示訊息 Cluster is up and running 時，表示叢集升級完成

若要透過 Azure 命令列介面檢視升級狀態，請使用 az networkcloud cluster show。

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

輸出應該是目標叢集的資訊，而且應該會出現叢集的詳細狀態和詳細狀態訊息。如需升級進度的詳細深入解析，檢查每個機架中的個別 BMM 即可獲得狀態。裸機角色下的參考區段提供此範例。

使用叢集 updateStrategy 設定執行階段升級的計算閾值參數

下列 Azure 命令列介面命令可用來設定執行階段升級的計算閾值參數：

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks>

必要參數：

strategy-type：定義更新策略。在此情況下，「Rack」表示更新會逐機架進行。預設值為「Rack」。
threshold-type：決定應如何評估閾值，並套用策略所定義的單位。預設值為「PercentSuccess」。
threshold-value：用來評估更新的數值閾值。預設值是 80。

選擇性參數：

max-unavailable：可以離線的背景工作角色節點數目上限，也就是一次升級一部機架。預設值為 32767。
wait-time-minutes：更新機架前的延遲或等待期間。預設值為 15。

命令的使用方式範例如下：

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

成功執行命令時，指定的 updateStrategy 值會套用至叢集：

    "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    }

注意

設定低於 100% 的閾值時，可能不會升級任何狀況不良的節點，但「叢集」狀態仍可能表示升級成功。如需針對裸機電腦的問題進行疑難排解，請參閱針對 Azure 運算子連接點伺服器問題進行疑難排解

使用 PauseRack 策略進行升級

從 API 版本 2024-06-01-preview 開始，可以使用「PauseRack」策略來觸發執行階段升級。當您使用 PauseRack 策略執行叢集執行階段升級時，其會在叢集中一次更新一個機架，然後停止，等待確認，再繼續更新下一個機架。「PauseRack」策略將繼續遵守所有現有的閾值。若要使用「PauseRack」策略執行叢集執行階段升級，請遵循使用暫停機架策略來升級叢集執行階段中所述的步驟

常見問題集

識別停滯的叢集升級

執行階段升級期間，升級可能無法推進，但詳細狀態會反映升級仍在進行中。 因為執行階段升級可能需要很長的時間才能順利完成，因此目前未指定逾時時間長度。因此，建議您也定期檢查叢集的詳細狀態和記錄，判斷升級是否無限嘗試升級。

查看叢集的記錄、詳細訊息和詳細狀態訊息，即可識別發生這種情況的時間。如果發生逾時，我們會發現叢集同樣持續無限期協調，不會推進。從這裡，建議您檢查叢集記錄或設定的 LAW，以查看是否有失敗，或導致無法推進的特定升級。

硬體失敗不需要重新執行升級

如果升級期間發生硬體失敗，只要符合計算和管理/控制節點的設定閾值，執行階段升級就會繼續。機器修正或取代後，就會使用目前平台執行階段的 OS 佈建，其中包含執行階段的目標版本。

如果發生硬體失敗，執行階段升級也因為不符合計算和控制節點閾值而失敗，視失敗發生的時間和機架中個別伺服器的狀態而定，可能必須重新執行執行階段升級。如果機架在失敗前更新，則重新佈建節點時，將會使用升級的執行階段版本。如果機架規格在硬體失敗前未更新為升級的執行階段版本，則會使用先前的執行階段版本佈建機器。若要升級至新的執行階段版本，請提交新的叢集升級要求，且只有具有舊版執行階段的節點才會升級。在先前升級動作中成功的主機則不會。

執行階段升級之後，叢集會顯示「失敗」佈建狀態

在執行階段升級期間，叢集會進入 Upgrading 的狀態。如果執行階段升級失敗，叢集將會進入 Failed 佈建狀態。升級期間失敗可能是基礎結構元件 (例如儲存設備) 所造成的。在某些情況下，您可能需要使用 Microsoft 支援服務來診斷失敗。

在叢集執行階段升級期間對連接點 Kubernetes 租用戶工作負載的影響

在執行階段升級期間，受影響的連接點 Kubernetes 叢集節點會在裸機主機 (BMH) 升級之前遭到隔離並清空。隔離 Kubernetes 叢集節點可防止在其上排程新的 Pod，而清空 Kubernetes 叢集節點，可讓執行租用戶工作負載的 Pod 有機會轉移到另一個可用的 Kubernetes 叢集節點，這有助於降低對服務的影響。清空機制的有效性取決於連接點 Kubernetes 叢集內的可用容量。如果 Kubernetes 叢集接近完整容量，且沒有空間重新放置 Pod，則其會在清空流程完成之後轉換為擱置狀態。

一旦租用戶叢集節點的隔離和清空流程完成，BMH 的升級就會繼續進行。每個租用戶叢集節點最多允許 10 分鐘，讓清空流程完成，這段時間後 BMH 升級就會開始。這保證 BMH 升級將取得進展。一次一個機架升級 BMH，並在相同的機架內平行執行升級。 BMH 升級不會等待租用戶資源上線，再繼續機架中的 BMH 執行階段升級。其優點是，不論有多少節點可用，機架升級的整體等候時間上限都會保持在 10 分鐘。此最長等候時間是隔離和清空流程特有的，而且不會套用至整體升級程序。完成每個 BMH 升級時，連接點 Kubernetes 叢集節點會啟動、重新加入叢集，且未遭隔離，從而允許在節點上再次排程 Pod。

請務必注意，在隔離和清空流程之後，連接點 Kubernetes 叢集節點將不會關閉。所有連接點 Nexus Kubernetes 叢集節點一被隔離並清空，BMH 就會使用新映像重新啟動，如果排空流程未完成，則會在 10 分鐘後進行。此外，不會針對 BMH 的關閉電源或重新啟動動作起始隔離和清空；其只會在執行階段升級期間單獨啟用。

請務必注意，在執行階段升級之後，可能會有連接點 Kubernetes 叢集節點保持隔離狀態的情況。針對這類情況，您可以執行下列命令，手動取消隔離節點

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table

共用方式為