更新叢集主節點的步驟

開始之前，請確認您已安裝 操作員 或 管理員 IAM 平台存取角色。 如果您不確定自己的存取角色，請在 IBM Cloud 主控台中前往「管理」→「存取權限 (IAM)」→「使用者」，或向您的帳戶管理員詢問。

若憑證授權機構 (CA) 的憑證輪替正在進行中，主更新將被暫停，直至輪替完成為止。 開始之前，請先確認任何正在進行中的輪替狀態。

若要更新 Red Hat OpenShift 的_主版本號_或_次_版本號：

1. 檢閱 Red Hat OpenShift on IBM Cloud 版本資訊，並進行任何標示為 _在主節點之前更新_的更新項目。

2. 檢閱任何 Kubernetes 有用警告，例如淘汰注意事項。

3. 請檢查叢集裡安裝的附加程式和外掛程式，以瞭解更新叢集版本可能造成的任何影響。

   • 正在檢查附加程式

     1. 列出叢集裡的附加程式。

        ibmcloud oc cluster addon ls --cluster CLUSTER
        

     2. 請針對所安裝的每一個附加程式，檢查支援的 Red Hat OpenShift 版本。

        ibmcloud oc addon-versions
        

     3. 如果必須更新附加程式以在您要將叢集更新至的 Red Hat OpenShift 版本中執行，請 更新附加程式。

   • 正在檢查外掛程式

     1. 在 Helm 型錄中，尋找您在叢集裡安裝的外掛程式。
     2. 從側邊功能表中，展開 來源與 TAR 檔 區段。
     3. 下載並開啟原始碼。
     4. 請檢查 README.md 或 RELEASENOTES.md 檔案，以取得支援的版本。
     5. 如果必須更新外掛程式以在您要更新叢集的 Red Hat OpenShift 版本中執行，請遵循外掛程式指示來更新外掛程式。

4. 使用 IBM Cloud 主控台或執行 CLI ibmcloud oc cluster master update 指令來更新 API 伺服器和關聯的主節點元件。

5. 等待幾分鐘，然後確認更新已完成。 在 IBM Cloud 叢集儀表板上檢閱 API 伺服器版本，或執行 ibmcloud oc cluster ls。

6. 安裝與主節點中執行的 API 伺服器版本相符合的 oc cli 版本。 Kubernetes 不支援與伺服器版本相差兩個或更多版本（n ± 2）的 oc 客戶端版本。 若要重新整理您的本機設定，請執行 ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID，然後透過 ` `oc version --client 進行驗證。

當主節點的更新完成後，請更新您的工作節點。 此方法取決於您的基礎架構類型：

1. 更新經典工作節點 — 採用由 ConfigMap 及 worker update 指令所控制的滾動更新。
2. 更新 VPC 工作節點 — VPC 裸機工作節點可透過 worker reload 進行就地更新；VPC VSI 工作節點則必須使用 worker replace --update。 ConfigMap 的滾動更新程序目前尚不支援 VPC 工作節點。

必要條件

在更新您的傳統基礎架構工作節點之前，請先完成以下先決條件步驟。

在執行工作節點更新時，工作節點的機器會重新安裝作業系統映像，且所有未 儲存於持久儲存裝置中的 資料都會被永久刪除。 在開始之前，請確認您需要保留的任何資料皆已儲存於工作節點之外。

若您的叢集中已安裝 Portworx，則必須執行 在更新工作節點之前，請先更新您的 Portworx 設定。

在 CLI 中使用配置對映更新標準工作者節點

請使用 ConfigMap 來對您的經典工作節點執行滾動更新。 透過「ConfigMap」，您可以設定每個區域或區域內，同時最多允許有多少個節點處於不可用狀態。 如果您的叢集能接受預設的 20% 不可用率規則，您可以跳過步驟 3 和 4（建立 ConfigMap ），並直接進行步驟 5，以預設行為套用更新。

1. 完成必要條件步驟。

2. 列出可用的工作者節點，並記下其專用 IP 位址。

   ibmcloud oc worker ls --cluster CLUSTER
   

