Agones项目中Fleet Autoscaler与零副本Fleet的兼容性问题分析

问题背景

在Agones游戏服务器编排系统中，Fleet Autoscaler是一个关键组件，它负责根据定义的策略自动调整Fleet的规模。近期发现当使用"List"策略的Fleet Autoscaler与未定义replicas的Fleet配合使用时，系统会抛出错误："cannot apply ListPolicy as List key MyCustomList does not exist in the Fleet Status"。

技术细节

当前实现机制

Agones的当前实现基于以下假设：

1. Fleet不能缩放到零副本
2. 因此也不能从零副本开始扩展

这种假设导致了List和Counter的状态聚合机制存在局限性。目前的状态聚合流程是：

• 从Game Server状态开始
• 聚合到Game Server Set
• 最后聚合到Fleet状态

当没有Game Server实例时，这个聚合链就会中断，导致无法生成必要的状态信息。

问题影响

这个问题特别影响使用GitOps工具（如Flux CD）的场景，因为这些工具通常期望系统能够从零状态开始部署和扩展。

解决方案探讨

核心团队提出了在GameServerSet控制器中添加逻辑来初始化空列表和计数器的方案。具体实现思路是：

当检测到Game Server列表为空且启用了CountsAndLists特性时：

1. 初始化空的Lists和Counters映射
2. 从Fleet规范中获取所有定义的List和Counter键
3. 为每个键创建初始状态条目，设置Count和Capacity为0

示例实现代码：

if runtime.FeatureEnabled(runtime.FeatureCountsAndLists) && len(list) == 0 {
    status.Lists = make(map[string]agonesv1.AggregatedListStatus)
    for key := range gsSpec.Lists {
        status.Lists[key] = agonesv1.AggregatedListStatus{}
    }
    status.Counters = make(map[string]agonesv1.AggregatedCounterStatus)
    for key := range gsSpec.Counters {
        status.Counters[key] = agonesv1.AggregatedCounterStatus{}
    }
}

实现考虑因素

1. GameServerSet控制器修改：需要在computeStatus函数中处理零Game Server的情况
2. Fleet Autoscaler兼容性：需要验证修改后的状态结构是否能被现有的Autoscaler正确处理
3. 性能影响：额外的状态初始化操作对系统性能的影响可以忽略不计
4. 向后兼容：修改不会影响现有正常运行的Fleet

测试建议

为确保修改的可靠性，建议进行以下测试场景：

1. 从零副本开始的Fleet扩展
2. 混合使用List和Counter策略的场景
3. 多List/Counter键的情况
4. 与GitOps工具的集成测试

总结

这一改进将使Agones更好地支持现代GitOps工作流，同时保持系统的稳定性和可靠性。通过合理初始化零副本状态，系统可以更灵活地适应各种部署场景，特别是从零开始的自动化部署流程。