建立高可用叢集策略

使用 Red Hat® OpenShift® on IBM Cloud® 設計標準叢集的應用程式最大可用性及容量。 使用內建的功能，讓您的群集更具高度可用性，並在群集中的元件發生故障時，保護您的應用程式免於停機。 但弄清楚叢集設定必須如何才能支援您的工作負載並不是一門精確的科學。 您可能需要測試不同的配置並進行調整。

高可用性 (HA) 是 IT 基礎架構的核心規範，即使網站發生部分或全部故障後，仍可維持應用程式正常運作。 高可用性的主要目的是消除 IT 基礎架構中的潛在故障點。 例如，您可以新增備援並設定失效接手機制，來準備好應對系統故障的情況。 看 如何IBM Cloud確保高可用性和災難復原。

若要開始規劃叢集並調整叢集大小，請在建立叢集之前查看這些決策點。

決定要創建多少個集群

若將應用程式分散到多個工作者節點、區域及叢集，使用者遇到應用程式運作中斷時間的可能性就越低。 內建功能（例如負載平衡及隔離）可提高對於潛在主機、網路或應用程式失敗的備援。

集群高可用
集群高可用

您建立的叢集數量取決於您的工作負載、公司政策和法規、業務要求、您與客戶簽訂的服務等級協定、您想要消耗的資源以及您想要使用運算資源執行的操作。

  • 多重群集：多重集群的管理通常較為複雜，但可以協助您達成下列重要目標。

    • 符合需要您隔離工作負載的安全原則。
    • 測試您的應用程式在不同版本的 Red Hat OpenShift 或其他群集軟體（例如 Calico ）中的執行狀況。
    • 為不同地理區域的使用者實現更高的效能。
    • 透過在叢集實例層級配置存取權限（而不是在命名空間層級自訂和管理多個 RBAC 策略），簡化使用者存取以控制叢集內的存取。
    • 保持較低的工作節點數量。 擴展虛擬機器的網路頻寬約為 1000 Mbps。 如果您需要一個群集中有數百個工作節點，您可以將配置分拆成多個節點較少的群集，或者訂購裸金屬節點。
    • 允許更多的數量 服務整合 等5000多個服務。
    • 為應用程式提供更高的可用性。 類似於在多區群集中使用 3 個區域，您可以透過跨區設定三個群集，為您的應用程式提供更多可用性。
    • 購買較小型的機器來處理您的工作量，以降低成本。

  • 一個叢集有更多工作節點：更少的叢集可以幫助您減少固定資源的營運工作量和每個叢集的成本。 您可以將工作池新增至一個叢集，以便為您的應用程式和服務元件提供不同類型的運算資源，而不是建立更多叢集。 當您開發應用程式時，所使用的資源位在相同的區域中，或在多區域中緊密地連接，因此您可以針對延遲、頻寬或相關故障做出一些假設。 然而，當您只有一個群集時，使用命名空間、資源配額和標籤來組織群集就變得更加重要。

確定需要多少位置

叢集可以在單一位置或多個位置的工作節點之間分配副本。 此選擇可能會影響下一節中可用的叢集類型。

將工作負載分佈到三個區域可確保應用程式在某個區域不可用時具有高可用性。 您必須將工作節點均勻分佈於所有三個可用區域，方能符合高可用性配置的 服務等級 IBM Cloud 協議(SLA)。

區域故障會影響所有實體運算主機和 NFS 儲存空間。 故障包括電源、散熱、網路功能或儲存空間中斷，以及洪水、地震和颶風這類自然災害。 為了防止區域故障，您必須在兩個不同的區域中擁有由外部負載平衡器進行負載平衡的集群，在多區域位置創建一個集群，將主伺服器分佈在多個區域中，或者考慮在另一個區域中設定第二個集群。

多區域叢集

經典 虛擬私有雲

多區域叢集將工作負載分佈到多個工作節點和區域，從而針對區域故障提供額外的保護。 工作節點自動部署為跨多個區域的三個副本。 如果整個區域發生中斷，您的工作負載將被調度到其他區域中的工作節點上，從而保護您的應用程式免受中斷影響。

