调度均衡：Descheduler 与资源碎片整理

场景一：节点池缩容后，剩余节点负载不均
场景二：批量驱逐（如节点维护）后，Pod 全部挤到少数节点
场景三：长期运行后，新老 Pod 混布导致资源碎片
场景四：拓扑约束与实时负载不匹配（某区 Pod 过密）
场景五：节点利用率极低但无法缩容（有不可驱逐的 Pod）

1. 列举所有 Node 与 Pod
2. 对每个策略生成候选驱逐列表
3. 过滤：PDB、优先级、本地存储、镜像亲和、守护进程
4. 执行 Eviction API（走 PDB 与准入）
5. 记录指标与事件，退出

apiVersion: descheduler/v1alpha2
kind: DeschedulerPolicy
profiles:
  - name: default
    pluginConfig:
      - name: DefaultEvictor
        args:
          evictSystemCriticalPods: false
          ignorePvcPods: true
          nodeFit: true
      - name: LowNodeUtilization
        args:
          thresholds: {cpu: 20, memory: 20, pods: 20}
          targetThresholds: {cpu: 50, memory: 50, pods: 50}
    plugins:
      balance:
        enabled: [LowNodeUtilization]
      deschedule:
        enabled: [RemovePodsHavingTooManyRestarts]

节点 A：剩余 2C4G      节点 B：剩余 2C4G      节点 C：剩余 2C4G
新 Pod 需要 4C8G -> 无法调度（尽管总空闲 6C12G）

思路一：提高装箱率 —— 用 HighNodeUtilization 把小 Pod 挤到一起，空出整台节点
思路二：保留缓冲节点 —— 预留一台低负载节点给大 Pod，靠优先级与亲和保护
思路三：规格分层 —— 按 Pod 规格划分节点池，避免大小混布
思路四：主动腾空 —— 配合缩容，把节点腾空后由 CA 回收

装箱率 = sum(已请求资源) / sum(可分配资源)
碎片率 = 1 - (可安放的最大 Pod 规格 / 单节点最大剩余)

underutilized（低于 thresholds）  -> 视为「欠载节点」，有 Pod 可被搬走
overutilized（高于 targetThresholds）-> 视为「过载节点」，需要减负
中间区间                          -> 视为合理，不动

第一道：thresholds 与 targetThresholds 之间留足间隔（至少 30 个百分点）
第二道：Descheduler 运行间隔足够长（>= 5 分钟），给调度器收敛时间
第三道：用 nodeFit + PDB + 优先级过滤，限制单次驱逐规模

- name: DefaultEvictor
  args:
    evictSystemCriticalPods: false
    ignorePvcPods: true
    nodeFit: true
    priorityThreshold:
      value: 10000

场景一：Pod 反亲和要求副本分散，但驱逐后全部落到同一节点
场景二：节点被打了新标签（如 zone 变更），旧的节点亲和不再匹配
场景三：扩缩容后拓扑打散约束被打破

- name: RemovePodsViolatingTopologySpreadConstraint
  args:
    constraints: [DoNotSchedule, ScheduleAnyway]
    includeSoftConstraints: true
- name: RemovePodsViolatingInterPodAntiAffinity
  args: {}
- name: RemovePodsViolatingNodeAffinity
  args:
    nodeAffinityType: [requiredDuringSchedulingIgnoredDuringExecution]

kubectl get pods -l app=api -o custom-columns=\
NODE:.spec.nodeName --no-headers | sort | uniq -c

- name: RemoveDuplicates
  args:
    excludeOwnerKinds: ["DaemonSet"]

Cluster Autoscaler（CA）：节点层，按调度失败扩容、按低利用率缩容
Descheduler：Pod 层，整理分布，让节点负载均衡

阻塞一：节点上有 kube-system 之外的系统 Pod（如日志采集 DaemonSet 之外的组件）
阻塞二：Pod 有 PDB 且 minAvailable 阻止驱逐
阻塞三：Pod 使用 emptyDir 或本地存储（CA 默认不移除）
阻塞四：Pod 不受控制器管理（裸 Pod，CA 默认不移除）

Descheduler 运行间隔：10 分钟
CA 缩容延迟：10~15 分钟（unneeded time）
顺序：先让 Descheduler 腾空节点，再让 CA 在延迟窗口后缩容

第一道：PodDisruptionBudget —— Eviction API 会自动遵守
第二道：优先级与 Preemption —— 高优先级 Pod 不应被搬动
第三道：nodeFit —— 确保有地方可去
第四道：maxNoOfPodsToEvictPerNode / maxNoOfPodsToEvictPerNamespace —— 限制单次规模

descheduler_pods_evicted_total{strategy,result}   驱逐数量与结果
descheduler_build_info                            版本信息
kube_pod_container_resource_requests              按节点聚合的请求量

均衡度 = stddev(node_cpu_request_ratio)  —— 越小越均衡

kubectl -n kube-system logs job/descheduler-xxxxx --tail=100
kubectl get events --field-selector reason=Evicted -A | tail -20
kubectl get pods -A -o wide | awk '{print $8}' | sort | uniq -c | sort -rn

1. 用 --dry-run 运行一次，查看候选驱逐列表
2. 在 staging 环境以最长间隔、最小阈值运行一周
3. 观察 P99 延迟与错误率是否受影响
4. 逐条启用策略，每次只加一个
5. 生产环境先设 maxNoOfPodsToEvictPerRun=5 观察

□ 所有多副本工作负载配置 PDB
□ DefaultEvictor 开启 nodeFit 与 priorityThreshold
□ 设置 maxNoOfPodsToEvictPerNode 与 PerRun 上限
□ ignorePvcPods=true 保护有状态服务
□ 阈值间隔至少 30 个百分点，避免震荡
□ 运行间隔 >= 10 分钟，给调度器与 CA 收敛时间
□ 与 Cluster Autoscaler 的缩容延迟对齐
□ 监控驱逐数量与节点利用率标准差
□ 策略纳入 Git，逐条灰度启用
□ 上线前用 dry-run 与 staging 验证