使用負載熱點打散重調(diào)度
ack-koordinator組件提供負載熱點打散重調(diào)度能力,可以感知集群內(nèi)節(jié)點負載的變化,自動優(yōu)化超過負載水位安全閾值的節(jié)點,防止出現(xiàn)負載極端不均衡的情況。本文介紹如何使用負載熱點打散重調(diào)度及其高級配置參數(shù)。
使用限制
僅支持ACK集群Pro版。具體操作,請參見創(chuàng)建ACK托管集群。
使用負載熱點打散重調(diào)度,需滿足以下版本要求。
組件
版本要求
ACK調(diào)度器版本
v1.22.15-ack-4.0及以上,v1.24.6-ack-4.0及以上
ack-koordinator(ack-slo-manager)
v1.1.1-ack.1及以上
Helm版本
v3.0及以上
重調(diào)度器只負責驅(qū)逐,調(diào)度過程仍由ACK Scheduler負責。在使用重調(diào)度功能時,建議和負載感知調(diào)度搭配使用,ACK Scheduler將盡量避免Pod被重新分配到熱點節(jié)點。
重調(diào)度在執(zhí)行過程中會先驅(qū)逐舊Pod,再創(chuàng)建新Pod。請確保您的應用有充足的冗余副本,避免驅(qū)逐時影響應用可用性。
重調(diào)度在驅(qū)逐時使用的是K8s標準的驅(qū)逐接口,請確保應用Pod自身邏輯具備可重入性,不會因驅(qū)逐后重新啟動而導致服務受損。
費用說明
ack-koordinator組件本身的安裝和使用是免費的,不過需要注意的是,在以下場景中可能產(chǎn)生額外的費用:
ack-koordinator是非托管組件,安裝后將占用Worker節(jié)點資源。您可以在安裝組件時配置各模塊的資源申請量。
ack-koordinator默認會將資源畫像、精細化調(diào)度等功能的監(jiān)控指標以Prometheus的格式對外透出。若您配置組件時開啟了ACK-Koordinator開啟Prometheus監(jiān)控指標選項并使用了阿里云Prometheus服務,這些指標將被視為自定義指標并產(chǎn)生相應費用。具體費用取決于您的集群規(guī)模和應用數(shù)量等因素。建議您在啟用此功能前,仔細閱讀阿里云Prometheus計費說明,了解自定義指標的免費額度和收費策略。您可以通過賬單和用量查詢,監(jiān)控和管理您的資源使用情況。
負載熱點打散重調(diào)度介紹
以下介紹負載熱點打散重調(diào)度相關(guān)的概念。
負載感知調(diào)度
調(diào)度器支持負載感知調(diào)度,能夠在調(diào)度時選擇負載較低的節(jié)點運行新的Pod。節(jié)點的利用率會隨著時間、集群環(huán)境變化、工作負載的流量或請求等動態(tài)變化,繼而導致集群內(nèi)節(jié)點間原本負載均衡的情況被打破,甚至有可能出現(xiàn)極端負載不均衡的情況,影響到工作負載運行時質(zhì)量。ack-koordinator組件提供重調(diào)度能力,防止負載出現(xiàn)極端不均衡的情況。通過將負載感知調(diào)度和熱點打散重調(diào)度結(jié)合使用,可以獲得集群良好的負載均衡效果。關(guān)于負載感知調(diào)度,請參見使用負載感知調(diào)度。
koord-descheduler模塊工作原理
ack-koordinator組件提供koord-descheduler模塊,其中LowNodeLoad插件負責感知負載水位并完成熱點打散重調(diào)度工作。與Kubernetes原生的Descheduler的插件LowNodeUtilization不同,LowNodeLoad是根據(jù)節(jié)點真實利用率決策重調(diào)度,而LowNodeUtilization是根據(jù)資源分配率決策重調(diào)度。
模塊執(zhí)行過程
koord-descheduler模塊周期性運行,每個周期內(nèi)的執(zhí)行過程分為以下三個階段。
數(shù)據(jù)收集:獲取集群內(nèi)的節(jié)點和工作負載信息,以及相關(guān)的資源利用率數(shù)據(jù)。
策略插件執(zhí)行。
下文以LowNodeLoad為例。
篩選負載熱點節(jié)點。關(guān)于節(jié)點分類,請參見下文LowNodeLoad負載水位參數(shù)說明。
遍歷熱點節(jié)點,從中篩選可以遷移的Pod,并進行排序。關(guān)于Pod打分排序,請參見下文Pod打分策略。
遍歷每個待遷移的Pod,檢查其是否滿足遷移條件,綜合考慮集群容量、資源利用率水位、副本數(shù)比例等約束。詳細信息,請參見下文負載熱點打散重調(diào)度策略說明。
若滿足條件則將Pod歸類為待遷移副本,若不滿足則繼續(xù)遍歷其他Pod和熱點節(jié)點。
容器驅(qū)逐遷移:針對待遷移的Pod發(fā)起Evict驅(qū)逐操作。關(guān)于Evict驅(qū)逐,請參見Evict驅(qū)逐。
LowNodeLoad負載水位參數(shù)說明
LowNodeLoad插件有兩個重要的參數(shù):
highThresholds:負載的熱點水位,超過該閾值的節(jié)點上的Pod將參與重調(diào)度。建議您同時開啟調(diào)度器的負載感知調(diào)度能力,請參見策略說明。關(guān)于兩者如何搭配使用,請參見負載感知調(diào)度和熱點打散重調(diào)度如何搭配使用?。
lowThresholds:負載的空閑水位,低于該閾值的節(jié)點上的Pod不會被重調(diào)度。
以下圖為例,將lowThresholds設(shè)置為45%,將highThresholds設(shè)置為70%,那么節(jié)點的分類標準如下。同理,如果lowThresholds和highThresholds的值發(fā)生變更,節(jié)點的分類標準也會相應發(fā)生變化。
資源利用率數(shù)據(jù)默認每分鐘更新一次,粒度為最近5分鐘的平均值。
空閑節(jié)點(Idle Node):資源利用率低于45%的節(jié)點。
正常節(jié)點(Normal Node):資源利用率高于等于45%且低于等于70%的節(jié)點。此節(jié)點的負載水位區(qū)間是期望達到的合理區(qū)間范圍。
熱點節(jié)點(Hotspot Node):資源利用率高于70%的節(jié)點。熱點節(jié)點將驅(qū)逐一部分Pod,降低負載水位,使其不超過70%。
負載熱點打散重調(diào)度策略說明
策略名稱 | 說明 |
熱點檢查重試次數(shù)策略 | 為了確保熱點識別的準確性,避免部分毛刺監(jiān)控數(shù)據(jù)觸發(fā)應用頻繁遷移,koord-descheduler支持為熱點檢查配置重試次數(shù)。只有節(jié)點連續(xù)多次觸發(fā)閾值時才會識別為熱點節(jié)點。 |
節(jié)點排序策略 | 在識別到的熱點節(jié)點中,koord-descheduler會按資源用量從高到低的順序,依次對節(jié)點發(fā)起重調(diào)度。其中,節(jié)點排序過程中會依次比較內(nèi)存資源用量和CPU資源用量,優(yōu)先選取資源用量更高的節(jié)點。 |
Pod打分策略 | 對于每個熱點節(jié)點,koord-descheduler會對其中的Pod逐個打分排序,依次發(fā)起驅(qū)逐操作,將其遷移到空閑節(jié)點上。比較順序如下:
說明 若您對Pod的驅(qū)逐順序有要求,建議您考慮對Pod配置不同的優(yōu)先級或QoS。 |
篩選策略 | koord-descheduler模塊支持為Pod和Node配置多種篩選參數(shù),方便您在使用過程中進行灰度控制。
|
前置檢查策略 | koord-descheduler模塊支持在Pod遷移前提供前置檢查能力,確保每個Pod的遷移過程盡量安全。
|
遷移流量控制策略 | 為了滿足Pod在遷移過程中應用的高可用要求,koord-descheduler模塊還提供多種類型的限制能力,支持配置節(jié)點維度、命名空間維度以及工作負載維度下處于遷移狀態(tài)Pod的最大數(shù)量。此外,它還提供基于時間窗口的流控機制,保證同一Workload下Pod的遷移不會過于頻繁。koord-descheduler同樣兼容K8s社區(qū)的干擾預算機制PDB(Pod Disruption Budgets),支持配置更精細的管理策略來保障工作負載的高可用。關(guān)于干擾預算機制,請參見干擾預算機制。 |
可觀測性策略 | 您可以通過Event觀測重調(diào)度的遷移過程,并在詳細信息中查看遷移的具體原因和當前狀態(tài)。樣例如下。
|
步驟一:安裝或修改組件ack-koordinator并開啟重調(diào)度
未安裝ack-koordinator組件
安裝ack-koordinator組件,并在安裝組件 ack-koordinator(ack-slo-manager)頁面選中ack-koordinator開啟重調(diào)度模塊。安裝ack-koordinator組件,請參見安裝ack-koordinator組件。
已安裝ack-koordinator組件
修改ack-koordinator組件,并在ack-koordinator參數(shù)配置頁面選中ack-koordinator開啟重調(diào)度模塊。修改ack-koordinator組件,請參見修改ack-koordinator組件。
步驟二:開啟負載熱點打散重調(diào)度插件
使用如下YAML文件,創(chuàng)建koord-descheduler-config.yaml。
koord-descheduler-config.yaml是ConfigMap格式的對象,用于啟用重調(diào)度插件LowNodeLoad。
# koord-descheduler-config.yaml apiVersion: v1 kind: ConfigMap metadata: name: koord-descheduler-config namespace: kube-system data: koord-descheduler-config: | # 以下為koord-desheduler系統(tǒng)配置,請保持不變。 apiVersion: descheduler/v1alpha2 kind: DeschedulerConfiguration leaderElection: resourceLock: leases resourceName: koord-descheduler resourceNamespace: kube-system deschedulingInterval: 120s # 執(zhí)行周期間隔,120s執(zhí)行一次重調(diào)度插件。 dryRun: false # 全局只讀模式開關(guān),開啟后koord-descheduler整體不做任何操作。 # 以上為系統(tǒng)配置。 profiles: - name: koord-descheduler plugins: deschedule: disabled: - name: "*" balance: enabled: - name: LowNodeLoad # 配置開啟負載熱點打散插件LowNodeLoad。 evict: disabled: - name: "*" enabled: - name: MigrationController # 配置開啟驅(qū)逐遷移控制器。 pluginConfig: - name: MigrationController # 重調(diào)度遷移控制參數(shù)。 args: apiVersion: descheduler/v1alpha2 kind: MigrationControllerArgs defaultJobMode: EvictDirectly - name: LowNodeLoad # 負載熱點打散插件配置。 args: apiVersion: descheduler/v1alpha2 kind: LowNodeLoadArgs lowThresholds: # lowThresholds表示空閑節(jié)點的準入水位閾值,判斷條件為“所有資源維度均低于閾值”。 cpu: 20 # CPU利用率為20%。 memory: 30 # Memory利用率為30%。 highThresholds: # highThresholds表示熱點節(jié)點的準入水位閾值,判斷條件為“只要有一個資源維度均高于閾值”。 cpu: 50 # CPU利用率為50%。 memory: 60 # Memory利用率為60%。 evictableNamespaces: # 參與重調(diào)度的Namespace,include和exclude是互斥的,只能配置其中一種。 include: # include表示只處理下面配置的Namespace。 - default # exclude: # exclude表示需要排除的Namespace。 # - "kube-system" # - "koordinator-system"
執(zhí)行如下命令,將配置更新到集群。
kubectl apply -f koord-descheduler-config.yaml
執(zhí)行如下命令,重啟重調(diào)度器模塊koord-descheduler。
重啟重調(diào)度器模塊koord-descheduler后,koord-descheduler會使用修改后的最新配置。
kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 0 deployment.apps/ack-koord-descheduler scaled kubectl -n kube-system scale deploy ack-koord-descheduler --replicas 1 deployment.apps/ack-koord-descheduler scaled
步驟三(可選):開啟調(diào)度器負載均衡插件
開啟調(diào)度器負載均衡插件,以獲得集群良好的負載均衡效果。具體操作步驟,請參見步驟一:開啟負載感知調(diào)度。
步驟四:驗證重調(diào)度能力
下文以擁有3臺104核 396 GB節(jié)點的集群為例進行說明。
使用如下YAML文件,創(chuàng)建stress-demo.yaml。
apiVersion: apps/v1 kind: Deployment metadata: name: stress-demo namespace: default labels: app: stress-demo spec: replicas: 6 selector: matchLabels: app: stress-demo template: metadata: name: stress-demo labels: app: stress-demo spec: containers: - args: - '--vm' - '2' - '--vm-bytes' - '1600M' - '-c' - '2' - '--vm-hang' - '2' command: - stress image: polinux/stress imagePullPolicy: Always name: stress resources: limits: cpu: '2' memory: 4Gi requests: cpu: '2' memory: 4Gi restartPolicy: Always
執(zhí)行如下命令,創(chuàng)建壓測Pod。
kubectl create -f stress-demo.yaml deployment.apps/stress-demo created
執(zhí)行如下命令,觀察Pod的狀態(tài),直到它開始運行。
kubectl get pod -o wide
預期輸出:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES stress-demo-588f9646cf-s**** 1/1 Running 0 82s 10.XX.XX.53 cn-beijing.10.XX.XX.53 <none> <none>
可以看到,Pod
stress-demo-588f9646cf-s****
調(diào)度在節(jié)點cn-beijing.10.XX.XX.53
上。提升節(jié)點
cn-beijing.10.XX.XX.53
的負載水位,然后執(zhí)行如下命令,檢查每個Node節(jié)點的負載。kubectl top node
預期輸出:
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% cn-beijing.10.XX.XX.215 17611m 17% 24358Mi 6% cn-beijing.10.XX.XX.53 63472m 63% 11969Mi 3%
可以看到,節(jié)點
cn-beijing.10.XX.XX.53
的負載較高,為63%,已經(jīng)超過配置的熱點水位50%。節(jié)點cn-beijing.10.XX.XX.215
負載較低,為17%,低于配置的空閑水位20%。開啟重調(diào)度。具體操作,請參見步驟二:開啟負載熱點打散重調(diào)度插件。
執(zhí)行如下命令,觀察Pod變化。
等待重調(diào)度器檢查熱點節(jié)點,并執(zhí)行驅(qū)逐遷移操作。
說明判定為熱點節(jié)點的默認條件為連續(xù)5次檢查節(jié)點均超過熱點水位,即10分鐘。
kubectl get pod -w
預期輸出:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES stress-demo-588f9646cf-s**** 1/1 Terminating 0 59s 10.XX.XX.53 cn-beijing.10.XX.XX.53 <none> <none> stress-demo-588f9646cf-7**** 1/1 ContainerCreating 0 10s 10.XX.XX.215 cn-beijing.10.XX.XX.215 <none> <none>
執(zhí)行如下命令,觀察Event。
kubectl get event | grep stress-demo-588f9646cf-s****
預期輸出:
2m14s Normal Evicting podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb**** Pod "default/stress-demo-588f9646cf-s****" evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)" 101s Normal EvictComplete podmigrationjob/00fe88bd-8d4c-428d-b2a8-d15bcdeb**** Pod "default/stress-demo-588f9646cf-s****" has been evicted 2m14s Normal Descheduled pod/stress-demo-588f9646cf-s**** Pod evicted from node "cn-beijing.10.XX.XX.53" by the reason "node is overutilized, cpu usage(68.53%)>threshold(50.00%)" 2m14s Normal Killing pod/stress-demo-588f9646cf-s**** Stopping container stress
預期輸出為遷移記錄,可以看出結(jié)果符合預期。熱點節(jié)點上的Pod被重調(diào)度到其他節(jié)點。
高級配置參數(shù)
koord-descheduler模塊高級配置參數(shù)介紹
koord-descheduler的所有參數(shù)配置以ConfigMap形式提供,以下展示了負載熱點打散重調(diào)度的高級配置參數(shù)格式。
# koord-descheduler-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: koord-descheduler-config
namespace: kube-system
data:
koord-descheduler-config: |
# 以下為koord-desheduler系統(tǒng)配置,請保持不變。
apiVersion: descheduler/v1alpha2
kind: DeschedulerConfiguration
leaderElection:
resourceLock: leases
resourceName: koord-descheduler
resourceNamespace: kube-system
deschedulingInterval: 120s # 執(zhí)行周期間隔,120s執(zhí)行一次重調(diào)度插件。
dryRun: false # 全局只讀模式開關(guān),開啟后koord-descheduler整體不做任何操作。
# 以上為系統(tǒng)配置。
profiles:
- name: koord-descheduler
plugins:
deschedule:
disabled:
- name: "*"
balance:
enabled:
- name: LowNodeLoad # 配置開啟負載熱點打散插件LowNodeLoad。
evict:
disabled:
- name: "*"
enabled:
- name: MigrationController # 配置開啟驅(qū)逐遷移控制器。
pluginConfig:
- name: MigrationController # 重調(diào)度遷移控制參數(shù)。
args:
apiVersion: descheduler/v1alpha2
kind: MigrationControllerArgs
defaultJobMode: EvictDirectly
maxMigratingPerNode: 1 # 每個節(jié)點處于遷移狀態(tài)的Pod的最大數(shù)量。
maxMigratingPerNamespace: 1 # 每個Namespace處于遷移狀態(tài)的Pod的最大數(shù)量。
maxMigratingPerWorkload: 1 # 每個Workload(例如Deployment)中處于遷移狀態(tài)的Pod的最大數(shù)量。
maxUnavailablePerWorkload: 2 # 每個Workload(例如Deployment)最大不可用副本數(shù)。
evictLocalStoragePods: false # 是否允許配置了HostPath或EmptyDir的Pod參與重調(diào)度
objectLimiters:
workload: # Workload級別Pod遷移的流量控制.默認為首次驅(qū)逐后,5分鐘內(nèi)最多遷移1個副本。
duration: 5m
maxMigrating: 1
- name: LowNodeLoad # 負載熱點打散插件配置。
args:
apiVersion: descheduler/v1alpha2
kind: LowNodeLoadArgs
lowThresholds: # lowThresholds表示空閑節(jié)點的準入水位閾值,判斷條件為“所有資源維度均低于閾值”。
cpu: 20 # CPU利用率為20%。
memory: 30 # Memory利用率為30%。
highThresholds: # highThresholds表示熱點節(jié)點的準入水位閾值,判斷條件為“只要有一個資源維度均高于閾值”。
cpu: 50 # CPU利用率為50%。
memory: 60 # Memory利用率為60%。
anomalyCondition: # 熱點節(jié)點檢查配置。
consecutiveAbnormalities: 5 # 連續(xù)多個執(zhí)行周期檢查中,均超過highThresholds的節(jié)點,才會被判定為熱點節(jié)點。熱點節(jié)點被驅(qū)逐后會重新計數(shù)。
evictableNamespaces: # 參與重調(diào)度的Namespace。include和exclude是互斥的,只能配置其中一種。
include: # include表示只處理下面配置的Namespace。
- default
# exclude: # exclude表示需要排除的Namespace。
# - "kube-system"
# - "koordinator-system"
nodeSelector: # 只處理指定的部分節(jié)點。
matchLabels:
alibabacloud.com/nodepool-id: np77f520e1108f47559e63809713ce****
podSelectors: # 只處理部分類型的Pod。
- name: lsPods
selector:
matchLabels:
koordinator.sh/qosClass: "LS"
koord-descheduler系統(tǒng)配置
參數(shù) | 類型 | 取值 | 說明 | 示例值 |
dryRun | boolean |
| 只讀模式開關(guān),開啟后將不會發(fā)起Pod遷移。 | false |
deschedulingInterval | time.Duration | >0s | 重調(diào)度執(zhí)行周期。 | 120s |
驅(qū)逐遷移控制配置
參數(shù) | 類型 | 取值 | 說明 | 示例值 |
maxMigratingPerNode | int64 | ≥0(默認值為2) | 每個節(jié)點處于遷移狀態(tài)的Pod的最大數(shù)量。0表示不限制。 | 2 |
maxMigratingPerNamespace | int64 | ≥0(默認不限制) | 每個命名空間處于遷移狀態(tài)的Pod的最大數(shù)量。0表示不限制。 | 1 |
maxMigratingPerWorkload | intOrString | ≥0(默認值為10%) | 每個工作負載(例如Deployment)中處于遷移狀態(tài)的Pod的最大數(shù)量或百分比。0表示不限制。 若工作負載只有單副本,則不參與重調(diào)度。 | 1或10% |
maxUnavailablePerWorkload | intOrString | ≥0(默認值為10%),且小于工作負載對應的副本總數(shù) | 每個工作負載(例如Deployment)最大不可用副本數(shù)或百分比。0表示不限制。 | 1或10% |
evictLocalStoragePods | boolean |
| 是否允許配置了HostPath或EmptyDir的Pod參與重調(diào)度。出于安全考慮,默認不開啟。 | false |
objectLimiters.workload | 結(jié)構(gòu)體,數(shù)據(jù)格式為:
|
| 工作級別Pod遷移的流量控制。
|
表示5分鐘內(nèi)單個工作負載最多遷移1個副本。 |
LowNodeLoad插件配置
參數(shù) | 類型 | 取值 | 說明 | 示例值 |
highThresholds | map[string]float64 說明 支持CPU和內(nèi)存兩個維度,值的單位為百分比。 | [0,100] | 表示負載的熱點水位,超過該閾值的節(jié)點上的Pod將參與重調(diào)度。 說明 可以和調(diào)度器的負載感知調(diào)度能力搭配使用,將節(jié)點篩選參數(shù)loadAwareThreshold配置為相同的值,調(diào)度器會拒絕將Pod調(diào)度到該熱點節(jié)點上,詳情請參見策略說明。 |
|
lowThresholds | map[string]float64 說明 支持CPU和內(nèi)存兩個維度,值的單位為百分比。 | [0,100] | 表示負載的空閑水位。低于該閾值的節(jié)點上的Pod不會被重調(diào)度。 |
|
anomalyCondition.consecutiveAbnormalities | int64 | >0(默認值為5) | 熱點檢查重試次數(shù)。連續(xù)多個執(zhí)行周期檢查后,均超過highThresholds的節(jié)點,才會被判定為熱點節(jié)點。熱點節(jié)點發(fā)生驅(qū)逐后會重新計數(shù)。 | 5 |
evictableNamespaces |
| 集群內(nèi)的命名空間 | 可以參與重調(diào)度的Namespace,不填表示所有Pod全部可參與。 支持配置include和exclude策略。兩種策略需二選一。
|
|
nodeSelector | metav1.LabelSelector | 關(guān)于LabelSelector的格式,請參見Labels and Selectors | 通過LabelSelector選擇目標節(jié)點。 | 分為兩種方式,一種是指定單個節(jié)點池時的配置方式,一個是指定多個節(jié)點池時的配置方式。
|
podSelectors | 由PodSelector組成的List,支持配置多組Pod。PodSelector的數(shù)據(jù)格式為:
| 關(guān)于LabelSelector的格式,請參見Labels and Selectors | 通過LabelSelector選擇開啟重調(diào)度的Pod。 |
|
常見問題
節(jié)點利用率閾值已經(jīng)達到閾值,但是節(jié)點上Pod沒有被驅(qū)逐怎么辦?
出現(xiàn)這種情況時,一般可能是有以下幾種原因,請參考對應的解決方法進行調(diào)整。
原因分類 | 原因描述 | 解決方法 |
組件配置未生效 | 開啟范圍未指定 | 重調(diào)度器配置中包含Pod和節(jié)點的開啟范圍配置,請檢查對應的命名空間和節(jié)點是否開啟。 |
重調(diào)度器配置修改后未重啟 | 重調(diào)度器配置修改后,需要對其進行重啟才能生效。關(guān)于重啟重調(diào)度器,請參見步驟二:開啟負載熱點打散重調(diào)度插件。 | |
節(jié)點狀態(tài)不滿足條件 | 節(jié)點的平均利用率長時間低于閾值 | 重調(diào)度器會持續(xù)對利用率監(jiān)控一段時間,并對監(jiān)控數(shù)據(jù)做平滑均值處理,因此只有節(jié)點持續(xù)超過閾值才會觸發(fā)重調(diào)度,默認為10分鐘左右。而 |
集群內(nèi)剩余的容量不足 | 在對Pod驅(qū)逐前,重調(diào)度器會對集群內(nèi)其他節(jié)點進行檢查,確保容量充足才會進行遷移。例如選擇了一個規(guī)格為8 Core 16 G的Pod準備驅(qū)逐,而集群所有節(jié)點的空閑容量均低于該值,出于安全考慮重調(diào)度器則不會對其遷移。請考慮增加節(jié)點,確保集群容量充足。 | |
工作負載屬性約束限制 | 工作負載為單副本 | 為了保證單副本應用的高可用,這類Pod默認不參與重調(diào)度。如果您評估此類單副本應用后,希望該Pod參與重調(diào)度,請給Pod或者工作負載(如Deployment或StatefulSet)的TemplateSpec中追加Annotation 說明 該Annotation配置僅支持v1.2.0-ack1.3及更早版本。 |
Pod指定了HostPath或EmptyDir | 出于安全考慮,這類指定了HostPath或EmptyDir的Pod默認不參與重調(diào)度。如果需要對其進行遷移,可以參考evictLocalStoragePods配置允許其參與重調(diào)度。詳細信息,請參見驅(qū)逐遷移控制配置。 | |
不可用或遷移中的副本數(shù)量過多 | 當工作負載(如Deployment或StatefulSet)的不可用或遷移中的副本數(shù)超過了限制配置(maxUnavailablePerWorkload或maxMigrationPerWorkload)。例如 maxUnavailablePerWorkload和maxMigrationPerWorkload設(shè)置為20%,Deployment的期望副本數(shù)設(shè)置為10,當前正好有2個Pod正在被驅(qū)逐或者正在發(fā)布,重調(diào)度器就不會對其發(fā)起驅(qū)逐。請等待Pod驅(qū)逐或發(fā)布完成,或?qū)⒁陨蟽蓚€配置調(diào)大。 | |
副本數(shù)量約束配置錯誤 | 當工作負載的副本總數(shù)小于等于最大遷移數(shù)量配置maxMigrationPerWorkload或最大不可用數(shù)量配置maxUnavailablePerWorkload時,出于安全考慮重調(diào)度器將不會對其進行重調(diào)度。請將以上兩個配置調(diào)小或修改為百分比模式。 |
重調(diào)度器頻繁重啟是什么原因?
重調(diào)度器的配置ConfigMap格式錯誤或不存在,請參考高級配置參數(shù)檢查ConfigMap文件內(nèi)容和格式并進行修改,修改后重啟重調(diào)度器。重啟重調(diào)度器,請參見步驟二:開啟負載熱點打散重調(diào)度插件。
負載感知調(diào)度和熱點打散重調(diào)度如何搭配使用?
開啟熱點打散重調(diào)度后,負載熱點上的Pod將會被驅(qū)逐。對于上層控制器(例如Deployment)新建的Pod,調(diào)度器會根據(jù)其配置選擇合適的節(jié)點進行調(diào)度。為了獲得更好的負載均衡效果,建議您同時為調(diào)度器開啟負載感知調(diào)度能力,請參見使用負載感知調(diào)度。
配置時,建議您將負載感知調(diào)度中的節(jié)點篩選功能參數(shù)loadAwareThreshold配置為與熱點打散重調(diào)度器的highThresholds參數(shù)相同的值,具體請參見策略說明。當節(jié)點的負載超過highThresholds時,重調(diào)度器將驅(qū)逐該節(jié)點上的Pod,而調(diào)度器則通過loadAwareThreshold拒絕新的Pod被調(diào)度到該熱點節(jié)點上。否則,經(jīng)驅(qū)逐的Pod可能重新被調(diào)度到原來的節(jié)點,尤其是在Pod指定了節(jié)點調(diào)度范圍,但對應的節(jié)點數(shù)量較少且利用率較為接近時。
重調(diào)度參考的利用率算法是什么?
重調(diào)度器會持續(xù)對利用率監(jiān)控一段時間,并對監(jiān)控數(shù)據(jù)做平滑均值處理,因此只有節(jié)點持續(xù)超過閾值才會觸發(fā)重調(diào)度,默認為10分鐘左右。此外對于內(nèi)存資源維度,重調(diào)度器參考的內(nèi)存用量排除了page cache,因為這部分資源是可以被操作系統(tǒng)回收的,而通過kubectl top node
返回的利用率是包含page cache的,您可以通過使用阿里云Prometheus監(jiān)控查看真實的內(nèi)存用量信息。