使用 OpenShift 實現高可用的最佳做法

本文說明在 Compute Engine 上，使用 Red Hat OpenShift Container Platform 工作負載達成高可用性 (HA) 的最佳做法。本文著重於應用程式層級的策略，協助您確保工作負載在發生故障時仍維持高可用性。這些策略可協助您消除單點故障，並實作自動容錯移轉和復原機制。

本文適用於平台和應用程式架構設計人員，並假設您具備 OpenShift 部署經驗。如要進一步瞭解如何部署 OpenShift，請參閱 Red Hat 說明文件。

將部署作業分散至多個可用區

建議您在Google Cloud 區域內的多個可用區部署 OpenShift。這種做法可確保即使某個區域發生中斷情形，叢集的控制層節點仍可在部署作業分散的其他區域繼續運作。如要跨多個區域部署 OpenShift，請在 install-config.yaml 檔案中指定同一區域的 Google Cloud 區域清單。

如要精細控管節點的部署位置，建議您定義 VM 配置政策，確保 VM 分散在同一可用區的不同故障網域中。對叢集節點套用分散式放置政策，有助於減少同時受到特定位置中斷影響的節點數量。如要進一步瞭解如何為現有叢集建立分散政策，請參閱「為 VM 建立及套用分散式放置政策」。

同樣地，如要避免在同一節點上排定多個 Pod，建議您使用 Pod 反相依性規則。這些規則會將應用程式副本分散到多個區域。以下範例說明如何實作 Pod 反親和性規則：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

如果是無狀態服務 (例如網頁前端或 REST API)，建議您為每個服務或路徑執行多個 Pod 副本。這種做法可確保流量自動路由至可用區域中的 Pod。

主動管理負載，避免資源過度承諾

建議您主動管理應用程式的負載，以免資源過度承諾。過度承諾可能會導致服務在負載下效能不佳。您可以設定資源要求限制，避免過度承諾，如需更詳細的說明，請參閱管理 Pod 的資源。此外，您也可以使用水平 Pod 自動調度器，根據 CPU、記憶體或自訂指標，自動調度備用資源。

此外，我們也建議您使用下列負載平衡服務：

定義 Pod disruption budget

建議您定義中斷預算，指定應用程式在維護事件或更新等中斷期間，必須可用的 Pod 數量下限。以下範例說明如何定義中斷預算：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

詳情請參閱「為應用程式指定中斷預算」。

使用支援高可用性和資料複製的儲存空間

對於需要將永久資料儲存在容器外部的有狀態工作負載，我們建議採取下列最佳做法。

磁碟最佳做法

如需磁碟儲存空間，請使用下列其中一種方式：

選取儲存空間選項後，請在叢集中安裝驅動程式：

CSI 永久磁碟運算子會提供儲存空間類別，您可用於建立永久磁碟區要求 (PVC)。如果是 Filestore，您必須建立 Filestore 儲存空間類別。

資料庫最佳做法

如需資料庫，請使用下列其中一種：

安裝資料庫運算子後，請設定具有多個執行個體的叢集。以下範例顯示叢集的設定，其中包含下列屬性：

  • 系統會建立名為 my-postgres-cluster 的 PostgreSQL 叢集，其中包含三個執行個體，可提供高可用性。
  • 叢集會使用 regionalpd-balanced 儲存空間級別，在各個區域提供耐用且經過複製的儲存空間。
  • 系統會使用使用者 myuser 初始化名為 mydatabase 的資料庫，而該使用者的憑證會儲存在名為 my-database-secret 的 Kubernetes Secret 中。
  • 為提高安全性，系統已停用超級使用者存取權。
  • 叢集已啟用監控功能。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

外部化應用程式狀態

建議您將工作階段狀態或快取移至共用的記憶體內儲存空間 (例如 Redis)，或是設定以高可用性模式執行的持續性資料儲存空間 (例如 Postgres、MySQL)。

最佳做法摘要

總而言之，請實作下列最佳做法，在 OpenShift 中實現高可用性：

  • 將部署作業分散至多個可用區
  • 主動管理負載，避免資源過度承諾
  • 定義 Pod disruption budget
  • 使用高可用性資料複製功能
  • 外部化應用程式狀態

後續步驟