更新叢集、工作者節點和叢集元件

請檢閱下列各節,以取得保持叢集主節點和工作者節點最新的步驟。

更新主節點

我該如何知道何時該更新主伺服器?
有可用的更新項目時,您會在主控台、公告及 CLI 中收到通知。 您也可以定期檢查 支援的版本頁面
主分支最多可以落後最新版本幾個版本?
您只能將 API 伺服器更新至其現行版本 (n+1) 之前的下一個版本。
我的工作節點能否運行比主節點更新的版本?
您的工作節點無法執行比主節點更新的 major.minor Kubernetes 版本。 此外,工作者節點只能比主節點版本 (n-1) 落後一個版本。首先,將主節點 更新 至最新 Kubernetes 版本。 然後,在叢集裡更新工作者節點

工作者節點可以執行比主節點更新的修補程式版本,例如針對安全更新項目的工作者節點專用修補程式版本。

修補程式更新是如何套用的?
依預設,主節點的修補程式更新會在幾天內自動套用,因此,主節點修補程式版本可能會先顯示為可用,再將它套用至您的主節點。 更新自動化也會跳過處於性能不佳狀態或目前正在進行作業的叢集。 有時,IBM 可能會停用特定主節點修正套件的自動更新,例如只有在主節點從某個次要版本更新為另一個次要版本時才需要的修補程式。 在上述任何情況下,您可以查閱 Red Hat OpenShift on IBM Cloud 的版本資訊,以確認是否會受到影響,並選擇自行安全地執行 ibmcloud oc cluster master update 指令,無需等待自動更新機制生效。

與主節點不同,您必須更新每個修補程式版本的工作者節點。

主伺服器更新期間會發生什麼事?
您的主節點可以高度地與三個抄本主節點 Pod 搭配使用。 主節點 Pod 具有漸進式更新,在漸進式更新期間,一次僅有一個 Pod 無法使用。 兩個實例會啟動並執行,讓您可在更新期間存取和變更叢集。 您的工作者節點、應用程式及資源會繼續執行。
我可以將更新還原嗎?
不,在更新程序完成後,您無法將叢集還原至先前版本。 請確保使用測試叢集並遵循指示來解決潛在問題,然後再更新正式作業主節點。
我該遵循什麼流程來更新主資料?
下圖顯示您可以採取來更新主節點的處理程序。

主資料更新流程圖
更新 Kubernetes 主資料流程圖

更新叢集主節點的步驟

開始之前,請確認您已安裝 操作員管理員 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.mdRELEASENOTES.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 客戶端版本。

主節點更新完成後,可以更新工作者節點,具體取決於您擁有的叢集基礎架構提供者的類型。

更新標準工作者節點

您注意到 標準基礎架構 叢集裡的工作者節點有可用的更新項目。 這代表什麼意思? 由於 API 伺服器和其他主節點元件的安全更新和修補程式可供使用,因此您必須確保工作者節點保持同步。 可以進行兩種類型的更新:只更新修補程式版本,或者更新含有修補程式版本的 major.minor 版本。

  • 修補程式:工作者節點修補程式更新包含安全修正程式。 您可以使用 ibmcloud oc worker reloadupdate 指令,將標準工作者節點更新為最新修補程式。 請記住,如果 major.minor 版本更新也可用,則 update 指令也會將工作者節點更新為與主節點及最新修補程式版本相同的 major.minor 版本。
  • Major.minormajor.minor 更新將工作者節點的 Kubernetes 版本升級到與主節點相同的版本。 此類型的更新通常包含對 Kubernetes API 的變更或必須準備叢集以進行的其他行為。 請記住,工作者節點只能比主節點版本 (n-1) 落後一個版本。您可以使用 ibmcloud oc worker update 指令,將標準工作者節點更新至相同的修補程式。

如需相關資訊,請參閱更新類型

每次更新工作節點時,輪換 CA 憑證 是個好習慣,因為憑證輪換的最長步驟包括重新載入或更換工作節點。

更新期間,我的應用程式會發生什麼情況?
如果您在更新的工作者節點上進行部署時執行應用程式,則會將應用程式重新排定至叢集裡的其他工作者節點。 這些工作者節點可能位於不同的工作者節點儲存區中,或者,如果您有獨立式工作者節點,則可能會將應用程式排定至獨立式工作者節點。 若要避免應用程式發生運作中斷時間,您必須確定叢集裡有足夠的容量可以執行工作負載。
如何控制在更新或重新載入期間,一次會停機多少個工作節點?
如果您需要啟動並執行所有工作者節點,請考慮調整工作者節點儲存區大小新增獨立式工作者節點以新增更多工作者節點。 更新完成之後,即可移除其他工作者節點。