每一個地區都有設定高可用性的負載平衡器，可從地區專用的 API 端點進行存取。 負載平衡器會將送入及送出要求遞送至地區區域中的叢集。 整個地區故障的可能性很低。 不過，若要說明此故障，您可以在不同地區設定多個叢集，然後使用外部負載平衡器連接它們。 如果整個區域發生故障，其他區域的群集可以接管工作負載。

例如，您部署多專區集群 在都會區，例如 sydney，三個副本自動分佈在地鐵的三個區域，例如 au-syd-1,au-syd-2，和 au-syd-3。 如果一個區域中的資源停止執行，叢集工作負載仍會繼續在其他區域中執行。

多地區叢集需要數個「雲端」資源，視您的應用程式而定，它們可能既複雜又昂貴。 檢查您是否需要多地區設定，或您是否可以容忍潛在的服務中斷。 如果您要建立多區域群集，請確保您的應用程式和資料可以託管在另一個區域，而且您的應用程式可以處理全域資料複製。

與負載平衡器連結的多個集群

經典 虛擬私有雲

為了保護您的應用程式免受主故障的影響，您可以在一個區域內的不同可用區中建立多個集群，並將它們與全域負載平衡器連接。 如果您必須在僅具有一個區域的經典資料中心中配置集群，但您仍然希望獲得多區域可用性的優勢，則此選項非常有用。

要將多個集群與全域負載平衡器連接，必須使用公共網路連接設定集群，並且您的應用程式必須透過 Ingress、路由 或 Kubernetes負載平衡器服務 公開。

若要在多個叢集之間平衡工作負載，您必須透過 Cloud Internet Services (CIS)設定全域負載平衡器，並將路由器服務或負載平衡器服務的公用 IP 位址新增至您的網域。 新增這些 IP 位址，即可在叢集之間遞送送入資料流量。

若要讓廣域負載平衡器偵測是否有一個叢集無法使用，請考慮將以 Ping 為基礎的性能檢查新增至每個 IP 位址。 當您設定此檢查時，DNS 提供者會定期對您新增至網域的 IP 位址執行連線測試。 如果有一個 IP 位址變成無法使用，則不會再將資料流量傳送至此 IP 位址。 但是，Red Hat OpenShift 不会自动在可用群集中的 Worker 节点上重新启动来自不可用群集的 pod。 如果您希望 Red Hat OpenShift 自動重新啟動可用群集中的 Pod，請考慮設定多區群集。

單一區域叢集

經典

工作節點分佈在單一區域內的不同實體主機上。 此選項可防止某些中斷（例如在主更新期間），並且更易於管理。 但是，如果整個區域出現中斷，它不會保護您的應用程式。 如果您後來發現可用性有問題，部署在某些位置的單專區叢集稍後可以轉換為多專區叢集。

如果您的群集是以單一區域中的所有工作節點來建立，則經典群集的 Kubernetes 主機具有高可用性，並為您的主 API 伺服器、etcd、排程器和控制器管理員提供獨立的實體主機，以防止中斷，例如在主機更新期間。 您可以為單區域叢集新增額外的工作程序節點，以提高可用性並在一個工作程序節點發生故障時增加保護。

如果一個工作節點發生故障，可用工作節點上的應用程式執行個體將會繼續運作。Red Hat OpenShift自動從不可用的工作節點重新調度 Pod，以確保應用程式的效能和容量。 若要確保 Pod 均勻地分佈在工作人員節點上，請執行 Pod 親和性。

選擇集群類型

可供您使用的工作者節點規格和隔離層次取決於要使用的容器平台、叢集類型、要使用的基礎架構提供者以及要建立叢集的 Red Hat OpenShift on IBM Cloud 位置。 您可以選擇經典、VPC 或Satellite集群。 您需要的集群類型取決於您對集群數量、位置所做的決定。

