Kubernetes调度性能测试中PreemptionPVs测试失败问题分析

背景介绍

在Kubernetes的持续集成测试中，调度性能基准测试(scheduler-perf)中的PreemptionPVs测试最近出现了失败情况。这个测试主要用于评估调度器在需要抢占资源时的性能表现，特别是在涉及持久卷(Persistent Volumes)的场景下。

问题现象

测试失败表现为调度吞吐量(SchedulingThroughput)低于预期阈值。经过深入分析发现，这个问题只会在同时启用SchedulerPopFromBackoffQ和SchedulerAsyncPreemption两个特性门控时出现。

根本原因

通过对比不同特性组合下的测试结果，我们发现这不是代码缺陷导致的，而是测试设计本身存在问题：

1. 测试测量方式存在缺陷：性能测试从第一个Pod被调度时开始计时，并会忽略第一个和最后一个秒的测量数据
2. 新特性显著提高了调度速度：SchedulerAsyncPreemption特性使测试时间缩短了近一半
3. SchedulerPopFromBackoffQ特性进一步优化：减少了Pod在backoff队列中的等待时间

这两个特性的组合使得大多数Pod的调度都集中在最后一个测量秒内完成，而这部分数据恰好被测试框架忽略，导致测得的吞吐量偏低。

解决方案探讨

针对这个问题，团队提出了几种可能的解决方案：

1. 增加测试中调度的Pod数量，延长调度时间
2. 修改性能测试框架，使其包含最后一个不完整秒的测量数据
3. 将PreemptionPVs测试改为PreemptionPVsAsync测试，与现有的PreemptionAsync测试保持一致

经过讨论，团队首先尝试了第一种方案，即增加Pod数量。然而测试结果显示，即使增加Pod数量，大多数调度仍集中在最后一个秒内完成。这说明单纯增加Pod数量可能不是最佳解决方案。

临时解决方案

考虑到当前处于代码冻结期，团队决定先采取临时解决方案：

1. 暂时移除这些测试的吞吐量阈值限制
2. 待代码冻结期结束后，再重新评估和调整测试方案

技术启示

这个案例给我们带来了一些重要的技术启示：

1. 性能测试设计需要与时俱进：当核心组件性能显著提升时，原有的测试方法可能不再适用
2. 特性组合测试的重要性：单个特性测试可能通过，但特性组合可能产生意想不到的效果
3. 测试框架的局限性：需要定期评估测试框架是否仍能准确反映系统真实性能

对于Kubernetes这样的复杂系统，性能测试需要持续维护和更新，以确保它们能够准确反映系统在各种配置下的真实表现。