高可用以及高效能是分布式任務執行過程中的重要要求。在ACK Pro版叢集或ACK Serverless叢集Pro版中,您可以通過Kubernetes原生調度語義實現分布式任務的跨可用性區域打散,以達到高可用性區域部署的要求,或者通過Kubernetes原生調度語義實現分布式任務在指定可用性區域中的親和性部署,以達到高效能部署的要求。本文介紹如何?ECI Pod可用性區域打散或親和調度。
背景資訊
在某些情況下,您可能需要將Pod分散部署到多個不同的可用性區域,或者部署到某個指定可用性區域,以實現高可用或者高效能的需求。此時,您可以通過Kubernetes原生調度語義中的Pod拓撲分布約束(topologySpreadConstraints)、節點親和性(nodeAffinity)和Pod親和性(podAffinity)來實現。
僅當Pod中帶有nodeAffinity
、podAffinity
、topologySpreadConstraints
欄位或存在匹配的ResourcePolicy時才會啟用可用性區域打散或親和調度。
更多資訊,請參見Kubernetes官方文檔:
前提條件
已有ACK Pro版叢集或ACK Serverless叢集Pro版,並且滿足以下要求:
叢集版本為1.22及以上。
叢集中的ACK Virtual Node組件版本為v2.10.0及以上。
叢集中的kube-scheduler組件版本為5.9及以上,並且已開啟虛擬節點調度功能。更多資訊,請參見開啟叢集虛擬節點調度策略。
已在eci-profile中配置多個期望調度的目標可用性區域(即配置多個交換器)。具體操作,請參見多可用性區域建立Pod。
使用限制
目前僅支援設定
topologyKey
為topology.kubernetes.io/zone
的用法。不支援設定ECI Pod的交換器順序。
如果ECI Pod通過
k8s.aliyun.com/eci-schedule-strategy: "VSwitchOrdered"
的Annotation聲明了多可用性區域調度策略為按照交換器的指定順序,該功能將被自動禁用。不支援設定ECI Pod的故障處理策略為
fail-fast
。如果ECI Pod通過
k8s.aliyun.com/eci-fail-strategy: "fail-fast"
的Annotation設定了Pod故障處理策略為fail-fast
,該功能將被自動禁用。
配置樣本
下文將在1.22版本的ACK Serverless叢集Pro版本叢集中示範ECI Pod可用性區域打散和親和調度功能。
樣本一:通過topologySpreadConstraints實現可用性區域打散
以下為一個配置了拓扑打散約束的樣本。預設情況下,Scheduler會將所有Pod均勻調度到所有可用性區域上,但並不會考慮Pod的生產結果。更多資訊,請參見ECI嚴格拓扑打散功能介紹。
在工作負載申明中增加拓撲分布約束。
Pod的
Spec
欄位中或Deployment、Job等工作負載的PodTemplate的Spec
欄位中,可以通過以下方式申明一個拓撲分布約束。topologySpreadConstraints: - maxSkew: <integer> minDomains: <integer> # 可選,從v1.25開始成為Beta。 topologyKey: <string> whenUnsatisfiable: <string> labelSelector: <object> matchLabelKeys: <list> # 可選,從v1.27開始成為Beta。 nodeAffinityPolicy: [Honor|Ignore] # 可選,從v1.26開始成為Beta。 nodeTaintsPolicy: [Honor|Ignore] # 可選,從v1.26開始成為Beta。
本樣本將建立一個在多個可用性區域上均勻分布的Deployment。關於參數的詳細資料,請參見topologySpreadConstraints欄位。以下為該Deployment的YAML檔案。
建立工作負載。
將上面的代碼儲存為
deployment.yaml
,並執行以下命令將Deployment提交到叢集中。kubectl apply -f deployment.yaml
驗證工作負載調度結果。
通過以下命令查看生產出的Pod所在的節點。
kubectl get po -lapp=with-pod-topology-spread -ocustom-columns=NAME:.metadata.name,NODE:.spec.nodeName --no-headers | grep -v "<none>"
通過以下命令查看生產出的Pod在各個可用性區域中的數量。
kubectl get po -lapp=with-pod-topology-spread -ocustom-columns=NODE:.spec.nodeName --no-headers | grep -v "<none>" | xargs -I {} kubectl get no {} -ojson | jq '.metadata.labels["topology.kubernetes.io/zone"]' | sort | uniq -c
樣本二:通過nodeAffinity和podAffinity實現可用性區域親和
在工作負載申明中增加親和性約束。
本樣本將建立在單個可用性區域上聚集分布的Deployment。關於參數的詳細資料,請參見節點親和性。以下為該Deployment的YAML檔案。
若您希望指定可用性區域進行部署,可以將樣本中的
podAffinity
刪去,在nodeAffinity
添加如下約束。下方約束表明Pod必須在可用性區域cn-beijing-a上進行部署。requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - cn-beijing-a
以下為
nodeAffinity
的完整樣本,表明Pod必須在可用性區域cn-beijing-a上進行部署。建立工作負載。
將上面的代碼儲存為
deployment.yaml
,並執行以下命令將Deployment提交到叢集中。kubectl apply -f deployment.yaml
驗證工作負載調度結果。
通過以下命令查看生產出的Pod所在的節點。
kubectl get po -lapp=with-affinity -ocustom-columns=NAME:.metadata.name,NODE:.spec.nodeName --no-headers | grep -v "<none>"
通過以下命令查看生產出的Pod在各個可用性區域中的數量。
kubectl get po -lapp=with-affinity -ocustom-columns=NODE:.spec.nodeName --no-headers | grep -v "<none>" | xargs -I {} kubectl get no {} -ojson | jq '.metadata.labels["topology.kubernetes.io/zone"]' | sort | uniq -c
ECI嚴格拓扑打散功能介紹
在保持預設狀態不變的情況下,當配置了強制打散約束時,Scheduler會將所有Pod均勻放置到所有可用性區域上,但並不考慮ECI Pod的生產結果。如下圖所示,假設將打散功能的maxSkew設定為1。關於maxSkew,請參見maxSkew。
此時若可用性區域B和C中生產ECI Pod失敗,則可用性區域A上會放置2個ECI Pod,其他兩個可用性區域沒有ECI Pod,從而破壞打散功能的maxSkew約束。
當嚴格拓扑打散功能開啟後,在ACK Serverless叢集Pro版中,調度器將嚴格保證Pod的強制打散需求得到滿足。Scheduler會在可用性區域A、B、C上各放置1個Pod,剩下的Pod將處於Pending狀態,等待現有Pod生產,如下圖所示。
當PodA1生產成功後,Pending狀態的Pod將繼續Pending,這是由於可用性區域B以及可用性區域C上的ECI Pod仍然可能生產失敗,Pod放置於任意可用性區域仍然可能導致生產結束後破壞maxSkew約束。當PodB1生產成功後,Scheduler將會放置一個Pod在可用性區域C。如下圖所示,其中綠色背景的Pod為生產完成的Pod。
若您不需要嚴格拓扑打散功能,請將拓扑打散約束中的調度條件whenUnsatisfiable
設定為ScheduleAnyway
。詳細資料,請參見分布約束定義。