本文介紹使用ACK叢集調度策略時可能遇到的常見問題及對應的解決方案。
索引
如何防止虛擬交換器IP不足導致Pod啟動失敗
原生Kubernetes叢集調度器無法感知識別節點上IP資源耗盡的情況,這導致即使在叢集IP資源不足、Pod啟動失敗的情況下,系統仍會嘗試將Pod調度到這些節點上,短時間內產生大量異常Pod。為瞭解決這一問題,ACK調度器引入了k8s.aliyun.com/max-available-ip
註解來標記每個節點的最大可用IP數量,並據此以及Pod是否需要獨立IP地址來限制可調度至該節點的Pod數量。此外,當檢測到某個節點出現IP資源耗盡時,通過更新節點狀態中的SufficientIP
的Condition,阻止進一步向該節點調度需要獨立IP地址的新Pod,從而有效避免了因IP資源不足而引發的大規模Pod故障情況。
此功能是kube-scheduler組件自動啟用的功能。但您的叢集及kube-scheduler組件需滿足以下條件:
叢集為ACK叢集Pro版,且叢集網路外掛程式為Terway,Terway版本為v1.5.7及以上。詳細資料,請參見建立ACK託管叢集。
kube-scheduler版本需滿足如下要求。
叢集版本
kube-scheduler版本
1.30
所有版本均可支援
1.28
v1.28.3-aliyun-6.3及以上
1.26
v1.26.3-aliyun-6.3及以上
1.24
v1.24.6-aliyun-6.3及以上
1.22
v1.22.15-aliyun-6.3及以上
如何將ack-descheduler遷移至Koordinator Descheduler
Container Service Kubernetes 版在應用市場中提供了重調度應用ack-descheduler組件。該組件是對社區Kubernetes Descheduler的封裝,目前提供0.20.0和0.27.1兩個版本,其功能和使用方法均與社區Kubernetes Descheduler 0.20.0以及0.27.1保持一致。
ack-descheduler已停止維護,建議您遷移至當前維護的組件模組Koordinator Descheduler。遷移流程與遷移Kubernetes Descheduler至Koordinator Descheduler的流程類似,請參見遷移Kubernetes Descheduler至Koordinator Descheduler完成遷移。
ACK Scheduler的預設調度策略是什嗎?
在ACK叢集中,ACK Scheduler的預設調度策略與社區Kubernetes調度器保持一致。Kubernetes調度器決定如何將Pod調度到某個節點時,通常包括兩個關鍵步驟:Filter(過濾)和Score(評分)。
Filter:過濾哪些節點可以被調度的。如果過濾後的列表為空白,則表明Pod當前無法被調度。
Score:過濾後,調度器將對可供調度的節點進行打分和排名,從而選擇一個最適合放置Pod的節點。
關於ACK Scheduler最新版本中開啟的Filter和Score外掛程式,請參見Filter及Score外掛程式介紹。
如何在Pod調度過程中,規避利用率熱點節點?
在Kubernetes原生調度策略中,調度器主要基於節點資源的分配情況(資源Request)進行調度,並不會參考節點的真實利用率情況。此外,調度器還有多種Filter(過濾)和Score(評分)外掛程式,共同影響著調度結果。推薦您使用ACK叢集提供的如下功能,避免Pod被調度到熱點節點上。
為每個Pod配置合理的資源Request和Limit,規劃資源冗餘。您可以使用資源畫像功能,基於對資源使用量歷史資料的分析擷取容器規格的推薦配置。更多資訊,請參見資源畫像。
啟用負載感知調度功能。負載感知調度是ACK調度器Kube Scheduler基於Kubernetes Scheduling Framework實現的外掛程式。與Kubernetes原生調度策略不同的是,ACK Scheduler可以感知節點實際的資源使用方式,通過參考節點負載的歷史資料並對新調度Pod進行預估,將Pod優先調度到負載較低的節點,實現節點的負載平衡。更多資訊,請參見使用負載感知調度。
啟用負載熱點打散重調度功能。節點的利用率會隨著時間、叢集環境變化、工作負載的流量或請求等動態變化,從而導致叢集內節點間原本的負載平衡被打破,ACK Scheduler還提供了重調度能力,防止負載出現極端不均衡的情況。更多資訊,請參見使用負載熱點打散重調度。
叢集中新增了一個節點,但Pod為什麼始終沒有調度到這台節點上去?
此現象可能由多種原因導致。您可以按照如下流程進行排查。
檢查節點狀態是否正常。若節點處於NotReady狀態,表明節點仍未就緒。
檢查Pod是否設定了不合適的調度策略(NodeSelector、NodeAffinity、PodAffinity)或存在汙點等情況,導致Pod無法被調度到新節點。
評估是否為Kubernetes原生調度策略問題。在Kubernetes原生調度策略中,調度器主要基於節點資源的分配情況(資源Request)進行調度,並不會參考節點的真實利用率情況,所以可能會出現某些節點上啟動並執行Pod很多,某些節點上啟動並執行Pod很少或沒有。
您可以參見如何在Pod調度過程中,規避利用率熱點節點?提供的解決方案解決此問題。
叢集中CPU或記憶體使用量率不高,但調度時會提示CPU或記憶體資源不足
在Kubernetes原生調度策略中,調度器主要基於節點資源的分配情況(資源Request)進行調度,並不會參考節點的真實資源使用率,所以即使叢集CPU真實使用率不高,但仍有可能出現Pod調度時因CPU、記憶體資源不足(Insufficient CPU或Insufficient Memory)而調度失敗的情況。
您可以參見如何在Pod調度過程中,規避利用率熱點節點?提供的解決方案解決此問題。
在ACK中使用重調度功能有哪些注意事項?是否會重啟Pod?
ACK通過Koordinator Descheduler提供重調度功能,在使用重調度功能時,有如下注意事項。
Koordinator Descheduler只負責驅逐正在啟動並執行Pod,並不負責Pod驅逐後的重建以及調度。Pod被驅逐後的重建由其工作負載對應的Controller實現(例如Deployment、StatefulSet),重建後Pod的調度流程仍然由調度器負責。
重調度在執行過程中會先驅逐舊Pod,再建立新Pod。請確保您的應用有充足的冗餘副本(
replicas
),避免驅逐時影響應用可用性。
更多資訊,請參見重調度概述。
如何將應用調度到指定的節點上?
您可以為節點設定標籤,然後在應用YAML中添加對應的nodeSelector,調度應用到指定節點。具體操作,請參見調度應用至指定節點。
在一個Deployment中,如何指定一定數量的Pod調度到ECS,一定數量的Pod調度到ECI?
在ECS、ECI資源混合使用情境的下,您可以通過UnitedDeployment的方式定義Subset,對工作負載進行管理。例如,您可以在UnitedDeployment的YAML中指定subset-ecs中的replicas
為10
,subset-eci中的replicas
為10
。詳細資料,請參見基於UnitedDeployment實現工作負載的伸縮。
如何讓一個工作負載的Pod在調度時滿足高可用?
您可以通過Pod親和性的方式,將一個工作負載的Pod打散到不同可用性區域或節點。例如,您可以參見下方YAML為Pod添加如下欄位,聲明一個preferredDuringSchedulingIgnoredDuringExecution
“偏好”規則,嘗試將具有 security=S2
Label的Pod分散調度到不同的可用性區域(zone)內,並在無法滿足此條件時,再次嘗試將該Pod調度到其他節點上。
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: topology.kubernetes.io/zone
詳細資料,請參見Kubernetes官方文檔podAffinity和podAntiAffinity、拓撲分布約束(Topology Spread Constraints)。