標準叢集中工作節點的硬體選項
標準叢集中工作節點的硬體選項

專有網路集群
可以使用標準基礎架構或專用主機上的虛擬工作節點來設定工作節點。 如果速度是您的重要考慮因素，VPC 叢集可能是最佳選擇。
Satellite叢集
工作節點可以配置在雲供應商的虛擬機器上，例如 AWS, Azure, GCP 等。 也可以使用您自己的本地基礎架構來配置工作節點。
經典集群
可以在虛擬和裸機工作節點上建立工作節點。 如果需要更多本端磁碟，則還可以選擇為軟體定義的儲存空間解決方案（例如，Portworx）設計的其中一個 Bare Metal Server 規格。

為叢集選擇作業系統

您可用的作業系統取決於您選擇的叢集類型。

Red Hat Enterprise Linux CoreOS (RHCOS)
虛擬私有雲 Satellite
適用於在4.15及更高版本中建立的叢集。 Red Hat Enterprise Linux CoreOS (RHCOS) 專為 Red Hat OpenShift Container Platform (OCP) 而設計。 在利用 Red Hat Enterprise Linux (RHEL) 的穩定性與安全性的同時，RHCOS 是輕量且最小的，專注於有效率且大規模地執行容器化工作負載。 由於它由 RHEL 元件組成，因此您可以獲得與 RHEL 相同等級的安全性，此外還具有更小的以容器為中心的佔用空間、只讀檔案系統、基於映像的部署等額外優勢。 如需 RHCOS 的概覽，請參閱 Red Hat Enterprise Linux CoreOS(RHCOS)。 VPC 叢集的 RHCOS 工作節點僅適用於在支援 RHCOS 的版本中建立的叢集。 從不支援 RHCOS 的版本升級到支援 RHCOS 的版本的叢集無法使用 RHCOS Worker。

從版本 4.18 開始，RHEL Worker 節點已不再適用於 VPC 叢集。 對 RHEL Worker 節點的支援隨著版本 4.22 的發行而終止。 如需詳細資訊，請參閱 RHEL deprecation for VPC 群集。

Red Hat Enterprise Linux (RHEL) 版本 9
經典 虛擬私有雲
適用於在 4.16 及更新版本中建立的群集。 Red Hat Enterprise Linux on IBM Cloud 為企業提供強大且可擴充的環境，以安全性為考量，並針對關鍵工作負載量身打造。 組織可透過 Red Hat Enterprise Linux 平台與 IBM Cloud 的基礎架構結合，存取高可用性、災難復原和簡化管理功能。 如需 RHEL 9 的概述，請參閱為 何在 IBM Cloud 上執行 Linux?
Red Hat Enterprise Linux (RHEL) 版本 8
經典 虛擬私有雲
適用於在 4.15 及更早版本中建立的群集。 RHEL 8 於 2024 年 5 月 31 日達到壽命終點。 如需詳細資訊，請參閱 Red Hat Enterprise Linux 8 生命週期。

定義叢集命名策略

考慮為叢集提供在您帳戶中的資源群組和地區之間唯一的名稱，以避免命名衝突。 集群創建後無法重命名。

決定每個叢集有多少個工作節點

您為叢集設定的可用性等級，將影響您在 IBM Cloud 高可用性服務等級協議條款 下的保障範圍。 例如，要獲得 SLA 條款下的完整 HA 覆蓋，您必須設定一個總共至少有 6 個工作節點的多區域集群，每個區域有兩個工作節點，均勻分佈在三個區域。

叢集裡的工作者節點總數決定了可用於叢集裡應用程式的運算容量。 您可以在群集中設定多個 Worker 節點，以在 Worker 節點故障時保護您的設定。 工作站節點故障可能包括硬體中斷，例如電源、冷卻或網路，以及 VM 本身的問題。

  • 多區群集 經典 VPC：計劃每個區域至少有兩個工作節點，因此三個區域共有六個節點。 此外，將叢集的總容量計劃為至少等於總工作負載所需容量的 150%，這樣，如果一個區域停止運作，您仍有資源可用於維持工作負載。

  • 單一區域群集計劃在群集中至少有三個工作站節點。 此外，需要在叢集裡提供可容納 1 個額外節點的 CPU 和記憶體容量。 如果您的應用程式所需的資源少於 Worker 節點上可用的資源，您或許可以限制部署到一個 Worker 節點的 Pod 數量。

