成功资源负载感知 调度 Koordinator 经常使用 重
Koordinator 是一个基于 QoS 的 Kubernetes 混合上班负载调度系统。它旨在提高对提前敏感的上班负载和批处置作业的运转时效率和牢靠性，简化与资源相关的性能调整的复杂性，并参与 Pod 部署密度以提高资源应用率。
Koordinator 是具有高性能、可裁减的， 在大规模消费环境中失掉了验证的，可以构建支持企业消费环境的容器编排系统。
Koordinator 经过提供以下性能增强了在 Kubernetes 中治理上班负载的用户体验：
Koordinator QoS vs Kubernetes QoS
Kubernetes 提供三种类型的 QoS：Guaranteed/Burstable/BestEffort，其中Guaranteed/Burstable被宽泛经常使用BestEffort很少经常使用。Koordinator 与 Kubernetes QoS 兼容，并且对每种类型都有许多增强性能。为了防止搅扰原生 QoS 语义，Koordinator 引入了一个独立的字段koordinator.sh/qosClass来形容混部 QoS。该 QoS 形容了在混部场景中节点上运转的 Pod 的服务品质。它是混合系统最关键的语义。
Koordinator 与 Kubernetes QoS 兼容，并且对每种类型都有许多增强性能。
Koordinator scheduler vs kube-scheduler
Koordinator 调度器并非旨在取代 kube-scheduler，而是为了让混部的上班负载在 kubernetes 上运转得更好。
Koordinator 调度器是基于 schedule-framework 开发的，在原生调度才干之上参与了与混部和优先级抢占相关的调度插件。Koordinator 将努力于推进相关的增强进入 Kubernetes 的抢先社区，推进混部技术的规范化。
Koordinator 由两个控制面（Koordinator Scheduler/Koordinator Manager）和一个 DaemonSet 组件(Koordlet)组成。Koordinator 在 Kubernetes 原有的才干基础上参与了混部性能，并兼容了 Kubernetes 原有的上班负载。
上方是 Koordinator 的外围相关组件：
Koord-Scheduler
Koord-Scheduler 以 Deployment 的方式部署在集群中，用于增强 Kubernetes 在 QoS-aware，差异化 SLO 以及义务调度场景的资源调度才干，详细包括:
为了更好的支持不同类型的上班负载，Koord-scheduler 还包括了一些通用性的才干增强：
Koord-Decheduler
Koord-Decheduler 以 Deployment 的方式部署在集群中，它是 kubernetes 抢先社区的增强版本，蕴含:
Koord-Manager
Koord-Manager 以 Deployment 的方式部署，通常由两个实例组成，一个 leader 实例和一个 backup 实例。Koordinator Manager 由几个控制器和 webhooks 组成，用于协调混部场景下的上班负载，资源超卖(resource overcommitment)和 SLO 治理。
目前，提供了三个组件:
Koordlet 以 DaemonSet 的方式部署在 Kubernetes 集群中，用于支持混部场景下的资源超卖(resource overcommitment)、搅扰检测、QoS 保证等。
在 Koordlet 外部，它关键包括以下模块:
Koord-RuntimeProxy
Koord-RuntimeProxy 以 systemd service 的方式部署在 Kubernetes 集群的节点上，用于代理 Kubelet 与 containerd/docker 之间的 CRI 恳求。这一个代理被设计来支持精细化的资源治理战略，比如为不同 QoS Pod 设置不同的 cgroup 参数，包括内核 cfs quota，resctl 等等技术个性，以改良 Pod 的运转时品质。
混部是一套资源调度处置打算，用于对提前敏感的上班负载与大数据计算上班负载启动精细化编排。它须要处置两个关键疑问:
定义
Resource Model
上图是 Koordinator 的混部资源模型，其基本思维是应用那些已调配但未经常使用的资源来运转低优先级的 pod。如图所示，有四条线:
整个混部资源调度是基于上图所示的资源模型构建的，不只可以满足各种上班负载的资源需求，还可以充沛应用集群的闲置资源。
SLO 形容
在集群中运转的 Pod 资源 SLO 由两个概念组成，即优先级和 QoS。
须要留意的是，Priority 和 QoS 是两个维度的概念，但在实践业务场景中，两者之间会有一些解放（不是一切的组合都是非法的）。
Koordinator 在 Kubernetes 优先级类型的基础上定义了一套规范，并裁减了优先级的一个维度以对混部场景的细粒度支持。
优先级用数字示意，目前定义了四个类:
PriorityClass 目前留有一些暂未经常使用的区间，以支持未来或许的裁减。
Koordinator 将不同类型的上班负载婚配到不同的优先级:
Koordinator 在 Kubernetes 集群中部署时会初始化这四个 PriorityClass：
apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata:name: koord-prodvalue: 9000description: "This priority class should be used for prod service pods only."---apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata:name: koord-midvalue: 7000description: "This priority class should be used for mid service pods only."---apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata:name: koord-batchvalue: 5000description: "This priority class should be used for batch service pods only."---apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata:name: koord-freevalue: 3000description: "This priority class should be used for free service pods only."在每个 PriorityClass 内，Koordinator 准许用户为精细化资源调度设置混部 Pod 的优先级。
比如上方的 YAML 是一个 Pod 性能的例子，它经常使用了前面例子中创立的 PriorityClass 和优先级。
apiVersion: v1kind: Podmetadata:name: nginxlabels:env: testkoordinator.sh/priority: "5300"spec:containers:- name: nginximage: nginximagePullPolicy: IfNotPresentpriorityClassName: koord-batchQoS 用于表白节点上 Pod 的运转品质，如失掉资源的方式、失掉资源的比例、QoS 保证战略等。
Koordinator 调度系统支持的 QoS 有五种类型:
QoS CPU 编排隔离与共享
Koordinator QoS 与 Kubernetes QoS 的对比
从上方可以看出，Koordinator 的 QoS 比 Kubernetes 的 QoS 更复杂，由于在混部场景下，咱们须要对提前敏感的上班负载的 QoS 启动微调，以满足混部时性能的需求。Koordinator 和 Kubernetes QoS 之间是有对应相关的:
Koordlet 依据 Pod 的优先级和 QoS 定义，触发相应的资源隔离和 QoS 保证。
Koordinator 依赖 1.18 及以上版本的 Kubernetes。另外 Koordinator 或许会从 kubelet 只读端口搜集目的（自动设置为禁用，即驳回了安保端口）。
这里咱们介绍经常使用 Helm 装置：
helm repo add koordinator-shrepo updatehelm install koordinator koordinator-sh/koordinator --version 1.5.0 --set imageRepositoryHost=registry.cn-beijing.aliyuncs.com --set manager.hostNetwork=true上方的命令自动会装置在koordinator-systemnamespace 下，假设须要装置在其余 namespace 下，可以经常使用installation.namespace参数，咱们可以经常使用kubectl get pods -n koordinator-system命令检查装置的组件。
$ kubectl get pods -n koordinator-systemNAMEREADYSTATUSRESTARTSAGEkoord-descheduler-7569579bc-knr851/1Running07m8skoord-manager-8897597b6-79wck1/1Running07m8skoord-scheduler-78bccfc65c-wt2n61/1Running07m8skoordlet-972kj1/1Running07m8skoordlet-kmtqh1/1Running07m8skoordlet-s9c4s1/1Running07m8s如今咱们就可以经常使用 Koordinator 来调度咱们的上班负载了。
负载感知调度（Load Aware Scheduling）是 koord-scheduler 提供的一种调度才干，调度 Pod 时依据节点的负载状况选用适合的节点，平衡节点间的负载状况。
负载平衡是资源调度中的经常出现疑问。资源未充沛应用的节点会带来很大的资源糜费，而适度经常使用的节点或许会造成性能降低。这些疑问都不能高效的治理和经常使用资源。原生 Kubernetes Scheduler 依据 Requests 和节点可调配总量来调度 Pod，既不思索实时负载，也不预计经常使用量。当咱们希冀经常使用原生调度器平均的打散 Pod 并坚持节点间的负载平衡，咱们须要为运行程序设置准确的资源规格。此外，当 Koordinator 经过超卖机制优化资源经常使用效率时，咱们须要一种机制尽量防止性能回退，并防止负载过高的疑问。
Koordinator 调度插件过滤意外节点并依据资源经常使用状况对其启动评分。这个调度插件裁减了 Kubernetes 调度框架中定义的 Filter/Score/Reserve/Unreserve 裁减点。
过滤不肥壮的节点
自动过滤意外节点，然而用户可以依据须要经过性能来选择能否开启。
评分算法
评分算法的外围逻辑是选用资源经常使用量最小的节点。然而思索到资源经常使用上报的提前和 Pod 启动时期的提前，时期窗口内曾经调度的 Pod 和正在调度的 Pod 的资源恳求也会被预算进去，并且预算值将介入计算。
关于须要深化定制的用户，可以经过修正 Helm Chart 中的 ConfigMap
koord-scheduler-config
规定来性能负载感知调度。
apiVersion: v1kind: ConfigMapmetadata:name: koord-scheduler-config...data:koord-scheduler-config: |apiVersion: kubescheduler.config.k8s.io/v1beta2kind: KubeSchedulerConfigurationprofiles:- schedulerName: koord-schedulerplugins:filter:# 过滤enabled:- name: LoadAwareScheduling# 启用负载感知调度插件...score: # 打分enabled:- name: LoadAwareSchedulingweight: 1 # 打分权重...reserve:# 预留资源enabled:- name: LoadAwareScheduling...pluginConfig: # 性能阈值和权重- name: LoadAwareSchedulingargs:apiVersion: kubescheduler.config.k8s.io/v1beta2kind: LoadAwareSchedulingArgsfilterExpiredNodeMetrics: true# 能否过滤掉不可更新 NodeMetric 的节点nodeMetricExpirationSeconds: 300# 经常使用 NodeMetric 的过时时期# 资源权重resourceWeights:cpu: 1memory: 1usageThresholds:# 资源应用率阈值cpu: 75memory: 85prodUsageThresholds:# prod资源应用率阈值cpu: 55memory: 65scoreAccordingProdUsage: true# 能否依据prod资源应用率阈值启动打分estimatedScalingFactors:# 资源应用率预算因子cpu: 80memory: 70aggregated:# 资源应用率百分比统计usageThresholds:cpu: 65memory: 75usageAggregationType: "p99"scoreAggregationType: "p99"可性能的参数如下所示：
|
字段 |
说明 |
版本 |
|
filterExpiredNodeMetrics 示意能否过滤 koordlet 更新 NodeMetric 失败的节点。自动状况下启用，但在 Helm chart 中，它被禁用。 |
||
|
nodeMetricExpirationSeconds 批示 NodeMetric 过时时期（以秒为单位）。当 NodeMetrics 过时时，节点被以为是意外的。默以为 180 秒。 |
||
|
resourceWeights 示意资源的权重。CPU 和 Memory 的权重自动都是 1。 |
||
|
usageThresholds 示意零件的资源应用率阈值。CPU 的自动值为 65%，内存的自动值为 95%。 |
||
|
estimatedScalingFactors 示意预计资源经常使用时的因子。CPU 自动值为 85%，Memory 自动值为 70%。 |
||
|
prodUsageThresholds 示意 Prod Pod 相关于零件的资源应用率阈值。自动状况下不启用。 |
||
|
scoreAccordingProdUsage 控制能否依据 Prod Pod 的应用率启动评分。 |
||
|
aggregated 支持基于百分位数统计的资源应用率过滤和评分。 |
Aggregated 支持的字段:
|
字段 |
说明 |
版本 |
|
usageThresholds 示意机器基于百分位统计的资源应用率阈值。 |
||
|
usageAggregationType 示意过滤机遇器应用率的百分位类型。目前支持avg、p50、p90、p95和p99。 |
||
|
usageAggregatedDuration 示意过滤机遇器应用率百分位数的统计周期。不设置该字段时，调度器自动经常使用 NodeMetrics 中最大周期的数据。 |
||
|
scoreAggregationType 示意评分机遇器应用率的百分位类型。目前支持avg、p50、p90、p95和p99。 |
||
|
scoreAggregatedDuration 示意打分时 Prod Pod 应用率百分位的统计周期。不设置该字段时，调度器自动经常使用 NodeMetrics 中最大周期的数据。 |
经过插件的性能可以作为集群自动的全局性能，当然用户也可以经过在节点上附加annotation来设置节点维度的负载阈值。当节点上存在 annotation 时，会依据注解指定的参数启动过滤。
咱们这里的集群一共三个节点：
上方咱们创立一个如下所示的 Deployment 来测试负载感知调度：
# pod-stress.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: stress-demonamespace: defaultlabels:app: stress-demospec:selector:matchLabels:app: stress-demotemplate:metadata:name: stress-demolabels:app: stress-demospec:containers:- args:- "--vm"- "2"- "--vm-bytes"- "1600M"- "-c"- "3"- "--vm-hang"- "3"command:- stressimage: jockerhub.com/polinux/stressimagePullPolicy: Alwaysname: stressschedulerName: koord-scheduler # use the koord-scheduler间接创立上方的 Deployment 即可：
$ kubectl apply -f pod-stress.yamldeployment.apps/stress-demo created创立成功后观察 Pod 的形态：
$ kubectl get pods -owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATED NODEREADINESS GATESstress-demo-64968d6446-8wdtr1/1Running089s10.0.1.5node2<none><none>可以看到 Pod 曾经调度到了node2节点上。
如今咱们可以审核下每个节点的负载状况：
$ kubectl top pods stress-demo-64968d6446-8wdtrNAMECPU(cores)MEMORY(bytes)stress-demo-64968d6446-8wdtr2979m3206Mi$ kubectl top nodesNAMECPU(cores)CPU%MEMORY(bytes)MEMORY%master92m4%2682Mi71%node154m1%1761Mi22%node21711m42%4381Mi56%从上方输入结果显示，节点node1的负载最低（master 不思索），node2的负载最高。
接上去咱们再部署几个 Pod 来测试下成果：
# nginx-with-loadaware.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: nginx-with-loadawarelabels:app: nginxspec:replicas: 6selector:matchLabels:app: nginxtemplate:metadata:name: nginxlabels:app: nginxspec:schedulerName: koord-scheduler # use the koord-schedulercontainers:- name: nginximage: jockerhub.com/library/nginxresources:limits:cpu: 100mrequests:cpu: 100m雷同间接创立上方的 Deployment：
$ kubectl apply -f nginx-with-loadaware.yamldeployment.apps/nginx-with-loadaware created创立成功后审核nginx这些 Pods 的调度结果：
$ kubectl get pods -owideNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATED NODEREADINESS GATESnginx-with-loadaware-57db6b7758-6gbfz1/1Running078s10.0.2.187node1<none><none>nginx-with-loadaware-57db6b7758-gvxdk1/1Running078s10.0.2.243node1<none><none>nginx-with-loadaware-57db6b7758-hzdqf1/1Running077s10.0.2.200node1<none><none>nginx-with-loadaware-57db6b7758-n779g1/1Running077s10.0.2.69node1<none><none>nginx-with-loadaware-57db6b7758-trt641/1Running078s10.0.1.156node1<none><none>nginx-with-loadaware-57db6b7758-xtvsh1/1Running077s10.0.1.75node2<none><none>咱们可以看到 nginx pods 绝大部分都被调度在 node2 (负载最高的节点) 以外的节点上。
感知 Prod Pods 的负载启动调度
假设一个 Node 中调度了很多 BestEffort Pod，或许会由于节点的负载已到达经常使用限度而造成提前敏感的 Pod 不可调度。在 Koordinator v1.1.0 中，负载感知调度针对这种场景启动了优化。关于提前敏感（LSE/LSR/LS）的 Pod，优先调度到 Prod Pod 总应用率较低的节点，而 BestEffort(BE) Pod 依据零件应用率水平启动调度。
经过设置以下参数启用相关优化：
|
字段 |
说明 |
版本 |
|
prodUsageThresholds 示意 Prod Pod 相关于零件的资源应用率阈值。自动状况下不启用。 |
||
|
scoreAccordingProdUsage 控制能否依据 Prod Pod 的应用率启动评分。 |
感知基于百分位数统计的应用率启动调度
Koordinator v1.0 及以前的版本都是依照 koordlet 上报的平均应用率数据启动过滤和打分。但平均值暗藏了比拟多的信息，因此在 Koordinator v1.1 中 koordlet 新增了依据百分位数统计的应用率聚合数据。调度器侧也跟着做了相应的适配。
经过设置以下参数启用相关优化：
|
字段 |
说明 |
版本 |
|
aggregated 支持基于百分位数统计的资源应用率过滤和评分。 |
Aggregated 支持的字段:
|
字段 |
说明 |
版本 |
|
usageThresholds 示意机器基于百分位统计的资源应用率阈值。 |
||
|
usageAggregationType 示意过滤机遇器应用率的百分位类型。目前支持avg、p50、p90、p95和p99。 |
||
|
usageAggregatedDuration 示意过滤机遇器应用率百分位数的统计周期。不设置该字段时，调度器自动经常使用 NodeMetrics 中最大周期的数据。 |
||
|
评分机遇器应用率的百分位类型。目前支持avg、p50、p90、p95和p99。 |
||
|
scoreAggregatedDuration 示意打分时 Prod Pod 应用率百分位的统计周期。不设置该字段时，调度器自动经常使用 NodeMetrics 中最大周期的数据。 |
aggregated和usageThresholds参数是互斥的。当两者都性能时，将经常使用aggregated。
调度器中支持的负载感知调度能够在调度时选用负载较低的节点运转新的 Pod，但随着时期、集群环境变动以及上班负载面对的流量/恳求的变动时，节点的应用率会灵活的出现变动，集群内节点间原本负载平衡的状况被冲破，甚至有或许出现极其负载不平衡的状况，影响到上班负载运转时品质。
koord-descheduler 组件中LowNodeLoad插件担任感知负载水位成功热点打散重调度上班。LowNodeLoad 插件 与 Kubernetes 原生的 descheduler 的插件 LowNodeUtilization 不同的是，LowNodeLoad 是依据节点实在应用率的状况决策重调度，而 LowNodeUtilization 是依据资源调配率决策重调度。
LowNodeLoad 插件有两个最关键的参数：
以下图为例，lowThresholds 为 45%，highThresholds 为 70%，咱们可以把节点归为三类：
在识别出哪些节点是热点后，koord-descheduler 将会口头迁徙驱逐操作，驱逐热点节点中的部分 Pod 到闲暇节点上。假设 Idle Node 数量是 0 或许 Hotspot Node 数量是 0，则 descheduler 不会口头任何操作。
假设一个集群中闲暇节点的总数并不是很多时会中断重调度。这在大型集群中或许会有所协助，在大型集群中，一些节点或许会经常或短时期经常使用无余。自动状况下，numberOfNodes设置为零。可以经过设置参数 numberOfNodes 来开启该才干。
在迁徙前，koord-descheduler 会计算出实践闲暇容量，确保要迁徙的 Pod 的实践应用率之和不超越集群内闲暇总量。这些实践闲暇容量来自于闲暇节点，一个闲暇节点实践闲暇容量 = (highThresholds - 节点负载) _ 节点总容量。假定节点 A 的负载水位是 20%，highThresholdss 是 70%，节点 A 的 CPU 总量为 96C，那么 (70%-20%) _ 96 = 48C，这 48C 就是可以承载的闲暇容量了。
另外，在迁徙热点节点时，会过滤挑选节点上的 Pod，目前 koord-descheduler 支持多种挑选参数，可以防止迁徙驱逐十分关键的 Pod:
当挑选出 Pod 后，从 QoSClass、Priority、实践用量和创立时期等多个维度对这些 Pod 排序。
挑选 Pod 并成功排序后，开局口头迁徙操作。迁徙前会审核残余闲暇容量能否满足和节点的负载水位能否高于目的安保阈值，假设这两个条件中的一个不能满足，将中止重调度。每迁徙一个 Pod 时，会预扣残余闲暇容量，同时也会调整节点的负载水位，直到残余容量无余或许水位到达安保阈值。
须要留意 ⚠️ 的是负载感知重调度自动是禁用的，可以经过修正性能 ConfigMapkoord-descheduler-config启用该才干。关于须要深化定制的用户，可以依照须要更改 Helm Chart 中的 ConfigMapkoord-descheduler-config设置参数。
apiVersion: v1kind: ConfigMapmetadata:name: koord-descheduler-config...data:koord-descheduler-config: |apiVersion: descheduler/v1alpha2kind: DeschedulerConfiguration...# 口头 LowNodeLoad 插件的距离时期deschedulingInterval: 60sprofiles:- name: koord-deschedulerplugins:deschedule:disabled:- name: "*"balance:enabled:- name: LowNodeLoad# Configure to enable the LowNodeLoad plugin....pluginConfig:- name: LowNodeLoadargs:apiVersion: descheduler/v1alpha2kind: LowNodeLoadArgsevictableNamespaces:# include 和 exclude 是互斥的，只能性能一个# include 示意只处置上方性能的 namespace# include:#- test-namespace# exclude 示意只处置除上方性能的 namespace 以外的 namespaceexclude:- "kube-system"- "koordinator-system"# lowThresholds 定义资源应用率的低阈值lowThresholds:cpu: 20memory: 30# highThresholds 定义资源应用率的高阈值highThresholds:cpu: 50memory: 60....除了上方这些性能之外还有其余一些性能，可以参看上方的表格：
|
字段 |
说明 |
|
DryRun 示意只口头重调度逻辑，但不重复啊迁徙/驱逐 Pod |
|
|
NumberOfNodes 可以性能为仅当未充沛应用的节点数高于性能值时才激活该战略。这在大型集群中或许会有所协助，在大型集群中，一些节点或许会经常或短时期经常使用无余。自动状况下，NumberOfNodes 设置为零。 |
|
|
可以介入重调度的 Namespace。可以性能 include 和 exclude 两种，但两种战略只能二选一。include 示意只处置指定的 namespace；exclude 示意只处置指定之外的 namespace。 |
|
|
经过 label selector 机制选用目的节点。 |
|
|
示意能否依照备选要迁徙的 Pod 中指定的 Node Affinity/Node Selector/Resource Requests/TaintToleration 判别能否有闲暇节点。没有则不介入调度。自动开启。可以设置为 false 禁用该才干。 |
|
|
假设 useDeviationThresholds 设置为 true，则阈值被视为与平均资源经常使用率的百分比偏向。lowThresholds 将从一切节点的平均值中减去，highThresholds 将参与到平均值中。高于此窗口的资源消耗被视为适度应用的，即热点节点。 |
|
|
示意负载水位的目的安保阈值，超越该阈值的节点上的 Pod 将介入重调度。 |
|
|
示意负载水位的闲暇安保水位。低于该阈值的节点上的 Pod 不会被重调度。 |
雷同接上去咱们从新创立 stress Pods 来测试下成果：
# pod-stress.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: stress-demonamespace: defaultlabels:app: stress-demospec:selector:matchLabels:app: stress-demotemplate:metadata:name: stress-demolabels:app: stress-demospec:containers:- args:- "--vm"- "2"- "--vm-bytes"- "2000M"- "-c"- "4"- "--vm-hang"- "200"command:- stressimage: jockerhub.com/polinux/stressimagePullPolicy: Alwaysname: stressschedulerName: koord-scheduler # use the koord-scheduler间接创立上方的 Deployment：
$ kubectl apply -f pod-stress.yamldeployment.apps/stress-demo created创立成功后审核 Pod 的调度结果：
$ kubectl get pods -owide -l app=stress-demoNAMEREADYSTATUSRESTARTSAGEIPNODENOMINATED NODEREADINESS GATESstress-demo-7cc84459c9-4b5wc1/1Running012s10.0.1.46node2<none><none>可以看到这个 Pod 区分调度到了 node2 节点上。
如今咱们审核下节点的负载状况：
$ kubectl top nodesNAMECPU(cores)CPU%MEMORY(bytes)MEMORY%master78m3%2381Mi63%node164m1%1527Mi19%node21844m46%5266Mi67%可以看到 node2 的负载都挺高的，接上去咱们更新下koord-descheduler-config性能，启用负载感知重调度的插件LowNodeLoad。而后观察前面咱们创立的 nginx Pod 的调度状况：
$ kubectl get pods -wNAMEREADYSTATUSRESTARTSAGEstress-demo-7cc84459c9-qk85s1/1Running04snginx-with-loadaware-57c7bbbbc-btz7g1/1Running06m13snginx-with-loadaware-57c7bbbbc-btz7g1/1Terminating06m13snginx-with-loadaware-57c7bbbbc-btz7g1/1Terminating06m13snginx-with-loadaware-57c7bbbbc-8dz960/1Pending00snginx-with-loadaware-57c7bbbbc-8dz960/1Pending00snginx-with-loadaware-57c7bbbbc-8dz960/1Pending00snginx-with-loadaware-57c7bbbbc-8dz960/1ContainerCreating00snginx-with-loadaware-57c7bbbbc-2hc8r1/1Running06m13snginx-with-loadaware-57c7bbbbc-2hc8r1/1Terminating06m13snginx-with-loadaware-57c7bbbbc-2hc8r1/1Terminating06m13snginx-with-loadaware-57c7bbbbc-97shv0/1Pending00snginx-with-loadaware-57c7bbbbc-97shv0/1Pending00snginx-with-loadaware-57c7bbbbc-97shv0/1Pending00snginx-with-loadaware-57c7bbbbc-97shv0/1ContainerCreating00snginx-with-loadaware-57c7bbbbc-btz7g0/1Terminating06m14snginx-with-loadaware-57c7bbbbc-2hc8r0/1Terminating06m14snginx-with-loadaware-57c7bbbbc-2hc8r0/1Terminating06m14snginx-with-loadaware-57c7bbbbc-2hc8r0/1Terminating06m14snginx-with-loadaware-57c7bbbbc-btz7g0/1Terminating06m14snginx-with-loadaware-57c7bbbbc-btz7g0/1Terminating06m14snginx-with-loadaware-57c7bbbbc-8dz961/1Running03snginx-with-loadaware-57c7bbbbc-97shv1/1Running03s观察 Events 信息，可以看到如下所示的迁徙记载：
$ kubectl get event |grep Descheduled3m37sNormalDescheduledpod/nginx-with-loadaware-57c7bbbbc-2hc8rPod evicted from node "master" by the reason "node is overutilized, memory usage(57.92%)>threshold(50.00%)"57sNormalDescheduledpod/nginx-with-loadaware-57c7bbbbc-8dz96Pod evicted from node "node2" by the reason "node is overutilized, cpu usage(75.22%)>threshold(45.00%), memory usage(65.70%)>threshold(50.00%)"3m37sNormalDescheduledpod/nginx-with-loadaware-57c7bbbbc-btz7gPod evicted from node "master" by the reason "node is overutilized, memory usage(57.98%)>threshold(50.00%)"57sNormalDescheduledpod/nginx-with-loadaware-57c7bbbbc-jhdmdPod evicted from node "node2" by the reason "node is overutilized, cpu usage(75.22%)>threshold(45.00%), memory usage(65.65%)>threshold(50.00%)"如今 Pod 就从高负载的 node2 节点上迁徙到了其余节点上去。
上方引见的这些性能只是 Koordinator 提供的负载感知性能，还有更多弱小的性能期待大家去探求。
