Container Service for Kubernetes：調度FAQ

如何防止虛擬交換器IP不足導致Pod啟動失敗？

如何將ack-descheduler遷移至Koordinator Descheduler？

ack-descheduler已停止維護，請參見【組件公告】ack-descheduler組件遷移公告。建議您遷移至當前維護的組件模組Koordinator Descheduler。遷移流程與遷移Kubernetes Descheduler至Koordinator Descheduler的流程類似，請參見遷移Kubernetes 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 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中的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）。

對於一批新建立的Pod，為什麼沒有全部調度到負載最低的節點？

如果調度器將一批新建立的Pod全部調度到當前負載最低的節點，那麼這個節點反而可能很快就會成為負載熱點，這是因為新Pod在啟動後會增加節點的負載。

因此，負載感知調度外掛程式在計算節點打分時，若節點中有利用率還未上報的新Pod，會對打分結果進行適當調整，避免過量調度而產生新的熱點。

除了節點負載水位，還有哪些因素會影響調度結果？

K8s調度器由多個外掛程式組成，在調度過程中很多外掛程式都會參與到節點排序的打分計算，例如親和性外掛程式、拓撲分布外掛程式，節點的最終排序會受這些外掛程式共同影響，您可以根據實際情況，按需調整各外掛程式的打分權重。

調度器升級為新版本後，是否繼續支援已通過舊版本協議使用的負載感知調度功能？

如需使用舊版本的負載感知調度功能，需為Pod添加Annotation alibabacloud.com/loadAwareScheduleEnabled: "true"。

各版本協議的支援情況和組件版本具體要求如下。

開啟CPU Burst配置後，為什麼Pod仍有CPU Throttled現象出現？

通常會有以下幾個原因，您可以參考以下說明進行調整。

• 配置格式錯誤，導致CPU Burst策略沒有生效，請參見進階參數配置修改並驗證。

• CPU利用率達到cfsQuotaBurstPercent配置的上限時，由於CPU資源不足，仍會出現CPU Throttled現象。

  建議您根據應用實際需求情況調整Reqeuest和Limit值。

• CPU Burst策略會調整Pod的兩個cgroup參數：cpu.cfs_quota_us和cpu.cfs_burst_us，詳情請參見進階參數配置。其中，cpu.cfs_quota_us在ack-koordinator感知到CPU Throttled後才會進行設定，存在少許延遲；而cpu.cfs_burst_us直接參考配置進行設定，效果更靈敏。

  建議您搭配Alibaba Cloud Linux作業系統使用，效果更佳。

• CPU Burst策略在調整cpu.cfs_quota_us時會有保護機制，即整機安全水位閾值配置的sharePoolThresholdPercent。當整機利用率過高時，為了避免單個Pod產生更多幹擾，cpu.cfs_quota_us會被重設為初始值。

  建議您結合自身應用的實際情況，合理設定整機安全水位閾值，避免因整機利用率過高而影響應用效能。

開啟CPU Burst策略是否必須使用Alibaba Cloud Linux作業系統？

ack-koordinator的CPU Burst策略適用於所有Alibaba Cloud Linux及CentOS開源核心。推薦您使用Alibaba Cloud Linux作業系統。藉助Alibaba Cloud Linux核心特性，ack-koordinator可以提供更加細粒度的CPU彈性管理機制。更多資訊，請參見在cgroup v1介面開啟CPU Burst功能。

應用使用了Batch資源後，記憶體資源用量為什麼突然變得更高？

對於在Pod Limit中配置了kubernetes.io/batch-memory的應用（簡稱batch limit），ack-koordinator會等待容器建立後根據batch limit在節點上為其設定Cgroup限制參數。由於部分應用在啟動時會根據容器Cgroup參數自動申請記憶體，若應用在Cgroup的memory.limit參數設定前就完成了啟動，其記憶體的真實用量可能會超過batch limit。而作業系統不會立即縮減該進程的記憶體使用量，從而導致容器的記憶體Cgroup參數無法設定成功，需等待至其真實用量降低至batch limit以下。

此時，建議您適當調整應用配置參數，控制其記憶體真實用量在batch limit以下，或在應用啟動指令碼中首先檢查記憶體限制參數，確認完成設定後再進行啟動，確保應用的記憶體用量存在合理限制，避免出現OOM等情況。

您可以在容器內執行以下命令，查看記憶體資源限制參數。

# 單位為位元組。
cat /sys/fs/cgroup/memory/memory.limit_in_bytes 
# 預期輸出。
1048576000

CPU核心數提高後，為什麼效能反而下降並且Pod出現CPU Throttling限流問題？

當前已通過ack-slo-manager的舊版本協議使用了動態資源超賣功能，升級為ack-koordinator組件後是否繼續支援？

舊版本的動態資源超賣協議包括兩部分：

• 在Pod的Annotation中填寫的alibabacloud.com/qosClass。

• 在Pod的Request和Limit中填寫的alibabacloud.com/reclaimed。

ack-koordinator相容以上舊版本協議，並在ACK託管叢集Pro版的調度器中統一計算新舊版本協議的資源申請量和可用量。您可將組件無縫升級至ack-koordinator。

ACK託管叢集Pro版的調度器和ack-koordinator對各版本協議的適配如下。

當前已通過ack-slo-manager的舊版本協議使用了CPU Burst功能，升級為ack-koordinator後是否繼續支援？

