本頁面提供相關指南,說明如何輕鬆地讓 Google Kubernetes Engine (GKE) 叢集保持在最新狀態,並提供相關建議,協助您依據需求制定升級策略,進而提升環境的可用性和可靠性。您可以根據這項資訊更新叢集,確保穩定性和安全性,同時盡量減少工作負載中斷情形。
或者,如要管理以機群整理的正式環境叢集自動升級作業,請參閱「關於推出作業排序功能管理的叢集升級作業」。
設定多個環境
建議您在軟體更新的交付工作流程中,使用多個環境。多個環境可讓您在正式環境以外測試軟體和基礎架構更新,將風險和不必要的停機時間降到最低。請至少建立一個正式環境,以及一個試產或測試環境。
建議使用下列環境:
環境 | 說明 |
---|---|
生產 | 用於為重要業務應用程式的終端使用者提供即時流量。 |
預備 | 確保從先前環境部署的所有新變更都能正常運作,再將變更部署至正式版。 |
測試 | 用於針對您在正式環境中使用的 GKE 版本,進行效能基準測試、測試及 QA 工作負載。在這個環境中,您可以先測試控制層和節點的升級作業,再於正式環境中執行。 |
開發 | 用於積極開發,且依賴在實際工作環境中執行的相同版本。您可以在這個環境中建立修正檔和增量變更,以便部署至正式版。 |
Canary 版 | 做為次要開發環境,用於測試較新的 Kubernetes 版本、GKE 功能和 API,以便在這些版本升級並成為自動升級目標後,更快推出產品。 |
在發布版本中註冊叢集
Kubernetes 版本經常更新,藉以提供安全性更新、修正已知問題及推出新功能。有了 GKE 發布版本,您就能在穩定性與叢集內部署版本的功能組合之間取得平衡。在發布版本中註冊新的叢集之後,Google 會自動管理該叢集及其節點集區的版本和升級頻率。
如要讓叢集隨時保持在最新狀態,建議您使用下列環境,並在對應的發布管道中註冊叢集:
環境 | 發布版本 | 說明 |
---|---|---|
生產 | 穩定或一般 | 如要確保穩定性及版本成熟度,請為正式工作負載使用穩定版或一般版。 |
預備 | 與正式版相同 | 為確保測試結果能反映正式版升級後的版本,請使用與正式版相同的發布管道。 |
測試 | ||
開發 | ||
Canary 版 | 快速 | 如要測試最新的 Kubernetes 版本,並搶先測試新的 GKE 功能或 API,請使用搶鮮版。如果搶鮮版中的版本升級至您用於正式版的管道,就能縮短上市時間。 |
不適用 | 延長 | 如要讓叢集繼續使用特定子版本一段時間,並在標準支援服務結束後仍能接收安全性修補程式,請使用延長版。詳情請參閱「需要長期支援時,請使用 Extended 管道」。 |
無論您是否在發布版本中註冊叢集,叢集控制層一律都會定期升級。
建立持續升級策略
在發布版本中註冊叢集後,叢集會定期升級至符合該版本品質和穩定度標準的版本。這些更新包括安全性修正和錯誤修正,且每個管道的審查都越來越嚴格:
- 修補程式會逐步推送至所有管道的控制層和節點,並在搶鮮版和一般版管道累積浸泡時間,然後才發布至穩定版管道。
- 系統會先升級控制層,再升級節點,以符合 Kubernetes OSS 政策,即
kubelet
不得高於kube-apiserver
。 - GKE 會根據嚴重程度和重要性,自動將修補程式發布至各個管道。
- 穩定版只會接收重大修補程式。
接收新版 GKE 最新資訊
新版本資訊會發布在主要的 GKE 版本資訊頁面和 RSS 饋給。每個發布管道都有專屬的簡化版版本資訊頁面 (例如「穩定版管道的版本資訊」),其中包含該管道建議使用的 GKE 版本資訊。
如要在升級前主動接收 GKE 升級資訊,請使用 Pub/Sub 並訂閱升級通知。
新版本推出後,您應在該版本成為叢集的自動升級目標前,規劃升級作業。因為如果可用的自動升級目標版本早於或與您已手動升級的叢集版本相同,GKE 就不會自動升級叢集,因此這種做法可在需要時提供更多控制權和可預測性。如要取得特定叢集的自動升級目標,請參閱「取得叢集升級資訊」。
測試及驗證新修補程式和次要版本
無論發布至哪個管道,所有版本都會通過內部測試。不過,由於上游 Kubernetes 和 GKE 會頻繁更新及修補,因此強烈建議您先在測試和/或預先發布環境中測試新版本,再將版本推出至正式環境,尤其是 Kubernetes 次要版本升級。
每個發布版本都提供多個可用版本,包括用於建立叢集的預設版本,以及自動升級目標:
- 新修補程式發布一週後,就會成為自動升級目標。
- 新的 Kubernetes 次要版本會在成為自動升級目標的四週前推出。
GKE 會自動將叢集升級至較新版本。如需進一步控管升級程序,建議您提前升級至可用版本。如果叢集已手動升級至自動升級目標,GKE 不會再次自動升級。
建議您採取下列方法,自動化及簡化升級程序:
- 使用可用版本的試前環境。
- 設定叢集升級通知,讓團隊瞭解可測試及認證的新版本。
- 實際工作環境已訂閱發布管道,並使用您在試前環境中測試過的版本。
- 逐步將新版本推出至正式環境叢集。舉例來說,如果有多個正式版叢集,逐步升級計畫會先將部分叢集升級至可用版本,其餘叢集則維持現有版本,接著再升級一小部分叢集,直到所有叢集都升級完畢為止。
下表摘要說明發布事件和建議動作:
事件 | 建議做法 |
---|---|
新版本 X 已在管道中推出。 | 手動升級測試叢集,並測試新版本是否符合資格。 |
版本 X 會成為叢集子版本的自動升級目標。 | GKE 開始自動升級至自動升級目標。 建議您在車隊升級前,先升級正式版。 |
GKE 開始自動升級叢集。 | 允許叢集自動升級,或使用維護作業排除時段延後升級。 |
修補程式版本的升級策略
以下是修補程式版本的建議升級策略,假設情境如下:
- 所有叢集都訂閱了穩定版。
- 新版本會先推出至測試叢集。
- 正式環境叢集會自動升級至新的自動升級目標。
- 定期監控 GKE 的新版本。
時間 | 事件 | 該怎麼辦? |
---|---|---|
T - 1 週 | 推出新的修補程式版本。 | 升級預先發布環境。 |
T | 修補程式版本會成為自動升級目標。 | 建議您提前升級正式版控制層,以提高可預測性。 |
T | GKE 會開始將控制層升級至自動升級目標。 | 建議您提前升級正式環境節點集區,以提高可預測性。 |
T + 1 週 | GKE 會開始將叢集節點集區升級至自動升級目標。 | GKE 會自動升級叢集,但會略過手動升級的叢集。 |
新子版本的升級策略
針對新的次要版本,建議採用下列升級策略:
時間 | 事件 | 該怎麼辦? |
---|---|---|
T - 3 週 | 推出新的次要版本 | 升級測試控制層 |
T - 2 週 |
| |
T - 1 週 | 升級成功後,請考慮提前升級正式環境節點集區。 | |
T | 子版本會成為自動升級目標。 | |
T | GKE 會開始將叢集控制層升級至自動升級目標。 | 如果需要更多測試或緩解措施,才能推出正式版,請建立排除時間範圍。 |
T + 1 週 | GKE 會開始將叢集節點集區升級至自動升級目標。 | GKE 會自動升級叢集,並略過手動升級的叢集。 |
在升級期間減少現有工作負載的中斷情形
為確保叢集正常運作及業務持續性,請務必為叢集套用最新的安全性修補程式和錯誤修正。定期更新可保護工作負載,避免安全漏洞和故障問題。
設定維護期間和排除時段
如要提高升級作業的可預測性,並確保系統在服務期間的離峰時段執行升級作業,您可以建立維護期間,控管控制層和節點的自動升級作業。GKE 會遵守維護期間。也就是說,如果升級程序超出定義的維護期間,GKE 會嘗試暫停作業,並在下一個維護期間繼續執行作業。
GKE 會在多天內推出新版本,並在不同地區自動升級叢集控制層和節點。推出作業通常會持續四天以上,並包含緩衝時間,以便觀察及監控問題。在多叢集環境中,您可以為每個叢集使用不同的維護時段,依序在叢集推出作業。舉例來說,您可能會想為每個叢集設定不同的維護期間,控管不同區域的叢集何時進行維護。
另一個可減少服務中斷的工具是維護排除條件,尤其是在業務需求量大的期間。 使用維護作業排除項目,禁止系統在這些期間自動執行維護作業;您可以在新叢集或現有叢集上設定維護作業排除項目。您也可以搭配升級策略使用排除條件。 舉例來說,如果測試或預先發布環境因升級而失敗,您可能想延後升級正式環境叢集。
設定容許的服務中斷
您可能熟悉 Kubernetes 中的副本概念。副本可確保工作負載的備援,進而提升效能和回應速度。設定後,備用資源會控管隨時執行的 Pod 備用資源數量。不過,在維護期間,Kubernetes 會移除基礎節點 VM,這可能會減少副本數量。如要確保工作負載有足夠的副本數量供應用程式使用 (即使在維護期間也一樣),請使用 Pod 中斷預算 (PDB)。
在 Pod 中斷預算中,您可以定義可終止的 Pod 數量 (或百分比),即使終止 Pod 會使目前的副本數量低於所需值也沒關係。這樣一來,您就不必等待遷移的 Pod 恢復正常運作,因此可加快節點排空程序。而是會根據 PDB 設定,從節點中排空 pod,讓部署作業在其他可用節點上部署缺少的 Pod。設定 PDB 後,如果 Pod 數量等於或少於設定的上限,GKE 就不會關閉應用程式中的 Pod。GKE 最多會遵循 PDB 60 分鐘。
控管節點集區升級作業
使用 GKE 時,您可以選擇節點升級策略,決定如何升級節點集區中的節點。根據預設,節點集區會使用大量升級。使用節點數擴充升級時,GKE 節點集區的升級程序會重建節點集區中的每個 VM。系統會以滾動式更新方式,使用新版本 (升級後的映像檔) 建立新的 VM。因此,您必須關閉舊節點上執行的所有 Pod,並將 Pod 移至新節點。您的工作負載可以充分的備援 (副本) 執行,而且您可以視需要依賴 Kubernetes 移動及重新啟動 Pod。不過,暫時減少副本數量仍可能對業務造成干擾,且在 Kubernetes 能夠再次達到所需狀態 (即滿足所需副本的最低數量) 前,可能會降低工作負載效能。如要避免這類中斷情形,請使用突增升級。
啟用升級緩衝區後,GKE 會先確保升級所需的資源 (機器),然後建立新的升級節點,接著排除舊節點,最後關閉舊節點。這樣一來,預期容量在升級過程中就不會受到影響。
如果叢集規模較大,升級程序可能需要較長時間,您可以一次升級多個節點,加快升級完成時間。使用節點數擴充升級搭配 maxSurge=20
和 maxUnavailable=0
,指示 GKE 一次升級 20 個節點,且不使用任何現有容量。
需要長期支援時,請使用延長版
如要讓叢集繼續使用子版本一段時間,請按照最佳做法,在延長版註冊叢集。透過這個管道,GKE 支援子版本約 24 個月。詳情請參閱「透過延展管道取得長期支援」。
為充分發揮這個管道的效益,建議您遵循下列最佳做法。部分最佳做法需要手動操作,包括手動升級叢集,以及變更叢集的發布管道。請參閱下列支援情境,以及不應使用擴充頻道的情況。
暫時延長使用特定子版本
如果需要將叢集暫時保留在次要版本,時間超過 14 個月的標準支援期限 (例如為了減少使用下一個次要版本中移除的已淘汰 API),請按照下列程序操作。您可以暫時將叢集從其他發布管道移至延長版管道,以便在準備升級至下一個子版本時,繼續接收安全性修補程式。準備好升級至下一個子版本時,請手動升級叢集,然後將叢集移回原始發布管道。
每年升級 1 到 2 次子版本
如要在叢集升級至新子版本時,盡量減少中斷時間,同時接收部分新功能,請按照下列步驟操作:
- 在延長版管道註冊叢集。
- 每年執行 1 到 2 次連續的次要版本升級。舉例來說,從 1.30 升級至 1.31,再升級至 1.32。
這個程序可確保叢集維持在可用的次要版本,並接收新次要版本的功能,但只有在您決定叢集已準備就緒時,才會升級次要版本。
不應使用擴展管道的情況
如要使用「延長版」欄的預期用途,必須手動操作。以下情境說明使用延長版,但未主動管理叢集子版本會造成的後果。
不採取任何行動,以相同頻率接收次要升級
如要讓叢集永久使用特定子版本,請在延長版註冊叢集,然後不必採取任何行動。所有子版本最終都會停止支援,GKE 會自動將叢集從不受支援的子版本升級。因此,GKE 會將這個叢集從一個不受支援的子版本升級至另一個即將不受支援的子版本,平均約每 4 個月升級一次。也就是說,叢集接收子版本升級的頻率與其他發布管道相同,但會較晚收到新功能。
檢查清單摘要
下表摘要說明建議的升級策略工作,可讓 GKE 叢集輕鬆保持在最新狀態:
最佳做法 | Tasks |
---|---|
設定多個環境 | |
在發布版本中註冊叢集 | |
建立持續升級策略 | |
減少現有工作負載的中斷情形 |
後續步驟
- 觀看 Google Cloud Next 2020 影片,瞭解如何在不確定時期和僅限數位業務的環境中,透過 GKE 確保業務持續運作。
- 觀看「GKE 升級最佳做法」。
- 進一步瞭解發布版本。
- 瞭解 GKE 的版本管理和自動升級。