全部產品
Search
文件中心

Container Service for Kubernetes:調度FAQ

更新時間:Nov 01, 2024

本文介紹使用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為什麼始終沒有調度到這台節點上去?

此現象可能由多種原因導致。您可以按照如下流程進行排查。

  1. 檢查節點狀態是否正常。若節點處於NotReady狀態,表明節點仍未就緒。

  2. 檢查Pod是否設定了不合適的調度策略(NodeSelector、NodeAffinity、PodAffinity)或存在汙點等情況,導致Pod無法被調度到新節點。

  3. 評估是否為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中的replicas10,subset-eci中的replicas10。詳細資料,請參見基於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)