3. 檢視工作者節點的標籤。 您可以在 CLI 輸出的 Labels 區段中找到工作者節點標籤。 每個標籤都包含 NodeSelectorKey 及 NodeSelectorValue。

   oc describe node PRIVATE-WORKER-IP
   

   輸出範例

   NAME:               10.184.58.3
   Roles:              <none>
   Labels:             arch=amd64
                   beta.kubernetes.io/arch=amd64
                   beta.kubernetes.io/os=linux
                   failure-domain.beta.kubernetes.io/region=us-south
                   failure-domain.beta.kubernetes.io/zone=dal12
                   ibm-cloud.kubernetes.io/encrypted-docker-data=true
                   ibm-cloud.kubernetes.io/iaas-provider=softlayer
                   ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                   kubernetes.io/hostname=10.123.45.3
                   privateVLAN=2299001
                   publicVLAN=2299012
   Annotations:        node.alpha.kubernetes.io/ttl=0
                   volumes.kubernetes.io/controller-managed-attach-detach=true
   CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
   Taints:             <none>
   Unschedulable:      false
   

4. 建立配置對映，並且定義工作者節點的無效性規則。 ConfigMap 最多可支援 15 項命名檢查。 每項檢查皆根據標籤鎖定一組工作節點，並設定這些節點中，同時不可用的節點數目所佔的最大百分比。 以下範例展示了一個區域檢查（zonecheck.json ）、一個區域檢查（regioncheck.json ）、一個預設備用檢查（defaultcheck.json ），以及一個自訂檢查的範本。 對於每項檢查，請從上一步驟中擷取的作業節點標籤中選擇一個，用以識別目標節點。

   對於每項檢查，您只能為 NodeSelectorKey 和 NodeSelectorValue`` 各設定一個值。 如果您要為多個地區、區域或其他工作者節點標籤設定規則，請建立新的檢查。 在配置地圖中最多可定義 15 項檢查。 如果您新增其他檢查，則在更新所要求的所有工作者節點之前，一次只會重新載入 1 個工作者節點。

   範例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     zonecheck.json: |
       {
         "MaxUnavailablePercentage": 30,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
         "NodeSelectorValue": "dal13"
       }
     regioncheck.json: |
       {
         "MaxUnavailablePercentage": 20,
         "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
         "NodeSelectorValue": "us-south"
       }
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   可選：等待 排水完成的超時時間（以秒為單位）。 排除工作者節點可安全地移除工作者節點中的所有現有 Pod，以及將 Pod 重新排定至叢集裡的其他工作者節點。 接受的值為範圍在 1 到 180 之間的整數。 預設值為 30。

   zonecheck.json 及 regioncheck.json

   兩個核對項目，用以定義一套工作節點的規則，您可以透過指定的 NodeSelectorKey 和 NodeSelectorValue 來識別這組工作節點。 zonecheck.json 會根據工作節點的區域標籤來識別這些節點，而 regioncheck.json 則會使用在資源配置過程中新增至每個工作節點的區域標籤。 在此範例中，在更新期間，所有區域標籤為「dal13」的工作節點中有 30%，以及所有位於「us-south」中的工作節點中有 20%，可能會無法使用。

   defaultcheck.json

   若未建立配置地圖，或地圖設定不正確，則會套用 Kubernetes 的預設值。 依預設，叢集裡只能有 20% 的工作者節點同時無法使用。 您可以新增配置對映的預設檢查，來置換預設值。 在此範例中，凡未在區域（zone）與區域（region）檢查中指定（dal13 或 us-south ）的每個工作節點，在更新期間都可能處於不可用狀態。

   MaxUnavailablePercentage

   對於指定的標籤鍵和值，容許無法使用的節點數目上限，以百分比的格式指定。 工作者節點在部署、重新載入或佈建程序中會無法使用。 如果已排入佇列的工作者節點超出任何已定義的無法使用百分比上限，則會被封鎖而無法更新。

   NodeSelectorKey

   您要設定規則的工作者節點的標籤索引鍵。 可以為 IBM 提供的預設標籤以及您建立的工作者節點標籤設定規則。 若要針對屬於同一個工作節點池的工作節點新增一項規則，您可以使用「ibm-cloud.kubernetes.io/machine-type」標籤。

   NodeSelectorValue

   工作者節點必須具有以讓您定義的規則考量的標籤值。

