Container Service for Kubernetes：ACK叢集高可用架構推薦配置

本文使用指引

本文主要面向Container Service for Kubernetes的叢集開發和管理員，提供規劃和構建高可用叢集的通用性建議。實際情況仍以您的叢集環境和業務需求為準。本文主要提供了關於叢集控制面和叢集資料面的相關高可用推薦配置。

叢集樣本架構

一個ACK叢集主要由控制面和普通節點或虛擬節點兩部分構成。

• 叢集控制面：負責叢集管理和協調，例如調度工作負載、維護叢集狀態等。以ACK託管叢集為例，ACK託管叢集採用Kubernetes on Kubernetes架構來託管您叢集的控制面組件，例如Kube API Server、etcd、Kube Scheduler等。

• 普通節點或虛擬節點：ACK叢集支援普通節點（ECS節點）和虛擬節點。節點負責執行實際的工作負載和提供運行容器所需的資源。

ACK叢集預設提供了多可用性區域（Availability Zone，AZ）的高可用叢集部署架構。以ACK託管叢集為例，叢集架構樣本如下。

控制面架構高可用

託管類的部分ACK叢集，包括ACK託管叢集（Pro版、基礎版）、ACK Serverless叢集（Pro版、基礎版）、ACK Edge叢集、ACK靈駿叢集中，其控制面及控制面相關組件（例如Kube API Server、etcd、Kube Scheduler等）由ACK進行託管。

• 多可用性區域的地區：所有託管組件均嚴格採用多副本、多AZ均衡打散部署策略，確保在單個可用性區域或節點發生故障時，叢集仍然能夠正常提供服務。

• 單可用性區域地區：所有託管組件均嚴格採用多副本、多節點打散部署策略，確保在單個節點發生故障時，叢集仍然能夠正常提供服務。

其中，etcd至少為3副本，Kube API Server至少為2副本。所有Kube API Server副本均通過掛載ENI與叢集VPC實現網路互連，節點側kubelet和Kube Proxy通過API Server CLB或者ENI串連Kube API Server。

ACK核心託管組件均可以根據實際的資源使用方式（例如CPU、記憶體使用量量等）進行Auto Scaling，以動態滿足API Server的資源使用需求，提供穩定的SLA保障。

除叢集控制面預設採用的多可用性區域的高可用架構外，您也可以進一步配置叢集資料面的高可用架構，包括節點池和虛擬節點高可用配置、工作負載高可用配置、負載平衡高可用配置、組件推薦配置。

節點池和虛擬節點高可用配置

ACK叢集支援普通節點（ECS節點）和虛擬節點。您可以通過節點池來納管節點，對節點進行分組管理，包括升級、擴縮容、日常營運等操作。如果您的業務流量相對穩定，或波峰波穀相對穩定，您可以使用ECS節點；如果您的業務有不易提前預測的瞬時波峰，您可以使用虛擬節點，應對突發流量，降低計算成本。更多資訊，請參見節點池概述、託管節點池概述、虛擬節點。

節點池高可用配置

您可以基於節點的Auto Scaling、部署集、多AZ，結合K8s調度的拓撲分布約束，確保服務在不同的故障域（failure-domain）資源充足且有所隔離，從而當某一故障域出現問題時，服務仍然可以保持運行，減少單點故障的風險，提高系統的整體可靠性和可用性。

配置節點Auto Scaling

每個節點池背後是一個Auto Scaling組（ESS），支援在負載調度層或叢集資源層對節點進行手動擴縮容與自動化Auto Scaling，以更低成本、更靈活地調整彈性計算資源。關於ACK提供的Auto Scaling方案，請參見Auto Scaling概述、啟用節點自動調整。

啟用部署集

部署集是控制ECS執行個體分布的策略，該策略將ECS執行個體分散部署在不同的物理伺服器上，避免由於一台物理機失效導致多台ECS執行個體宕機。通過為節點池指定部署集，能夠保證節點池擴容出的ECS執行個體不會分佈於同一物理機上，並通過親和性配置，使您的應用對底層的節點拓撲進行感知，使其均勻地分布在不同節點上，保證應用的容災能力和高可用性。關於如何啟用部署集功能，請參見節點池部署集最佳實務。

配置多AZ分布