請牢記：

  • 你可以嘗試一下 集群自動縮放器 確保您始終有足夠的工作節點來滿足您的工作負載。
  • Kubernetes 會限制您在叢集裡可以有的工作者節點數目上限。 檢閱 Worker 節點和 Pod 配額，以瞭解更多資訊。

選擇工作節點風格

Worker 節點是在實體硬體上執行的 VM。 工作者節點規格說明了佈建工作者節點時取得的運算資源，例如 CPU、記憶體和磁碟容量。 相同規格的工作者節點會分組成工作者節點儲存區。

當您選擇叢集類型時，您已經考慮過工作節點風格位置和機器類型如何影響您的決策。 當您在工作節點風格之間進行選擇時，請考慮以下事項。

  • 租賃：根據您需要的硬體隔離級別，虛擬工作節點可以設定為由多個共享IBM客戶（多租戶）或專用於您的（單一租戶）節點。 裸機機器始終設定為專用機器。 當您決定共用或專用節點時，您可能需要向法律部門查詢，討論您的應用程式環境所需的基礎結構隔離層級與合規性。

    • 共用：所有部署到相同實體硬體的虛擬機器共享 CPU 和記憶體等實體資源。 為了確保每個虛擬機器都可以獨立執行，虛擬機器監視器（也稱為 Hypervisor）會將實體資源區隔為隔離實體，並將它們當成專用資源配置至虛擬機器（Hypervisor 隔離）。 因為基礎硬體的成本是由多個客戶分攤，所以共用節點成本通常會比專用節點成本低。
    • 投入的：所有實體資源僅供您使用。 您可以將多個工作者節點部署為相同實體主機上的虛擬機器。 與多方承租戶設定類似，系統管理程序也會確保每個工作者節點在可用實體資源中獲得應有的份額。

  • 機器的種類：您有多種機器類型可供選擇。

    • 虛擬機：為了獲得更大的靈活性、更快的配置時間、更多的自動可擴展功能以及更具成本效益的價格，請使用 VM。 您可以將 VM 用於大部份一般用途的使用案例，例如測試和開發環境、暫置和正式作業環境、微服務以及商務應用程式。 然而，在效能上會有所取捨。

    • 裸機（物理）機器：如果您需要針對資料或 RAM 密集型工作負載進行高效能運算，請考慮使用裸機工作節點建立經典叢集。 由於您可以完全控制工作負載的隔離和資源消耗，因此您可以使用裸機來實現環境的 HIPAA 和 PCI 合規性。 裸機可讓您直接存取機器上的實體資源，例如記憶體或 CPU。 此設定可免除虛擬機器 Hypervisor，該 Hypervisor 將實體資源配置給在主機上執行的虛擬機器。 相反，裸機的所有資源都專門用於工作人員，因此您不需要擔心「吵鬧的鄰居」會分享資源或降低效能。 實體規格的本端儲存空間多於虛擬規格，而且有些實體機型具有 RAID 可用來增加資料可用性。 Worker 節點上的本機儲存只用於短期處理，當您更新或重新載入 Worker 節點時，主磁碟和輔助磁碟會被抹除。 實體機器僅適用於傳統群集，不支援 VPC 群集。

      裸機伺服器按月計費。 如果您在月底之前取消裸機伺服器，則會向您收取該月整個月的費用。 當您訂購或取消裸機伺服器之後，即會在 IBM Cloud 基礎架構帳戶中手動完成此處理程序。 因此，可能需要多個營業日才能完成。

    • SDS 機器：軟體定義儲存 (SDS) 類型具有用於實體本機儲存的附加原始磁碟。 與主要和輔助本機磁碟不同，這些原始磁碟不會在 Worker 節點更新或重新載入時被抹除。 由於資料與運算節點會並存，所以 SDS 機器很適合高效能工作負載。 軟體定義儲存風味僅適用於傳統群集，在 VPC 群集中不受支援。

      由於您可以完全控制工作負載的隔離和資源消耗，因此您可以使用 SDS 電腦來實現您的環境的 HIPAA 和 PCI 合規性。

      一般您會在下列情況使用 SDS 機器：

      • 如果您使用 SDS 附加元件，例如 Portworx，請使用 SDS 機器。
      • 如果您的應用程式是 StatefulSet 需要本機儲存，您可以使用 SDS 機器，並佈建 Kubernetes 本機持久卷。
      • 如果您有需要額外原始本端儲存空間的自訂應用程式。

  • 成本：一般而言，您的密集型工作負載較適合在裸金屬實體機器上執行，而對於符合成本效益的測試和開發工作，您可能會選擇共用或專用硬體上的虛擬機器。

  • 地點：決定您想要在哪些位置建立叢集。 在您想要的位置，它還可能會告知您需要多少個叢集或叢集類型。 例如，如果您知道您需要的位置位於蒙特利爾，那麼這有助於縮小您的選擇範圍。 查看可用的 地點。

  • 大小：較大的節點可能比較小的節點更具成本效益，特別是對於那些在高效能機器上處理時可以提高效率的工作負載而言。 但是，如果一個大型工作站發生故障，您需要確定群集有足夠的容量，可以安全地將所有工作負載 Pod 重新排程到群集中的其他工作站上。 較小的工作節點可以幫助您安全地擴展。 進一步瞭解容量。

  • GPU：您可以使用 GPU 機器來加快運算密集型工作負載（例如 AI、機器學習、推理等）所需的處理時間。

  • 儲存：每個 VM 都附有磁碟，用於儲存 VM 執行所需的資訊，例如作業系統檔案系統、容器執行時間和 kubelet。 工作者節點上的本端儲存空間僅適用於短期處理，而且在您刪除、重新載入、取代或更新工作者節點時，會清除儲存空間磁碟。 此外，標準及 VPC 基礎架構在磁碟設定時不同。

    • 標準 VM：標準 VM 具有兩個連接的磁碟。 主儲存磁碟有 25 GB 用於作業系統檔案系統，而輔助儲存磁碟有 100 GB 用於容器執行時間和 kubelet 等資料。 為了可靠起見，主要和輔助儲存卷是本機磁碟，而不是儲存區域網路 (SAN)。 可靠性優點包括將位元組序列化到本端磁碟時的更高傳輸量，以及減少檔案系統由於網路故障而造成的退化。 輔助磁碟預設已加密。
    • VPC 運算虛擬機器：VPC 虛擬機器有一個主磁碟，是透過網路連接的區塊儲存卷。 儲存層未與其他網路層區隔，而且會在相同的網路上遞送網路及儲存空間資料流量。 主要儲存空間磁碟用於儲存資料（例如 OS 檔案系統、容器運行環境及 kubelet），而且依預設會進行加密。 對於 VPC 集群，您也可以在工作節點上配置輔助磁碟。 此可選磁碟已在您的帳戶中配置，您可以在 VPC 控制台中查看它們。 這些磁碟的費用與每個工作人員的成本分開，並在帳單上顯示為不同的行項目。 這些輔助卷也計入您帳戶的配額使用量。 為了防止預設 pod 驅逐，10%Kubernetes資料盤（經典為輔助盤，VPC為主啟動盤）是為系統元件保留的。

    在有狀態的應用程式中，資料扮演能讓您應用程式保持執行中的重要角色。 請確定資料具有高可用性，以在發生潛在故障時能夠回復。 在 Red Hat OpenShift on IBM Cloud 中，可以從多個選項中進行選擇來持續保存資料。 例如，您可以使用 Kubernetes 原生持續性磁區來佈建 NFS 儲存空間，或使用 IBM Cloud 資料庫服務來儲存資料。 如需詳細資訊，請參閱 規劃高度可用的資料。

    選擇具有正確儲存配置的機種或機器類型，以支援您的工作負載。 有些規格混合了下列磁碟及儲存空間配置。 例如，有些規格可能具有含原始 SSD 次要磁碟的 SATA 主要磁碟。