5. 在叢集裡建立配置對映。

   oc apply -f <filepath/configmap.yaml>
   

6. 驗證已建立配置對映。

   oc get configmap --namespace kube-system
   

7. 更新工作者節點。

   ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID
   

8. 選用項目：驗證配置對映所觸發的事件，以及發生的所有驗證錯誤。 在 CLI 輸出的 Events 區段中，可以檢閱事件。

   oc describe -n kube-system cm ibm-cluster-update-configuration
   

9. 藉由檢閱工作者節點的 Kubernetes 版本，來確認更新已完成。

   oc get nodes
   

10. 請確認您沒有重複的工作節點。 有時，較舊的叢集會列出具有重複 NotReady 狀態。 若要移除重複項目，請參閱疑難排解。

在主控台中更新標準工作者節點

首次設定 ConfigMap 之後，您可以透過 IBM Cloud 控制台來更新工作節點。 此主控台會遵循您在《 ConfigMap 》中定義的不可用性規則。

1. 請完成 先決步驟，並 設定一個「ConfigMap」，以控制您的工作節點如何進行更新。
2. 從 IBM Cloud 主控台 功能表的 ，按一下 Containers > Clusters。
3. 從叢集頁面中，按一下您的叢集。
4. 在「工作節點」分頁中，勾選您要更新的每個工作節點旁的核取方塊。 動作列顯示在表格標頭列上方。
5. 從動作列中，按一下更新。

若您的叢集中已安裝 Portworx，則必須在已更新的工作節點上重新啟動 Portworx 的 Pod。 如需更多資訊，請參閱 Portworx 限制。

必要條件

在更新 VPC 基礎架構的工作節點之前，請先完成以下先決條件步驟。

對於 VPC VSI 工作節點，系統會刪除原有工作節點並以新節點取代。 對於 VPC 裸機工作節點，該節點將就地重新載入。 在這兩種情況下，未 儲存於持久性儲存裝置中的 資料都會被永久刪除。 在開始之前，請確認您需要保留的任何資料皆已儲存於工作節點之外。

若您的叢集中已部署 Portworx，請依照相關步驟 ，將 VPC 工作節點更新為使用 Portworx 卷宗， 而非遵循本頁面的步驟。

在 VPC 裸機工作節點重新載入期間進行韌體更新

當您重新載入 VPC 裸機工作節點時，IBM Cloud 基礎架構會自動檢查該伺服器是否有待處理的韌體更新，並在重新載入過程中一併套用該更新。 無需執行任何額外操作即可觸發韌體更新。

重新載入 VPC 裸機工作節點時，請注意以下事項：

重新載入時間延長

若在重新載入過程中進行韌體更新，總重新載入時間可能會大幅增加——可能比一般重新載入時間多出 30 分鐘或更久。 請據此規劃您的維護時段。

無法預先查看待處理的更新

在執行 reload 指令之前，無法得知工作節點是否正在等待韌體更新。

資料遺失風險

與所有 VPC 裸機工作節點的重新載入作業相同，無論是否進行韌體更新，重新載入過程中都會刪除本機磁碟上的資料。 在重新載入之前，請先備份任何未儲存於持久性儲存裝置上的資料。

因韌體更新導致重新載入失敗

在某些情況下，韌體更新可能會失敗，導致工作節點進入「reload_failed」狀態（Failed to reload worker ），並顯示狀態詳細資訊 The infrastructure firmware update has failed. (P4056)。 若發生此情況：

1. 請等待幾分鐘，然後再次執行 ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID 來重新載入。
2. 如果嘗試 2 至 3 次後錯誤仍未解決，請提交一則 IBM Cloud 支援案件。

開始之前