ACK支援多AZ節點池。在節點池的建立和運行過程中，推薦您為節點池選擇多個不同AZ的vSwitch，並在配置擴縮容策略時選擇均衡分布策略，允許在伸縮組指定的多可用性區域（即指定多個專用網路交換器）之間均勻分配ECS執行個體。如果由於庫存不足等原因導致可用性區域之間資源不平衡，您可以再進行均衡操作來平衡資源的可用性區域分布。關於如何配置自動調整策略，請參見啟用節點自動調整。

啟用拓撲分布約束

基於節點的Auto Scaling、部署集、多AZ分布等手段，結合K8s調度中的拓撲分布約束（Topology Spread Constraints），可以實現不同層級的故障域隔離能力。ACK節點池上所有節點會自動添加拓撲相關的label，例如kubernetes.io/hostname、topology.kubernetes.io/zone、topology.kubernetes.io/region等。您可以使用拓撲分布約束來控制Pod在不同故障域之間的分布，提升對底層基礎設施故障的容忍能力。

關於如何在ACK叢集中使用拓撲感知調度能力，例如使Pod在多個拓撲域中重試或將Pod調度到屬於同一低延時部署集的ECS中，請參見拓撲感知調度。

虛擬節點高可用配置

您可以藉助ACK虛擬節點將Pod快速地調度到Elastic Container Instance上運行。使用ECI時，您無需購買和管理底層ECS伺服器，可以更加關注容器應用而非底層基礎設施的維護工作。您可按需建立ECI，僅為容器配置的資源付費（按量按秒計費）。

但為應對突發流量而進行業務的快速水平擴容，或者啟動大量執行個體進行Job任務處理時，可能會遇到可用性區域對應的規格執行個體庫存不足或者指定的交換器IP耗盡等情況，從而導致ECI執行個體建立失敗。ACK Serverless叢集的多可用性區域特性可以提高ECI執行個體的建立成功率。

您可以配置虛擬節點的ECI Profile，指定跨不同AZ的vSwitch，實現跨多AZ應用部署。

• ECI會把建立Pod的請求分散到所有的vSwitch中，從而達到分散壓力的效果。

• 如果建立Pod的請求在某一個vSwitch中無庫存，會自動切換到下一個vSwitch繼續嘗試建立。

您執行以下命令，按需修改kube-system/eci-profile configmap中的vSwitchIds欄位，追加vSwitch ID，多個vSwitch ID之間採用英文半形逗號（,）分隔。修改後即時生效。更多資訊，請參見建立多可用性區域的ECI Pod。

kubectl -n kube-system edit cm eci-profile

apiVersion: v1
data:
 kube-proxy: "true"
 privatezone: "true"
 quota-cpu: "192000"
 quota-memory: 640Ti
 quota-pods: "4000"
 regionId: cn-hangzhou
 resourcegroup: ""
 securitygroupId: sg-xxx
 vpcId: vpc-xxx
 vSwitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap

工作負載高可用配置

工作負載的高可用能夠保障在故障發生時，應用Pod能夠正常運行，或迅速恢複。您可以通過配置拓撲分布約束（Topology Spread Constraints）、Pod反親和（PodAntiAffinity）、Pod Disruption Budget（PDB）、Pod健康檢測與自愈等來實現應用Pod的高可用。

配置拓撲分布約束

拓撲分布約束（Topology Spread Constraints）是一種在Kubernetes叢集中管理Pod分布的功能。它可以確保Pod在不同的節點和可用性區域之間均勻分布，以提高應用程式的高可用性和穩定性。該技術適用於Deployment、StatefulSet、DaemonSet、Job、CronJob等工作負載類型。

您可以設定maxSkew.topologyKey等配置來控制Pod的分布，以確保Pod在叢集中按照期望的拓撲分布進行部署，例如指定工作負載在不同的可用性區域之間均勻分布，以提高可靠性和可用性。樣本如下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-zone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-zone
  template:
    metadata:
      labels:
        app: app-run-per-zone
    spec:
      containers:
        - name: app-container
          image: app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

配置Pod反親和

Pod反親和（PodAntiAffinity）是Kubernetes中的一種調度策略，用於在調度Pod時確保它們不會被調度到同一個節點上，以提高應用程式的高可用性和故障隔離能力。樣本如下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-node
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-node
  template:
    metadata:
      labels:
        app: app-run-per-node
    spec:
      containers:
        - name: app-container
          image: app-image
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - app-run-per-node
              topologyKey: "kubernetes.io/hostname"

