CleanUpOldVMs 和 CleanUpOldPodsLoop 的评论包括：
这是删除偏离正常删除过程的虚拟机的安全性机制。虚拟机是用来运行单个构建的，应该由控制进程关闭。由于各种类型的故障，它们可能会被困住。为了防止它们被困住并永远浪费资源，我们在创建时为它们设置 "delete-at" 元数据属性，以便在某个时间点超过它们的预期生命周期。
这个机制需要维护构建的超时时间，始终是“远远超过它们的预期生命周期”。如果这不再成立，也取决于 #42699 的状态，由于多次重试(如2021-2022年中 #49666 和 #52591 中发生的情况),资源可能会被浪费。
由于协调器知道它启动的所有构建，并且已经删除了它不知道的构建(例如，因为它们是前一个协调器示例的遗留物),我认为实际上不需要计时器。然而，处理停滞或其他意外原因，使构建继续超出“合理”的时间范围可能仍然有用。因此，也许我们总是需要维护这样的超时。
在任何情况下，我们都可以做的是添加更好的度量/监控，这样我们就可以在正常构建开始变得危险地接近极限之前发现问题。
CL 406216 将全局构建超时从45分钟增加到2小时，以适应长测试构建器，这是一个跟踪问题，以确定我们在这个领域长期想要做什么。(如果将来某些构建需要更长的时间，也许只需将其从2小时提高即可。)
CC @golang/release.
2条答案
按热度按时间ki0zmccv1#
https://go.dev/cl/406216提到了这个问题：
cmd/coordinator: consolidate and increase global VM deletion timeoutn3schb8v2#
顺便说一下，我目前使用的构建器排期流程有一个自然的限制，即构建器时间。这个限制是指一个CL被提交和进行排期处理之间的时间间隔。
我一直使用当天的时间边界作为排期截止点，我认为
fetchlogs使用的是UTC时间戳。我所在的时区是UTC-4,我至少要等到当地时间上午9点才开始排期处理，所以在提交了刚刚过午夜的CL之后，测试会在大约13个小时(减去调度延迟)内开始超出排期窗口。