如需可用風味的清單，請參閱 VPC 風味 或 Classic 風味。

確定資源的工作節點容量

若要充分利用工作執行緒節點的效能，請在設定資源時考慮以下事項：

  • 考慮您的應用程式在做什麼：首先將應用程式大小與可用工作節點類型之一的容量保持一致。 此外，還要考慮您的應用程式是否會拉取大型或大量的圖片，因為這些圖片可能會佔用 Worker 節點上的本機儲存空間。

  • 保持核心力量每台機器都有一定數量的核心。 根據應用程式的工作負載，設定每個核心的 Pod 數目限制，例如 10。

  • 避免節點超載：將工作人員節點維持在 75% 左右的容量，以便為其他可能需要排程的 Pod 留出空間。 如果您應用程式所需的資源比工作者節點上可用的資源還要多，請使用可滿足這些需求的不同工作者節點規格。 根據應用程式的工作負載，設定每個節點的 Pod 數目限制，例如 40。

  • 選擇服務：當您考慮要建立多少個叢集時，您決定包含多少個服務整合？ 這些整合的服務和附加元件可以啟動 Pod，消耗並影響群集資源。

  • 應用程式的抄本：若要判定您想要的工作者節點數目，您也可以考量所要執行之應用程式的抄本數目。 例如，如果您知道工作負載需要 32 個 CPU 核心，而且規劃執行應用程式的 16 個抄本，則每個抄本 Pod 都需要 2 個 CPU 核心。 如果每個工作者節點只要執行一個應用程式 Pod，您可以為叢集類型訂購適當數目的工作者節點來支援此配置。

  • 為運行時要求留出空間：Worker節點必須預留一定數量的CPU和記憶體資源 運行所需的元件，例如作業系統或容器運行時。

    預留容量和預留實例 不支援。

