本文介紹使用ACK叢集調度策略時可能遇到的常見問題及對應的解決方案。
索引
如何防止虛擬交換器IP不足導致Pod啟動失敗
原生Kubernetes叢集調度器對節點所屬虛擬交換器是否有剩餘IP不感知。在多個叢集或多個節點同時使用同一個虛擬交換器時，可能出現Pod調度到節點上後由於虛擬交換器可用IP不足而啟動失敗的情況。這種情況下，Pod控制器通常會重建Pod，之後原生Kubernetes叢集調度器通常會再次調度Pod到啟動失敗的節點上，最終在短時間內多次觸發IP不足，既影響客戶業務部署，也會產生大量警示。
為瞭解決此問題，ACK支援了虛擬交換器剩餘IP狀態感知調度功能。此功能是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、Statfulset），重建後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。詳細資料，請參見在ACK上使用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）。