更新叢集、工作者節點和叢集元件
請依照正確的順序更新主節點、工作節點及叢集組件,以確保叢集的安全性並獲得技術支援。 若未依序進行更新,可能會導致版本不一致的錯誤或意外的系統停機。
請依照以下順序完成更新:
- 更新叢集主節點。
- 更新您的工作節點 — Classic、VPC 或 Satellite — 視您的基礎架構類型而定。 不確定您的是哪一種嗎? 在 IBM Cloud 控制台中,點選您的叢集,並查看「概覽」分頁中的「基礎架構」欄位——該處會顯示「經典」、「VPC」或 Satellite。
- 更新叢集元件 例如 Fluentd 以及 Ingress ALB,若您是手動管理這些服務的話。
- 更新受管附加元件。
更新主節點
- 我該如何知道何時該更新主伺服器?
- 有可用的更新項目時,您會在主控台、公告及 CLI 中收到通知。 您也可以定期檢查 支援的版本頁面。
- 主分支最多可以落後最新版本幾個版本?
- 您只能將 API 伺服器更新至其現行版本 (
n+1) 之前的下一個版本。 - 我的工作節點能否運行比主節點更新的版本?
- 您的工作節點無法執行比主節點更新的
major.minorKubernetes 版本。 此外,您的工作節點版本最多只能比主節點版本落後兩個次版本(n-2)。首先,請將您的主節點更新 至最新版本 Kubernetes。 然後,在叢集裡更新工作者節點。
工作者節點可以執行比主節點更新的修補程式版本,例如針對安全更新項目的工作者節點專用修補程式版本。
- 修補程式更新是如何套用的?
- 依預設,主節點的修補程式更新會在幾天內自動套用,因此,主節點修補程式版本可能會先顯示為可用,再將它套用至您的主節點。 更新自動化也會跳過處於性能不佳狀態或目前正在進行作業的叢集。 有時,IBM 可能會停用特定主節點修正套件的自動更新,例如只有在主節點從某個次要版本更新為另一個次要版本時才需要的修補程式。 在上述任何情況下,您可以查閱 Kubernetes 的版本資訊,以確認是否可能受到影響,並選擇自行安全地執行
ibmcloud ks cluster master update指令,無需等待自動更新程序生效。
與主節點不同,您必須更新每個修補程式版本的工作者節點。
- 主伺服器更新期間會發生什麼事?
- 您的主節點可以高度地與三個抄本主節點 Pod 搭配使用。 主節點 Pod 具有漸進式更新,在漸進式更新期間,一次僅有一個 Pod 無法使用。 兩個實例會啟動並執行,讓您可在更新期間存取和變更叢集。 您的工作者節點、應用程式及資源會繼續執行。
- 我可以將更新還原嗎?
- 不,在更新程序執行完畢後,您無法將叢集還原至先前版本。 請確保使用測試叢集並遵循指示來解決潛在問題,然後再更新正式作業主節點。
- 我該遵循什麼流程來更新主資料?
- 下圖顯示您可以採取來更新主節點的處理程序。
更新叢集主節點的步驟
開始之前,請確認您已安裝 操作員 或 管理員 IAM 平台存取角色。 如果您不確定自己的存取角色,請在 IBM Cloud 控制台中前往「管理」→「存取權限 (IAM)」→「使用者」,或向您的帳戶管理員詢問。
若憑證授權機構 (CA) 憑證輪替正在進行中,主更新將被暫停,直至輪替完成為止。 開始之前,請先確認任何正在進行中的輪替狀態。
若要更新 Kubernetes 的_主版本號_或_次_版本號:
-
請檢視 Kubernetes 的版本資訊,並執行所有標示為「Update before master」的更新。
-
檢閱任何 Kubernetes 有用警告,例如淘汰注意事項。
-
請檢查叢集裡安裝的附加程式和外掛程式,以瞭解更新叢集版本可能造成的任何影響。
-
正在檢查附加程式
- 列出叢集裡的附加程式。
ibmcloud ks cluster addon ls --cluster CLUSTER - 針對已安裝的每一個附加程式,檢查支援的 Kubernetes 版本。
ibmcloud ks addon-versions - 如果必須更新附加程式,才能在您要將叢集更新至的 Kubernetes 版本中執行,請 更新附加程式。
- 列出叢集裡的附加程式。
-
正在檢查外掛程式
- 在 Helm 型錄中,尋找您在叢集裡安裝的外掛程式。
- 從側邊功能表中,展開 來源與 TAR 檔 區段。
- 下載並開啟原始碼。
- 請檢查
README.md或RELEASENOTES.md檔案,以取得支援的版本。 - 如果必須更新外掛程式,才能在您要將叢集更新至的 Kubernetes 版本中執行,請遵循外掛程式指示來更新外掛程式。
-
-
使用 IBM Cloud 主控台或執行 CLI
ibmcloud ks cluster master update指令來更新 API 伺服器和關聯的主節點元件。 -
等待幾分鐘,然後確認更新已完成。 在 IBM Cloud 叢集儀表板上檢閱 API 伺服器版本,或執行
ibmcloud ks cluster ls。 -
安裝與主節點中執行的 API 伺服器版本相符合的
kubectl cli版本。 Kubernetes 不支援與伺服器版本相差兩個或更多版本(n ± 2)的kubectl客戶端版本。 若要重新整理您的本地端設定,請執行ibmcloud ks cluster config -c CLUSTER_NAME_OR_ID,然後使用 ` `kubectl version --client進行驗證。
當主節點的更新完成後,請更新您的工作節點。 此方法取決於您的基礎架構類型:
- 更新經典工作節點 — 採用由 ConfigMap 及
worker update指令所控制的滾動式更新。 - 更新 VPC 工作節點 — VPC VSI 工作節點和 VPC 裸機工作節點必須使用
worker replace --update。 ConfigMap 的滾動更新程序目前尚不支援 VPC 工作節點。
更新標準工作者節點
經典基礎架構的工作節點會在原地執行滾動更新。 更新由 Kubernetes ( ConfigMap )所控制,該設定定義了同時最多可有多少個節點處於不可用狀態。 ibmcloud ks worker update 指令僅適用於經典工作節點。
您可以進行兩種類型的更新:
- 修補程式:套用安全性修補程式,並將版本更新至最新修補版本。 請使用
ibmcloud ks worker reload或ibmcloud ks worker update。 這兩條指令都會將節點更新至最新的修補程式版本。update指令同時也會套用任何可用的major.minor版本更新,使其與主分支保持一致。 - Major.minor: 將工作節點的
Kubernetes版本升級,使其與主節點保持一致。 您的工作節點版本落後主節點的幅度最多為兩個版本(n-2)。請使用ibmcloud ks worker update指令。
如需相關資訊,請參閱更新類型。
每次更新工作節點時,輪換 CA 憑證 是個好習慣,因為憑證輪換的最長步驟包括重新載入或更換工作節點。
- 更新期間,我的應用程式會發生什麼情況?
- 在已更新的工作節點上執行的應用程式,會被重新排程至叢集中的其他工作節點——包括位於不同工作節點群組中的節點,或是獨立的工作節點。 為避免系統停機,請在開始更新之前,確保叢集具有足夠的容量來承載工作負載。
- 在執行更新或重新載入時,該如何控制同時停機的作業節點數量?
- 請使用 Kubernetes ConfigMap 來設定同時最多可處於不可用狀態的執行節點數量。 工作節點是透過其標籤來識別的。 您可以使用 IBM 預設的標籤或自訂標籤。 如果您需要確保所有工作節點均保持可用,請考慮在更新前 調整工作節點池的大小,或 新增獨立的工作節點 以增加臨時處理能力。
ConfigMap 僅控制更新行為。 這不會影響工作節點的重新載入,因為工作節點會在收到請求時立即重新載入。
- 如果我選擇不定義配置地圖,會怎樣?
- 預設情況下,在更新期間,每個叢集中最多有 20% 的工作節點可能無法使用。 您可以透過定義一個包含
defaultcheck.json項的ConfigMap,來覆寫此值。
必要條件
在更新您的傳統基礎架構工作節點之前,請先完成以下先決條件步驟。
在工作節點更新期間,工作節點的機器會重新安裝作業系統,且所有未 儲存於持久性儲存裝置中的 資料都會被永久刪除。 在開始之前,請確認您需要保留的任何資料均已儲存於工作節點之外。
若您的叢集中已安裝 Portworx,則必須 在更新工作節點之前,先更新 Portworx 的設定。
更新前的準備步驟(請依序完成)
- 請參閱 Kubernetes 的版本資訊,以了解最新的安全性修補程式及所需變更。
- 請針對 《 Kubernetes 版本準備指南》 中標示為「在主分支之前更新」或「在主分支之後更新」的任何變更進行調整。
- 在更新工作節點之前,請先更新主節點。 工作節點的版本不得高於主節點上執行的 API 伺服器版本。
- 請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。
- 請考慮在叢集中 新增工作節點,以便在更新期間為工作負載重新排程提供額外處理能力。 更新完成後,您可以移除多餘的節點。
所需許可權
請確認您已安裝 操作員 或 管理員 IAM 平台存取角色。 如果您不確定自己的存取角色,請在 IBM Cloud 控制台中前往「管理」→「存取權限 (IAM)」→「使用者」,或向您的帳戶管理員詢問。
在 CLI 中使用配置對映更新標準工作者節點
請使用 ConfigMap 對您的經典工作節點執行滾動更新。 透過「ConfigMap」,您可以控制每個區域或區域內,同時最多可有多少個節點處於不可用狀態。 如果您的叢集能接受預設的 20% 不可用率規則,您可以跳過步驟 3 和 4(建立 ConfigMap ),並直接進行步驟 5,以預設行為套用更新。
-
完成必要條件步驟。
-
列出可用的工作者節點,並記下其專用 IP 位址。
ibmcloud ks worker ls --cluster CLUSTER -
檢視工作者節點的標籤。 您可以在 CLI 輸出的 Labels 區段中找到工作者節點標籤。 每個標籤都包含
NodeSelectorKey及NodeSelectorValue。kubectl 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 -
建立配置對映,並且定義工作者節點的無效性規則。 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- 工作者節點必須具有以讓您定義的規則考量的標籤值。
-
在叢集裡建立配置對映。
kubectl apply -f <filepath/configmap.yaml> -
驗證已建立配置對映。
kubectl get configmap --namespace kube-system -
更新工作者節點。
ibmcloud ks worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID -
選用項目:驗證配置對映所觸發的事件,以及發生的所有驗證錯誤。 在 CLI 輸出的 Events 區段中,可以檢閱事件。
kubectl describe -n kube-system cm ibm-cluster-update-configuration -
藉由檢閱工作者節點的 Kubernetes 版本,來確認更新已完成。
kubectl get nodes -
請確認您沒有重複的工作節點。 有時,較舊的叢集會列出具有重複
NotReady狀態。 若要移除重複項目,請參閱疑難排解。
下一步
-
對其他工作者節點儲存區重複更新處理程序。
-
請通知所有在該叢集中工作的開發人員,將其
kubectlCLI 更新 至與 Kubernetes 主分支版本相符。 不支援執行與伺服器版本相差兩個或更多版本的kubectl客戶端,此舉可能會導致意外錯誤。 -
如果 Kubernetes 儀表板未顯示使用率圖形,則會刪除
kube-dashboardPod。
在主控台中更新標準工作者節點
首次設定 ConfigMap 後,您可以透過 IBM Cloud 控制台來更新工作節點。 此主控台會遵循您在《 ConfigMap 》中定義的不可用性規則。
- 請完成 先決步驟,並 設定一個「ConfigMap」,以控制您的工作節點如何進行更新。
- 從 IBM Cloud 主控台 功能表的
,按一下 Containers > Clusters。
- 從叢集頁面中,按一下您的叢集。
- 在「工作節點」索引標籤中,勾選您要更新的每個工作節點旁的核取方塊。 動作列顯示在表格標頭列上方。
- 從動作列中,按一下更新。
若您的叢集中已安裝 Portworx,則必須在已更新的工作節點上重新啟動 Portworx 匣。 如需更多資訊,請參閱 Portworx 中的限制事項。
更新 VPC 工作者節點
VPC 工作節點的更新方式會根據其類型而有所不同。 任何 VPC 工作節點均不支援 ibmcloud ks worker update 指令。 無論在何種情況下,都必須先更新叢集主節點。
- VPC 裸機工作節點與 VPC 虛擬伺服器執行個體 (VSI) 工作節點:已改用
ibmcloud ks worker replace --update(以與主版本保持一致)或ibmcloud ks worker replace(僅更新修補程式)。 舊節點已刪除,並已配置一個新節點。
您可以進行兩種類型的更新:
- 修補程式:將安全修補程式及更新套用至當前 BOM 版本的最新修補程式。 請使用
ibmcloud ks worker replace。 - Major.minor: 將工作節點的
Kubernetes版本升級,使其與主節點保持一致。 您的工作節點版本最多可落後主節點兩個版本(n-2)。請使用ibmcloud ks worker replace --update。
每次更新工作節點時,輪換 CA 憑證 是個好習慣,因為憑證輪換的最長步驟包括重新載入或更換工作節點。
- 更新期間,我的應用程式會發生什麼情況?
- 在已更新的工作節點上執行的應用程式,會被重新排程至叢集中的其他工作節點。 這些工作者節點可能位於其他工作者節點儲存區中。 為避免系統停機,請在開始更新之前,確保您的叢集具備足夠的處理能力來承載工作負載。 如需相關資訊,請參閱 將工作者節點新增至標準叢集 或 將工作者節點新增至 VPC 叢集。
- 在更新過程中,我的工作節點會發生什麼情況?
- 要更換工作節點,請先移除舊的工作節點,然後配置一個新的工作節點,該節點將運行更新後的修補程式或
major.minor版本。 替換工作者節點在相同區域、相同工作者節點儲存區中建立,並且其規格與刪除的工作者節點相同。 然而,替代的工作節點會被指派一個新的私有 IP 位址,並會失去您先前套用至舊工作節點的任何自訂標籤或污點(工作節點池的標籤和污點仍會套用至替代的工作節點)。 - 如果我同時取代多個工作者節點,該怎麼辦?
- 如果您同時取代多個工作者節點,則會同時刪除並取代它們,而不是逐一取代。 在取代工作者節點之前,請確定叢集裡有足夠的容量來重新排程工作負載。
- 如果未建立替換用的工作者節點,該怎麼辦?
- 如果工作者節點儲存區未 啟用自動重新平衡,則不會建立取代工作者節點。
必要條件
在更新 VPC 基礎架構的工作節點之前,請先完成以下先決條件步驟。
對於 VPC VSI 工作節點,系統會刪除該工作節點並以新節點取代。 對於 VPC 裸機工作節點,系統會直接在原處重新載入該節點。 在這兩種情況下,未 儲存於持久性儲存裝置中的 資料都會被永久刪除。 在開始之前,請確認您需要保留的任何資料均已儲存於工作節點之外。
若您的叢集中已部署 Portworx,請依照以下步驟,將 VPC 工作節點更新為使用 Portworx 卷宗, 而非遵循本頁面的步驟。
更新前的準備步驟(請依序完成)
- 請參閱 Kubernetes 的版本資訊,以了解最新的安全性修補程式及所需變更。
- 請針對 《 Kubernetes 版本準備指南》 中標示為「在主分支之前更新」或「在主分支之後更新」的任何變更進行調整。
- 在更新工作節點之前,請先更新主節點。 工作節點的版本不得高於主節點上執行的 API 伺服器版本。
- 請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。
所需許可權
請確認您已安裝 操作員 或 管理員 IAM 平台存取角色。 如果您不確定自己的存取角色,請在 IBM Cloud 控制台中前往「管理」→「存取權限 (IAM)」→「使用者」,或向您的帳戶管理員詢問。
在 CLI 中更新 VPC 工作者節點
請完成下列步驟,以使用 CLI 來更新工作者節點。
-
完成必要條件步驟。
-
可選:透過調整工作節點池的大小,來擴增叢集的處理能力。 工作者節點上的 Pod 可以重新排定,並且這些 Pod 在更新期間繼續在新增的工作者節點上執行。 如需相關資訊,請參閱 將工作者節點新增至標準叢集 或 將工作者節點新增至 VPC 叢集。
-
列出叢集裡的工作者節點,並記下要更新的工作者節點的 ID 和 Primary IP。
ibmcloud ks worker ls --cluster CLUSTER -
更新工作節點。
請使用
worker replace指令,來更新與主版本(master version)相符的修補版本(patch version)或次版本(major.minor)。- 若要將工作節點更新至與主節點相同的
major.minor版本(例如從 1.35 更新至 1.36 ),請加入--update選項。
ibmcloud ks worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update ``` * 若要將工作節點更新至相同 `major.minor` 版本下的最新修補程式版本(例如從 1.35.8_1530 更新至 1.35.9_1533 ),請勿包含 `--update` 選項。 ```sh {: pre} ibmcloud ks worker replace --cluster CLUSTER --worker WORKER-NODE-ID ``` - 若要將工作節點更新至與主節點相同的
-
對必須更新的每個工作者節點重複上述步驟。
-
可選:當已替換的工作節點處於「就緒」狀態後,請調整工作節點池的大小,以符合您所需的叢集容量。 如需相關資訊,請 將工作者節點新增至 VPC 叢集。
若您在 VPC 叢集中執行 Portworx,則 必須手動將 Block Storage for VPC 卷宗掛載至新的工作節點。
在 VPC 裸機工作節點重新載入期間進行韌體更新
當您重新載入 VPC 裸機工作節點時,IBM Cloud 基礎架構會自動檢查該伺服器是否有待處理的韌體更新,並在重新載入過程中一併套用該更新。 無需執行任何額外操作即可觸發韌體更新。
重新載入 VPC 裸機工作節點時,請注意以下事項:
- 重新載入時間延長
- 若在重新載入過程中進行韌體更新,總重新載入時間可能會大幅增加——比一般重新載入時間多出 30 分鐘或更久。 請據此規劃您的維護時段。
- 無法預先查看待處理的更新
- 在您發出 reload 指令之前,無法得知該工作節點是否正在等待韌體更新。
- 資料遺失風險
- 與所有 VPC 裸機工作節點的重新載入程序相同,無論是否進行韌體更新,重新載入過程中都會刪除本機磁碟上的資料。 在重新載入之前,請先備份任何未儲存於持久性儲存裝置上的資料。
- 因韌體更新導致重新載入失敗
- 在某些情況下,韌體更新可能會失敗,導致工作節點進入「
reload_failed」狀態(Failed to reload worker),其狀態詳情為The infrastructure firmware update has failed. (P4056)。 若發生此情況:- 請等待幾分鐘,然後再次執行
ibmcloud ks worker reload --cluster CLUSTER --worker WORKER-NODE-ID來重新載入。 - 如果嘗試 2 至 3 次後錯誤仍未解決,請提交 IBM Cloud 技術支援案件。
- 請等待幾分鐘,然後再次執行
在主控台中更新 VPC 工作者節點
可以在主控台中更新 VPC 工作者節點。 開始之前,請考量 新增工作者節點 至叢集,以協助避免應用程式關閉。
「更新」動作的執行內容取決於工作節點的類型:
- 所有 VPC 工作節點:工作節點已於本次更新中替換為新版本的節點。
- 完成必要條件步驟。
- 從 IBM Cloud 主控台 功能表的
,按一下 Containers > Clusters。
- 從叢集頁面中,按一下您的叢集。
- 在「工作節點」索引標籤中,勾選您要更新的每個工作節點旁的核取方塊。 動作列顯示在表格標頭列上方。
- 從動作列中,按一下更新。
更新規格(機型)
當您需要不同的運算資源時(例如:更多記憶體、額外的 CPU,或是具備 GPU 的機器),請更新工作節點的規格(機器類型)。 更新「flavor」會建立一個具有新「flavor」的全新工作執行者群組,然後移除舊的工作執行者群組。 由於此流程會替換節點,因此工作節點上所有未儲存於持久性儲存裝置的資料都將被永久刪除。
開始之前
- 請登入您的帳戶。 適用的話,請將適當的資源群組設為目標。 設定叢集的環境定義。
- 請確認您需要保留的任何資料,皆已儲存於工作節點外的 持久性儲存裝置 中。 僅儲存於工作節點上的資料將遺失且無法恢復。
- 請確認您已安裝 操作員 或 管理員 IAM 平台存取角色。 如果您不確定自己的存取角色,請在 IBM Cloud 控制台中前往「管理」→「存取權限 (IAM)」→「使用者」,或向您的帳戶管理員詢問。
更新風味
-
列出可用的工作者節點,並記下其專用 IP 位址。
- 列出叢集裡可用的工作者節點儲存區。
ibmcloud ks worker-pool ls --cluster CLUSTER ``` 2. 列出工作者節點儲存區中的工作者節點。 請記下 **ID** 及**專用 IP**。 ```sh {: pre} ibmcloud ks worker ls --cluster CLUSTER --worker-pool WORKER-POOL ``` 3. 取得工作者節點的詳細資料。 在輸出中,記下區域,以及標準叢集的專用及公用 VLAN ID 或 VPC 叢集的子網路 ID。 ```sh {: pre} ibmcloud ks worker get --cluster CLUSTER --worker WORKER-ID ``` -
列出區域中的可用規格。
ibmcloud ks flavors --zone <zone> -
使用新機型建立工作者節點。
- 使用您要取代的工作者節點數目,建立工作者節點儲存區。
- 標準叢集:
ibmcloud ks worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE - VPC 第 2 代叢集:
ibmcloud ks worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
- 標準叢集:
- 驗證已建立工作者節點儲存區。
ibmcloud ks worker-pool ls --cluster CLUSTER ``` 3. 將區域新增至您先前擷取的工作者節點儲存區。 當您新增區域時,會在區域中佈建工作者節點儲存區中所定義的工作者節點,並考慮用於排定未來的工作負載。 如果您要將工作者節點分散在多個區域,請選擇 [標準](/docs/containers?topic=containers-regions-and-zones#zones-mz) 或 [VPC](/docs/containers?topic=containers-regions-and-zones#zones-vpc) 多區域位置。 * 標準叢集: ```sh {: pre} ibmcloud ks 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 ks zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID ``` - 使用您要取代的工作者節點數目,建立工作者節點儲存區。
-
等待部署工作者節點。 工作者節點狀況變更為正常時,部署已完成。
ibmcloud ks worker ls --cluster CLUSTER -
移除舊的執行程序池。 如果您要移除「Classic」裸機方案(此方案按月計費),即使是在當月中途移除,仍需支付該月的全額費用。 VPC 工作單元(包括裸機)均按小時計費。
- 移除具有舊機型的工作者節點儲存區。 移除工作者節點儲存區,會移除所有區域的儲存區中的所有工作者節點。 此處理程序可能需要幾分鐘的時間才能完成。
ibmcloud ks worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER ``` 2. 驗證已移除工作者節點儲存區。 ```sh {: pre} ibmcloud ks worker-pool ls --cluster CLUSTER ``` -
驗證已從叢集裡移除工作者節點。
ibmcloud ks worker ls --cluster CLUSTER -
重複這些步驟以將其他工作者節點儲存區或獨立式工作者節點更新為不同的規格。
如何縮減工作者節點儲存區?
本節說明在縮減規模(例如在更新工作節點後,或執行 ibmcloud ks worker-pool resize 時。 您無需設定此行為——它會自動發生。
當工作節點池中的工作節點數量減少時,系統會根據狀態、健康狀況及版本等數項屬性,優先刪除特定工作節點。
此優先順序邏輯與 autoscaler 附加程式無關。
下表顯示優先刪除工作者節點的順序。
您可以執行 ibmcloud ks worker ls 指令,以檢視表格中列出的所有工作者節點內容。
| 優先順序 | 內容 | 說明 |
|---|---|---|
| 1 | 工作者節點狀況 | 處於無法運作或低功能狀態的工作者節點會優先移除。 此清單顯示從最高到最低優先順序的狀態: provision_failed、deploy_failed、deleting、provision_pending、provisioning、deploying、provisioned、reloading_failed、reloading、deployed。 |
| 2 | 工作者節點性能 | 性能不佳的工作者節點優先於性能良好的工作者節點。 此清單顯示從最高到最低優先順序的性能狀態: critical、warning、pending、unsupported、normal。 |
| 3 | 工作者節點版本 | 在舊版上執行的工作者節點具有較高的刪除優先順序。 |
| 4 | 選擇的安置設定 | 僅適用於在專用主機上執行的工作者節點。 在 DesiredPlacementDisabled 選項設為 true 的專用主機上執行的工作者節點具有較高的刪除優先順序。 |
| 5 | 按字母順序 | 根據上面列出的因素設定工作者節點的優先順序之後,會按字母順序刪除這些節點。 請注意,根據工作者節點 ID 慣例,標準及 VPC 叢集上工作者節點的 ID 會與經歷時間產生關聯,因此會先移除較舊的工作者節點。 |
更新叢集元件
IBM Cloud Kubernetes Service 叢集隨附在佈建叢集時自動安裝的元件,例如 Ingress。 依預設,IBM 會自動更新這些元件。 但是,您可以停用某些元件的自動更新,而個別從主節點和工作者節點手動更新這些元件。
- 有哪些預設元件可以獨立於叢集之外進行更新?
- 您可以選擇停用下列元件的自動更新:
- 是否有某些元件無法獨立於叢集之外進行更新?
- 是。 您的叢集已部署以下受管元件及相關資源,這些內容不得變更,惟為提升特定效能而調整 Pod 規模或編輯 ConfigMap 者不在此限。 如果您嘗試變更下列其中一個部署元件,則當它們與叢集主節點一起更新時會定期還原其原始設定。 不過,請注意,不會更新您所建立且與下列這類元件相關聯的資源:例如,您所建立要由 Calico 部署元件實作的 Calico 網路原則。
calico元件coredns元件ibm-cloud-provider-ipibm-file-pluginibm-keepalived-watcheribm-master-proxyibm-storage-watcherkubernetes-dashboard元件metrics-serverolm-operator和catalog元件 (1.16 以及更新版本)vpn
- 除了預設元件之外,我還能安裝其他外掛程式或附加元件嗎?
- 是的。IBM Cloud Kubernetes Service 提供了其他外掛程式和附加元件,您可以從中選擇,為您的叢集增添功能。 例如,您可能需要 使用 Helm 圖表 來安裝 區塊儲存插件。 或者您可能需要在叢集中啟用由 IBM 管理的外掛程式。 您必須分別更新這些 Helm 圖表與附加元件,方法是依照 Helm 圖表的讀我檔中的說明,或依照 更新受管附加元件的 步驟進行操作。
管理 Fluentd 的自動更新
當您為叢集中的來源建立記錄配置以轉發至外部伺服器時,系統會在您的叢集中建立一個「Fluentd」元件。 若要變更您的記錄或篩選設定,Fluentd 元件必須為最新版本。 依預設,會啟用元件的自動更新。
若要執行以下指令,您必須擁有該叢集的 管理員 IBM Cloud IAM 平台存取角色 權限。
您可以透過下列方式來管理 Fluentd 元件的自動更新。
- 請執行
ibmcloud ks logging autoupdate get --cluster CLUSTER指令,以檢查自動更新是否已啟用。 - 藉由執行
ibmcloud ks logging autoupdate disable指令來停用自動更新。 - 如果停用了自動更新,但您需要對配置進行變更,則有兩個選項:
- 開啟 Fluentd Pod 的自動更新。
ibmcloud ks logging autoupdate enable --cluster CLUSTER ``` * 在您使用包括 `--force-update` 選項的 logging 指令時,強制執行一次性更新。 您的 Pod 已更新至 Fluentd 元件的最新版本,但 Fluentd 今後將不會自動更新。 範例指令 ```sh {: pre} ibmcloud ks 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。 若要將叢集裡已啟用的受管理附加程式更新到最新版本,請參閱更新受管理附加程式。