開發與測試具備韌性的應用程式
瞭解 Red Hat OpenShift on IBM Cloud 如何處理控制平面維護、維護更新如何影響正在執行的工作負載，以及如何測試並規劃應用程式架構以實現高韌性。
叢集架構與職責概述
Red Hat OpenShift on IBM Cloud 是一項託管的 Kubernetes 服務。 在每個叢集中，架構被劃分為兩個平面，各自 [擁有明確的責任歸屬](/docs/openshift?topic=openshift-responsibilities_Kubernetes Service)：
- 控制平面
- 由 IBM 管理。 包含 Kubernetes API 伺服器、etcd、控制器管理員及排程器。
- 資料平面
- 由您自行管理。 包含工作節點、應用程式 Pod、儲存配置以及網路附加元件。
| 飛機 | 管理者 | 元件 |
|---|---|---|
| 控制平面 | IBM | API 伺服器、etcd、控制器管理器、排程器 |
| 資料平面 | 您 | 工作節點、應用程式 Pod、儲存、網路附加元件 |
IBM 定期為控制平面套用修補程式版本更新。 這些修補程式旨在解決安全漏洞、修正關鍵錯誤，並確保叢集持續符合 IBM 的安全要求。 了解這些修補程式是如何套用的，有助於您針對應用程式架構做出明智的決策。
在雲端環境中運行的應用程式會面臨各種動態狀況，包括短暫的網路中斷、主機基礎架構維護，以及第三方服務的延遲。 在各種條件下進行韌性設計與測試，可確保生產工作負載的可靠性。
IBM 如何套用控制平面修補程式
每個 Red Hat OpenShift on IBM Cloud 叢集的控制平面元件均以高可用性（HA）配置運作。 每個元件的多個副本皆分佈於獨立的可用區域中，以確保控制平面上不存在單一故障點。
當套用修補程式升級時，IBM 會採用滾動式重建策略。 複本會依序進行更新：
- 在整個升級過程中，Kubernetes API 伺服器始終可連線。
- 叢集運作（例如排程、自動擴展及狀態檢查）將持續進行，不會中斷。
- IBM 提供一個平穩關機延遲，以便在移除 Pod 之前，讓正在進行中的連線得以完成。
控制平面修補程式的升級設計，旨在確保不會對在資料平面上執行的使用者應用程式造成任何影響。 在此過程中，您的 Pod、服務和工作負載將持續在工作節點上正常運作。
控制平面更新期間對工作負載的影響
由於資料平面由使用者自行管理，因此 IBM 控制平面修補程式不會重新啟動、重新排程或修改您的工作節點或正在執行的應用程式 Pod。
然而，那些頻繁直接呼叫 Kubernetes API 的應用程式或工具（例如自訂控制器、操作員、CI/CD 管線，或是監控叢集狀態的監控代理程式），必須能妥善處理 API 的暫時性錯誤。 請遵循 Kubernetes 的通用最佳實務：
- 針對所有 API 呼叫，實作採用指數退避法的重試邏輯。
- 請避免在沒有重新連線邏輯的情況下，依賴與 API 伺服器的持久性開啟連線。
透過模擬情境來測試應用程式的韌性
為了建立對應用程式韌性的信心，應在預定維護或意外中斷發生之前，於非生產環境中模擬生產環境的故障狀況。
在任何模擬過程中，請監控您的應用程式，留意可能出現的中斷跡象：pod 意外重新啟動、錯誤日誌激增、回應時間變慢，或客戶端請求遭丟失。 利用這些觀察結果來優化重試邏輯、調整狀態偵測機制，或調整複本拓撲。
執行叢集管理指令（例如「主節點重新整理」或「工作節點池調整大小」）需要具備「管理員」或「操作員」級別的平台存取權限，以及叢集管理服務的權限。 如果您是無法存取叢集基礎架構的應用程式開發人員，請與您的叢集管理員協調，以執行這些模擬。
透過控制平面刷新來模擬控制平面連接
觸發控制平面刷新，將啟動 IBM 在修補程式升級過程中所採用的滾動更新程序。 此測試旨在驗證您的應用程式與工具能否順利處理控制平面複本的轉換。
-
在您的叢集上觸發控制平面刷新。
ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID -
請確認您的應用程式能持續不中斷地處理流量，且面向客戶的端點仍能正常回應。
透過新增與移除工作節點來模擬網路路由更新
新增或移除工作節點會促使 Kubernetes 在整個叢集中更新內部網路路由邏輯，藉此模擬在基礎設施維護期間節點循環更換時所發生的狀況。
-
調整您的工作者群組規模，以新增一個臨時工作者節點。
ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME --size-per-zone NEW_SIZE -
在新工作節點初始化並加入叢集網路期間，請監控您的應用程式日誌及回應延遲。
-
測試完成後，請移除測試工作節點。
若要針對性地移除在步驟 1 中建立的特定工作節點，請執行以下操作：
- 在刪除工作節點之前，請先將其隔離並排空，以確保工作負載能順利重新排程。
oc cordon NODE_NAME oc drain NODE_NAME --ignore-daemonsets --delete-emptydir-data- 從叢集中刪除該工作節點。
ibmcloud oc worker rm --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID- 請使用
作為另一種較不具針對性的做法，您可以直接使用步驟 1 中的
工作負載韌性的最佳實踐
應用程式在發生叢集事件時的韌性，取決於您如何設計和配置工作負載。 請將以下建議做法套用至您的 Kubernetes 工作負載規格：
針對每個工作負載執行多個副本
單一副本的部署無法容忍中斷。 請將 spec.replicas 設定為至少 2 （生產環境的工作負載建議設定為 3 或更高），以確保單一 Pod 的損失或重新排程不會導致系統停機。
將複本分佈於各區域及工作節點
請在部署設定中設定「topologySpreadConstraints」或 pod 反親和性規則。 將 Pod 分散部署於多個可用區域和工作節點，可避免因單一區域發生中斷或節點維護事件，而導致所有副本同時停機。
設定 Pod 中斷預算 (PDB)
PodDisruptionBudget 資源會指定在自發性中斷（例如節點清空或叢集更新）期間，必須保持可用的 Pod 最低數量或百分比。 針對每個關鍵工作負載定義一個 PDB，以防止管理操作將超過應用程式所能承受的數量之 Pod 從系統中移除。
定義就緒與活躍性探測
在容器規格中設定就緒與存活探測：
- 就緒性探測： 確保 Kubernetes 僅將流量導向已初始化且準備好處理請求的 Pod。
- 存活檢測： 啟用 Kubernetes，以便自動重新啟動進入死鎖或非正常狀態的容器。
設定適當的資源請求與限制
請為每個容器指定切合實際的 CPU 和記憶體需求與限制。 這些請求可確保 Kubernetes 排程器將 Pod 配置在具備足夠容量的節點上。 限制機制可防止單一容器消耗過多資源，進而影響同一工作節點上同處的工作負載。
實作優雅關機處理機制
當一個 Pod 被終止時，Kubernetes 會在傳送 SIGKILL 之前，先傳送一個 SIGTERM 訊號。 請設計您的應用程式，使其能擒獲 SIGTERM`` 錯誤、停止接受新連線、完成進行中的交易，並乾淨俐落地退出。 請在您的 Pod 規格中設定適當的 terminationGracePeriodSeconds ，以讓您的應用程式有足夠的時間將流量排空。
避免依賴與 API 伺服器之間的長期連線
Kubernetes 監控請求與串流連線（例如 oc exec、端口轉發或自訂 API 客戶端監控）會直接連線至特定的控制平面複本。 當該複本在修補程式升級期間進行循環時，連線便會關閉。 工作負載和工具必須實作採用指數退避機制的自動重新連線邏輯。
使用重試邏輯與斷路器
當您的應用程式與 Kubernetes API、外部資料庫或下游微服務進行互動時，請實作採用指數退避與抖動機制的重試邏輯。 利用斷路器模式，以防止在上游或下游依賴項暫時不可用時發生連鎖故障。
下一步
- 請參閱「規劃應用程式部署」一文，以進一步了解工作負載類型及「Kubernetes」物件。
- 透過完整的配置範例，了解如何 將應用程式部署至叢集。
- 請參閱《 高可用性與災難復原 》，了解叢集層級的可用性策略。