AIbrix项目中模型适配器控制器端点清理问题分析

问题背景

在AIbrix项目（一个开源的大模型推理平台）中，模型适配器控制器（Model Adapter Controller）负责管理模型服务的端点信息。最近发现了一个关键问题：当进行滚动升级时，旧的Pod端点信息没有被正确清理，导致EndpointSlice中保留了已经不存在的Pod IP地址。

问题现象

在Kubernetes环境中进行模型服务的滚动升级时，虽然旧的Pod已经被终止，但其IP地址仍然保留在EndpointSlice资源中。这会导致：

1. 服务发现机制可能会将流量路由到已经不存在的Pod
2. 调度器可能选择旧的Pod而不是新创建的Pod
3. 系统需要额外的迁移轮次来纠正这种不一致状态

技术分析

当前实现的问题

当前控制器在处理端点更新时采用了简单的追加(append)方式，这导致了以下问题：

1. 缺乏清理机制：当Pod被替换时，旧IP没有被从EndpointSlice中移除
2. 状态不一致：EndpointSlice中同时存在新旧Pod的IP地址
3. 调度效率低下：调度器可能优先选择旧Pod，导致不必要的迁移

根本原因

问题的核心在于控制器没有实现完整的端点状态同步逻辑。在Kubernetes中，EndpointSlice应该精确反映当前可用的服务端点，而不仅仅是累积所有曾经存在过的端点。

解决方案

直接修复方案

最直接的修复方法是改变端点更新策略，从"追加模式"改为"全量更新模式"。具体实现要点：

1. 每次更新时重新构建完整的端点列表
2. 只包含当前健康且可用的Pod IP
3. 移除所有不再存在的端点

长期架构考虑

考虑到未来可能支持多副本部署，建议进行以下架构改进：

1. 实现更健壮的端点状态管理
2. 引入端点健康检查机制
3. 优化调度器选择逻辑，优先选择新创建的Pod

实现建议

在代码层面，应该重构端点更新逻辑，确保：

1. 基于当前Pod状态动态构建端点列表
2. 实现精确的端点添加和移除操作
3. 考虑引入版本控制或生成标识来帮助调度器做出正确选择

总结

这个问题虽然表面上是端点清理不彻底的技术问题，但反映了在动态编排环境中状态同步的重要性。通过这次修复，不仅解决了当前的问题，也为未来支持多副本和更复杂的部署场景打下了基础。对于类似系统，建议在设计之初就考虑好状态同步和清理机制，避免这类问题的发生。