Kubernetes Kueue项目中Provisioning Admission Check的测试稳定性问题分析

问题背景

Kubernetes Kueue项目是一个用于管理Kubernetes工作负载队列的系统。在最近的项目测试中，发现了一个与Provisioning Admission Check相关的测试稳定性问题。该问题表现为在某些情况下，当工作负载(Workload)已被接纳(Admitted)且ProvisioningRequest的条件被设置为BookingExpired时，系统未能正确忽略变更。

问题现象

测试用例"Provisioning when A workload is using a provision admission check Should ignore the change if Workload is Admitted and the ProvisioningRequest's condition is set to BookingExpired"在多个版本的CI测试中出现了间歇性失败。失败表现为工作负载的AdmissionCheck状态意外地从"Ready"变为了"Rejected"，而测试期望的是系统应忽略这种变更。

技术分析

核心问题

问题的根本原因在于控制器之间的协调时序问题。具体来说：

1. 工作负载控制器(workload_controller)负责设置工作负载的Admitted状态
2. 供应控制器(provisioning_controller)负责处理ProvisioningRequest和相关的AdmissionCheck状态

这两个控制器的操作是异步进行的，在测试环境中，当ProvisioningRequest的状态被设置为BookingExpired时，供应控制器可能尚未感知到工作负载已被Admitted的状态变化。这导致供应控制器错误地更新了AdmissionCheck状态为Rejected，而不是忽略这个变更。

代码流程分析

测试的主要流程如下：

1. 首先将ProvisioningRequest设置为Provisioned状态
2. 验证工作负载是否被Admitted
3. 然后将ProvisioningRequest设置为BookingExpired状态

问题出现在第三步，当设置BookingExpired状态时，供应控制器可能尚未收到工作负载已被Admitted的通知，因此错误地执行了状态更新。

实际影响

虽然这是一个测试稳定性问题，但在实际生产环境中，由于BookingExpired通常是在10分钟后才会触发，控制器有足够的时间来同步状态，因此实际影响较小。但在测试环境中，由于所有操作都是快速连续执行的，这种时序问题就显现出来了。

解决方案

为了解决这个问题，可以采用以下方法：

1. 在测试代码中增加适当的等待时间，确保供应控制器有足够的时间来感知工作负载的Admitted状态
2. 或者在设置BookingExpired状态前，显式验证供应控制器已经处理了Admitted状态

这种解决方案既保持了测试的可靠性，又不会影响生产环境中的正常行为，因为生产环境中自然会有足够的时间让控制器同步状态。

总结

这个案例展示了在分布式系统中处理状态同步时可能遇到的典型问题。Kubernetes Kueue项目通过合理的控制器设计和测试改进，确保了系统在各种场景下的稳定性和可靠性。对于开发者而言，理解控制器之间的交互时序对于编写可靠的测试用例至关重要。