舊版本的Pod協議要求在Annotation中填寫alibabacloud.com/cpuBurst，ack-koordinator對此舊版本協議完全相容，您可將組件無縫升級至新版本。

ack-koordinator對各版本協議的適配如下。

當前已經通過ack-slo-manager的舊版本協議使用了CPU QoS功能，升級為ack-koordinator後是否繼續支援CPU QoS功能？

舊版本（≤0.8.0）的Pod協議中，通過在Pod的Annotation中填寫alibabacloud.com/qosClass啟用CPU QoS。

ack-koordinator保持了對以上舊版本協議的相容，您可以將組件無縫升級至ack-koordinator，並逐步將Pod切換為koordinator.sh協議。ack-koordinator將對以上舊版本協議相容至2023年07月30日，我們建議您將原協議資源欄位及時升級到新版本。

當前已經通過ack-slo-manager的舊版本協議使用了容器記憶體QoS功能，升級為ack-koordinator後是否繼續支援容器記憶體QoS功能？

舊版本（≤0.8.0）的Pod協議包括：

• 在Pod的Annotation中填寫alibabacloud.com/qosClass。

• 在Pod的Annotation中填寫alibabacloud.com/memoryQOS。

ack-koordinator相容以上舊版本協議，您可以將組件無縫升級至ack-koordinator。相容支援至2023年7月30日。建議您將原協議資源欄位及時升級到新版本。

ack-koordinator各版本對記憶體QoS功能的適配如下。

節點利用率閾值已經達到閾值，但是節點上Pod沒有被驅逐怎麼辦？

出現這種情況時，一般可能是有以下幾種原因，請參考對應的解決方案進行調整。

重調度器頻繁重啟是什麼原因？

重調度器的配置ConfigMap格式錯誤或不存在，請參見進階配置參數檢查ConfigMap檔案內容和格式並進行修改，修改後重啟重調度器。重啟重調度器，請參見步驟二：開啟負載熱點打散重調度外掛程式。

負載感知調度和熱點打散重調度如何搭配使用？

開啟熱點打散重調度後，負載熱點上的Pod將會被驅逐。對於上層控制器（例如Deployment）建立的Pod，調度器會根據其配置選擇合適的節點進行調度。為了獲得更好的負載平衡效果，建議您同時為調度器開啟負載感知調度能力，請參見使用負載感知調度。

配置時，建議您將負載感知調度中的節點篩選功能參數loadAwareThreshold配置為與熱點打散重調度器的highThresholds參數相同的值，具體請參見策略說明。當節點的負載超過highThresholds時，重調度器將驅逐該節點上的Pod，而調度器則通過loadAwareThreshold拒絕新的Pod被調度到該熱點節點上。否則，經驅逐的Pod可能重新被調度到原來的節點，尤其是在Pod指定了節點調度範圍，但對應的節點數量較少且利用率較為接近時。

重調度參考的利用率演算法是什嗎？

重調度器會持續對利用率監控一段時間，並對監控資料做平滑均值處理，因此只有節點持續超過閾值才會觸發重調度，預設為10分鐘左右。此外對於記憶體資源維度，重調度器參考的記憶體用量排除了page cache，因為這部分資源是可以被作業系統回收的，而通過kubectl top node返回的利用率是包含page cache的，您可以通過使用阿里雲Prometheus監控查看真實的記憶體用量資訊。

在使用wrk壓測中，測試結果提示“Socket errors: connect 54,”怎麼辦？

問題描述

在使用wrk壓測中，測試結果提示Socket errors: connect 54,。測試中的wrk Client和Nginx Server建立串連失敗，測試結果失效。

問題原因

該錯誤通常是因為用戶端的串連數受限，導致用戶端建立串連失敗。

解決辦法

為了避免該錯誤，請在壓測機上檢查系統的TCP串連配置，並嘗試啟用TCP串連重用。

1. 登入壓測機，執行如下命令，查看是否開通TCP串連重用。

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   命令輸出為0或2，說明系統未完全開啟TCP串連重用。

2. 執行如下命令，啟用TCP串連重用。

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. 使用wrk工具再次發起壓測請求。

   檢查測試結果不再包含Socket errors: connect 54, ...的報錯提示，說明測試結果有效。

為什麼k8s-reclaimed-resource頁簽中，叢集混部收益情況地區沒有資料？

1. 查看是否已安裝ack-koordinator組件。

   1. 登入Container Service管理主控台，在左側導覽列單擊叢集列表。

   2. 在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇應用 > Helm。

   3. 在Helm頁面查看是否存在ack-koordinator組件。

      • 不存在：參見安裝和管理組件安裝ack-koordinator組件，然後執行下方步驟。

      • 已存在：直接執行下方步驟。

2. 查看在離線混部監控大盤是否顯示相關資料。

   若不顯示，請執行以下步驟：

   1. 登入ARMS控制台。

   2. 在左側導覽列選擇Prometheus監控 > 執行個體列表，進入可觀測監控 Prometheus 版的執行個體列表頁面。

   3. 在頁面左上方選擇目標地區，單擊Prometheus執行個體名稱，然後在左側導覽列單擊指標管理。

   4. 單擊藍色指標（Metrics）按鈕，按照頁面提示搜尋並選擇kube_node_labels，查看指標的資料詳情。

是否可以使用Arm架構類型的競價（Spot）執行個體？

目前已經提供Arm架構的競價執行個體。關於使用方式，請參見使用搶佔式執行個體。

在ACK叢集中使用Arm架構節點有哪些限制？