• 存取您的 Red Hat OpenShift 叢集。
• 請確認您需要保留的任何資料，皆已儲存於工作節點外的 持久性儲存裝置 中。 僅儲存於工作節點上的資料將遺失且無法恢復。
• 請確認您已安裝 操作員 或 管理員 IAM 平台存取角色。 如果您不確定自己的存取角色，請在 IBM Cloud 主控台中前往「管理」→「存取權限 (IAM)」→「使用者」，或向您的帳戶管理員詢問。

更新風味

1. 列出可用的工作者節點，並記下其專用 IP 位址。

   1. 列出叢集裡可用的工作者節點儲存區。

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   2. 列出工作者節點儲存區中的工作者節點。 請記下 **ID** 及**專用 IP**。
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
       ```
   3. 取得工作者節點的詳細資料。 在輸出中，記下區域，以及標準叢集的專用及公用 VLAN ID 或 VPC 叢集的子網路 ID。
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. 列出區域中的可用規格。

   ibmcloud oc flavors --zone <zone>
   

3. 使用新機型建立工作者節點。

   1. 使用您要取代的工作者節點數目，建立工作者節點儲存區。
      • 標準叢集：

        ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
        

      • VPC 第 2 代叢集:

        ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
        

   2. 驗證已建立工作者節點儲存區。

       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   3. 將區域新增至您先前擷取的工作者節點儲存區。 當您新增區域時，會在區域中佈建工作者節點儲存區中所定義的工作者節點，並考慮用於排定未來的工作負載。 如果您要將工作者節點分散在多個區域，請選擇 [標準](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) 或 [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc) 多區域位置。
       * 標準叢集：
           ```sh {: pre}
           ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
           ```
       * VPC 叢集：
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. 等待部署工作者節點。 工作者節點狀況變更為正常時，部署已完成。

   ibmcloud oc worker ls --cluster CLUSTER
   

5. 移除舊的執行程序池。 如果您要移除「Classic」裸機方案（此方案按月計費），即使是在當月中途移除，仍需支付當月全額費用。 VPC 工作執行個體（包括裸機）均按小時計費。

   1. 移除具有舊機型的工作者節點儲存區。 移除工作者節點儲存區，會移除所有區域的儲存區中的所有工作者節點。 此處理程序可能需要幾分鐘的時間才能完成。

       ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
       ```
   2. 驗證已移除工作者節點儲存區。
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. 驗證已從叢集裡移除工作者節點。

   ibmcloud oc worker ls --cluster CLUSTER
   

7. 重複這些步驟以將其他工作者節點儲存區或獨立式工作者節點更新為不同的規格。

管理 Fluentd 的自動更新

當您為叢集中的來源建立記錄配置以轉發至外部伺服器時，系統會在您的叢集中建立一個 Fluentd 元件。 若要變更您的記錄或篩選設定，Fluentd 元件必須為最新版本。 依預設，會啟用元件的自動更新。

若要執行以下指令，您必須擁有該叢集的 管理員 IBM Cloud IAM 平台存取角色 權限。

您可以透過下列方式來管理 Fluentd 元件的自動更新。

• 請執行 ibmcloud oc logging autoupdate get --cluster CLUSTER 指令，以檢查自動更新功能是否已啟用。
• 藉由執行 ibmcloud oc logging autoupdate disable 指令來停用自動更新。
• 如果停用了自動更新，但您需要對配置進行變更，則有兩個選項：
  • 開啟 Fluentd Pod 的自動更新。

      ibmcloud oc logging autoupdate enable --cluster CLUSTER
      ```
  * 在您使用包括 `--force-update` 選項的 logging 指令時，強制執行一次性更新。 您的 Pod 已更新至 Fluentd 元件的最新版本，但 Fluentd 今後將不會自動更新。
          範例指令
  
  ```sh {: pre}
      ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
      ```
  

管理 Ingress ALB 的自動更新

控制何時更新 Ingress 應用程式負載平衡器 (ALB) 元件。 如需保持 ALB 最新的相關資訊，請參閱 管理 Ingress ALB 生命週期。