選擇要在叢集中建立的命名空間數量

當您有多個共用叢集的團隊及專案時，請設定多個名稱空間。 命名空間是一種劃分群集資源的方法，使用 資源配額和 預設限制。 當您建立新的名稱空間時，請務必設定適當的 RBAC 原則來控制存取權。 如需詳細資訊，請參閱 Kubernetes 文件中的 使用命名空間共用群集。

如果您有一個小型叢集、數十位使用者及類似的資源（例如相同軟體的不同版本），則可能不需要多個名稱空間。 您可以改為使用標籤。

查看有關此決定的安全信息 容器隔離和安全。

建立命名空間的資源請求與限制

為了確保每個團隊都有必要的資源在群集中部署服務和執行應用程式，您必須為每個命名空間設定 資源配額。 資源配額決定部署限制，例如您可以部署的 Kubernetes 資源數量，以及這些資源可以消耗的 CPU 和記憶體數量。 設定配額之後，使用者必須在其部署中包含資源要求和限制。

當您建立部署時，也要限制它，讓您的應用程式的 Pod 只部署在具有最佳資源組合的機器上。 例如，建議您將資料庫應用程式限制為具有大量本端磁碟儲存空間（如 md1c.28x512.4x4tb）的裸機機器。

讓您的應用程式也具有高可用性

根據設計，容器和 Pod 的生存時間短，並且可能會非預期故障。 例如，如果應用程式發生錯誤，則容器或 Pod 可能會當機。 為了讓您的應用程式具有高可用性，您必須確保有足夠的實體來處理工作負載，並在發生故障時提供額外的實體。 您可以透過設定來確保有足夠的實例 自動縮放。

下一步

若要繼續規劃過程，請選擇 VPC集群網路 和 經典集群網路。 如果您準備好開始建立集群，請先從 準備您的帳戶以建立集群。