此外,您可以建立一個名為「Kubernetes」的配置地圖,用以指定在特定情況下(例如進行更新時)最多可同時處於不可用狀態的作業節點數量。 工作者節點是透過工作者節點標籤所識別。 您可以使用已新增至工作者節點的 IBM 提供的標籤或自訂標籤。

配置 Kubernetes 圖規則僅用於更新工作節點。 這些規則不會影響工作者節點重新載入,這表示在要求時立即重新載入。

如果我選擇不定義配置地圖,會怎樣?
未定義配置對映時,會使用預設值。 預設情況下,在更新過程中,每個叢集中最多有 20% 的工作節點可能無法使用。

必要條件

在更新標準基礎架構工作者節點之前,請檢閱必要條件步驟。

更新工作者節點可能會導致應用程式及服務發生運作中斷時間。 您的工作者節點機器會重新安裝映像,而且如果資料不是儲存在 Pod 之外即會被刪除。

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

設定配置對映以執行標準工作者節點的漸進式更新。

  1. 完成必要條件步驟

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

    ibmcloud oc worker ls --cluster CLUSTER
    
  3. 檢視工作者節點的標籤。 您可以在 CLI 輸出的 Labels 區段中找到工作者節點標籤。 每個標籤都包含 NodeSelectorKeyNodeSelectorValue

    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. 建立配置對映,並且定義工作者節點的無效性規則。 下列範例顯示四項檢查:zonecheck.jsonregioncheck.jsondefaultcheck.json 及檢查範本。 您可以使用這些檢查範例,為特定區域 (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.jsonregioncheck.json
    兩個核對項目,用於定義一組工作節點的規則,您可以透過指定的 NodeSelectorKeyNodeSelectorValue 來識別這些節點。 zonecheck.json 會根據工作節點的區域標籤來識別這些節點,而 regioncheck.json 則會使用在配置過程中新增至每個工作節點的區域標籤。 在此範例中,在更新期間,所有區域標籤為「dal13」的工作節點中有 30%,以及所有位於「us-south」的工作節點中有 20%,可能會處於不可用狀態。
    defaultcheck.json
    若未建立配置地圖,或地圖設定不正確,則會套用 Kubernetes 的預設值。 依預設,叢集裡只能有 20% 的工作者節點同時無法使用。 您可以新增配置對映的預設檢查,來置換預設值。 在此範例中,凡未在區域(zone)與區域(region)檢查(dal13us-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 狀態。 若要移除重複項目,請參閱疑難排解

後續步驟:

  • 對其他工作者節點儲存區重複更新處理程序。
  • 通知在叢集內工作的開發人員,將 oc CLI 更新至 Kubernetes 主節點的版本。
  • 如果 Kubernetes 儀表板未顯示使用率圖形,則會刪除 kube-dashboard Pod

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

首次設定配置對映後,接著就可以使用 IBM Cloud 主控台來更新工作者節點。

若要從主控台更新工作者節點,請執行下列動作:

  1. 完成必要條件步驟設定配置對映,以控制工作者節點的更新方式。
  2. IBM Cloud 主控台 功能表的 Menu 圖示,按一下 Containers > Clusters
  3. 叢集頁面中,按一下您的叢集。
  4. 在「工作節點」索引標籤中,勾選您要更新的每個工作節點旁的核取方塊。 動作列顯示在表格標頭列上方。
  5. 從動作列中,按一下更新

如果叢集裡已安裝 Portworx,則必須在已更新的工作者節點上重新啟動 Portworx Pod。 如需相關資訊,請參閱 Portworx 限制

更新 VPC 工作者節點

您注意到 VPC 叢集裡的工作者節點有可用的更新項目。 這代表什麼意思? 由於 API 伺服器和其他主節點元件的安全更新和修補程式可供使用,因此您必須確保工作者節點保持同步。 可以進行兩種類型的更新:只更新修補程式版本,或者更新含有修補程式版本的 major.minor 版本。

若您 Portworx 已在叢集部署,請遵循 步驟更新 Portworx 具備卷宗的 VPC 工作節點

每次更新工作節點時,輪換 CA 憑證 是個好習慣,因為憑證輪換的最長步驟包括重新載入或更換工作節點。

若您的叢集已部署 OpenShift Data Foundation,請遵循以下 步驟使用 OpenShift Data Foundation 更新 VPC 工作節點

  • 修補程式:工作者節點修補程式更新包含安全修正程式。 對於 VPC 裸機工作節點,您可以透過執行 ibmcloud oc worker reload 指令來套用最新修補程式。 對於 VPC 虛擬伺服器實例工作程序,請使用 ibmcloud oc worker replace 指令。
  • Major.minormajor.minor 更新將工作者節點的 Kubernetes 版本升級到與主節點相同的版本。 此類型的更新通常包含對 Kubernetes API 的變更或必須準備叢集以進行的其他行為。 請記住,工作者節點只能比主節點版本 (n-1) 落後一個版本。您可以搭配使用 ibmcloud oc worker replace 指令與 --update 選項,將 VPC 工作者節點更新至相同的修補程式。
更新期間,我的應用程式會發生什麼情況?
如果您在更新的工作者節點上進行部署時執行應用程式,則會將應用程式重新排定至叢集裡的其他工作者節點。 這些工作者節點可能位於其他工作者節點儲存區中。 為避免應用程式發生停機,您必須確保叢集中有足夠的容量來承載工作負載,例如透過調整工作節點池的大小來達成。 如需相關資訊,請參閱 將工作者節點新增至標準叢集將工作者節點新增至 VPC 叢集
在更新期間,我的工作節點會發生什麼情況?
您的 VPC 工作節點將透過移除舊的工作節點,並配置一個運行於更新後修補程式或 major.minor 版本的新工作節點來進行替換。 替換工作者節點在相同區域、相同工作者節點儲存區中建立,並且其規格與刪除的工作者節點相同。 然而,替代的工人節點會被指派一個新的私有 IP 位址,並會失去您先前套用至舊工人節點的任何自訂標籤或污點(但工人池的標籤和污點仍會套用至該替代的工人節點)。
如果我同時取代多個工作者節點,該怎麼辦?
如果您同時取代多個工作者節點,則會同時刪除並取代它們,而不是逐一取代。 在取代工作者節點之前,請確定叢集裡有足夠的容量來重新排程工作負載。
如果未建立替換用的工作者節點,該怎麼辦?
如果工作者節點儲存區未 啟用自動重新平衡,則不會建立取代工作者節點。

必要條件

在更新 VPC 基礎架構工作者節點之前,請檢閱必要條件步驟。

更新工作者節點可能會導致應用程式及服務發生運作中斷時間。 系統會移除工作者節點機器,並且如果資料未儲存在 Pod 外部,則將刪除資料。

在 CLI 中更新 VPC 工作者節點

請完成下列步驟,以使用 CLI 來更新工作者節點。

  1. 完成必要條件步驟
  2. 可選:透過調整工作節點池的大小,來擴增叢集的處理能力。 工作者節點上的 Pod 可以重新排定,並且這些 Pod 在更新期間繼續在新增的工作者節點上執行。 如需相關資訊,請參閱 將工作者節點新增至標準叢集將工作者節點新增至 VPC 叢集
  3. 列出叢集裡的工作者節點,並記下要更新的工作者節點的 IDPrimary IP
    ibmcloud oc worker ls --cluster CLUSTER
    
  4. 取代工作者節點,以更新與主節點版本符合的修補程式版本或 major.minor 版本。
    • 若要將工作者節點更新至與主節點相同的 major.minor 版本,請包括 --update 選項。
        ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update
        ```
    *  若要將工作者節點更新至相同 `major.minor` 版本的最新修補程式版本,請不要包含 `--update` 選項。
    ```sh {: pre}
        ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID
        ```
    
  5. 對必須更新的每個工作者節點重複上述步驟。
  6. 可選:當已替換的工作節點進入「就緒」狀態後,請調整工作節點池的大小,以符合您所需的叢集容量。 如需相關資訊,請 將工作者節點新增至 VPC 叢集

若您正在 VPC 叢集內 Portworx 執行作業,必須 手動將您的 Block Storage for VPC 磁碟區附加至新工作節點。

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

可以在主控台中更新 VPC 工作者節點。 開始之前,請考量 新增工作者節點 至叢集,以協助避免應用程式關閉。

  1. 完成必要條件步驟
  2. IBM Cloud 主控台 功能表的 Menu 圖示,按一下 Containers > Clusters
  3. 叢集頁面中,按一下您的叢集。
  4. 在「工作節點」索引標籤中,勾選您要更新的每個工作節點旁的核取方塊。 動作列顯示在表格標頭列上方。
  5. 從動作列中,按一下更新

更新規格(機型)

開始之前:

若要更新規格,請執行下列動作:

  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. 移除舊的工作者節點。 附註:如果您移除按月計費的規格(例如裸機),則仍會針對整個月向您收費。

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

如何縮減工作者節點儲存區?

當工作者節點儲存區中的工作者節點數目減少時 (例如在工作者節點更新期間或使用 ibmcloud oc worker-pool resize 指令),工作者節點會根據數個內容 (包括狀態、性能及版本) 來設定刪除的優先順序。

此優先順序邏輯與 autoscaler 附加程式無關。

下表顯示優先刪除工作者節點的順序。

您可以執行 ibmcloud oc worker ls 指令,以檢視表格中列出的所有工作者節點內容。

在工作者節點儲存區縮減期間刪除工作者節點的優先順序。
優先順序 內容 說明
1 工作者節點狀況 處於無法運作或低功能狀態的工作者節點會優先移除。 此清單顯示從最高到最低優先順序的狀態: provision_faileddeploy_faileddeletingprovision_pendingprovisioningdeployingprovisionedreloading_failedreloadingdeployed
2 工作者節點性能 性能不佳的工作者節點優先於性能良好的工作者節點。 此清單顯示從最高到最低優先順序的性能狀態: criticalwarningpendingunsupportednormal
3 工作者節點版本 在舊版上執行的工作者節點具有較高的刪除優先順序。
4 選擇的安置設定 僅適用於在專用主機上執行的工作者節點。DesiredPlacementDisabled 選項設為 true 的專用主機上執行的工作者節點具有較高的刪除優先順序。
5 按字母順序 根據上面列出的因素設定工作者節點的優先順序之後,會按字母順序刪除這些節點。 請注意,根據工作者節點 ID 慣例,標準及 VPC 叢集上工作者節點的 ID 會與經歷時間產生關聯,因此會先移除較舊的工作者節點。

更新叢集元件

Red Hat OpenShift on IBM Cloud 叢集隨附在佈建叢集時自動安裝的元件,例如 Ingress。 依預設,IBM 會自動更新這些元件。 但是,您可以停用某些元件的自動更新,而個別從主節點和工作者節點手動更新這些元件。

有哪些預設元件可以獨立於叢集之外進行更新?
您可以選擇停用下列元件的自動更新:
是否有某些元件無法獨立於叢集之外進行更新?
是。 您的叢集已部署以下受管元件及相關資源,這些內容不得變更,惟為提升特定效能而調整 Pod 規模或編輯 ConfigMap 者不在此限。 如果您嘗試變更下列其中一個部署元件,則當它們與叢集主節點一起更新時會定期還原其原始設定。 不過,請注意,不會更新您所建立且與下列這類元件相關聯的資源:例如,您所建立要由 Calico 部署元件實作的 Calico 網路原則。
  • calico 元件
  • coredns 元件
  • ibm-cloud-provider-ip
  • ibm-file-plugin
  • ibm-keepalived-watcher
  • ibm-master-proxy
  • ibm-storage-watcher
  • kubernetes-dashboard 元件
  • metrics-server
  • olm-operatorcatalog 元件 (1.16 以及更新版本)
  • vpn
除了預設元件之外,我還能安裝其他外掛程式或附加元件嗎?
是的。Red Hat OpenShift on IBM Cloud 提供了其他外掛程式和附加元件,您可以從中選擇,為您的叢集增添功能。 例如,您可能希望在叢集中啟用由 IBM 管理的外掛程式。 您必須依照 更新託管附加元件 的步驟分別更新這些附加元件。

管理 Fluentd 的自動更新

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

您可以透過下列方式來管理 Fluentd 元件的自動更新。 : 若要執行以下指令,您必須擁有該叢集的 管理員 IBM Cloud IAM 平台存取角色

  • 請執行 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 生命週期

更新受管理附加程式

IBM Cloud Kubernetes Service 託管叢集的附加元件,是透過開源功能(例如 Istio )來強化叢集的簡易方式。 您新增至叢集的開源工具版本,已由 IBM 進行測試,並獲准用於 IBM Cloud Kubernetes Service。 若要將叢集裡已啟用的受管理附加程式更新到最新版本,請參閱更新受管理附加程式