基於拓撲分布約束，您也可實現在每個節點上最多隻運行1個Pod的效果。當指定topologyKey: "kubernetes.io/hostname"時，相當於將每個節點作為一個拓撲域。

下方樣本建立了一個拓撲分布約束，其中maxSkew設定為1，topologyKey設定為"kubernetes.io/hostname"，whenUnsatisfiable設定為DoNotSchedule，表明在每個節點上最多隻能運行1個Pod，以實現強制Pod按節點高可用打散的效果。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: DoNotSchedule

配置Pod Disruption Budget

您可以使用Pod Disruption Budget（PDB）進一步提高應用的可用性。PDB允許定義一個最小可用副本數，當節點處於維護或故障狀態時，叢集將確保至少有指定數量的副本保持運行。PDB可以防止過多的副本同時終止，尤其適合多副本處理流量型的情境。樣本如下。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-pdb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-with-pdb
  template:
    metadata:
      labels:
        app: app-with-pdb
    spec:
      containers:
        - name: app-container
          image: app-container-image
          ports:
            - containerPort: 80
  ---
  apiVersion: policy/v1beta1
  kind: PodDisruptionBudget
  metadata:
    name: pdb-for-app
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: app-with-pdb

配置Pod健康檢測與自愈

在ACK叢集中，您可以配置不同類型的探針來監測和管理容器的狀態和可用性，包括存活探針（Liveness Probes）、就緒探針（Readiness Probes）、啟動探針（Startup Probes）。您可以通過在Pod配置中添加相應的探針和重啟策略來進行配置。樣本如下。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probe
spec:
  containers:
    - name: app-container
      image: app-image
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/ready
        initialDelaySeconds: 20
        periodSeconds: 15
      restartPolicy: Always

負載平衡高可用配置

在叢集中實現負載平衡的高可用對於提高服務的穩定性、響應速度、故障隔離性等至關重要。您可以指定Server Load Balancer執行個體的主備可用性區域、啟用拓撲感知提示 (Topology Aware Hints)等手段來實現。

指定CLB執行個體的主備可用性區域

傳統型負載平衡CLB已在大部分地區部署了多可用性區域，以實現同地區下的跨機房容災。您可以通過Service Annotation來指定CLB執行個體的主備可用性區域，使得主備可用性區域與節點池中ECS可用性區域保持一致，減少跨可用性區域資料轉寄，提升網路訪問效能。關於CLB支援的地區和可用性區域，請參見CLB支援的地區資訊；關於如何指定CLB執行個體的主備可用性區域，請參見建立負載平衡時，指定主備可用性區域。

樣本如下。

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-a"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-b"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

啟用拓撲感知提示 (Topology Aware Hints)

為了減少跨可用性區域網路流量，提升網路效能，Kubernetes 1.23引入拓撲感知路由（Topology Aware Routing，也可以稱為拓撲感知提示，Topology Aware Hints）特性，實現了拓撲感知的就近路由功能。

您可以在Service中啟用該功能。啟用後，當可用性區域（Zone）內有足夠的端點（Endpoint）可用時，EndpointSlice控制器會根據在EndpointSlice上的拓撲提示（Topology Hint）資訊將流量優先路由到距離發起請求的地點更近的端點。在網路流量跨可用性區域的情境下，該功能會優先將網路流量保持在同一地區內，從而提高網路效率並減少相應的成本。更多資訊，請參見Topology Aware Routing。

組件推薦配置

ACK提供多種類型的組件，您可以根據業務需求為建立叢集或已建立叢集擇配置特定組件，拓展叢集功能。關於ACK支援的組件及其介紹與變更記錄，請參見組件介紹與發布記錄；關於如何升級和管理（配置、卸載、升級等）組件，請參見管理組件。

相關文檔

• 推薦您的Worker節點使用較大規格的ECS執行個體，更多資訊請參見ECS選型推薦配置。

• 如您的ACK叢集Pro版規模較大（通常為超過500個節點或者10,000個Pod的叢集），請參見大規模ACK Pro叢集使用建議擷取使用建議。

• 關於節點與節點池的最佳實務，請參見節點與節點池最佳實務。

• 關於Auto Scaling的最佳實務，請參見Auto Scaling最佳實務。