Kubeflow KFServing实现推理服务启停控制的设计思考

背景与需求分析

在私有云环境中，GPU资源往往是非常珍贵的计算资源。当用户通过Kubeflow KFServing部署推理服务(InferenceService)后，可能会面临以下场景需求：

1. 在非使用时段希望释放GPU资源供其他任务使用
2. 需要完全停止服务以避免意外访问
3. 后续使用时能快速恢复而不需要重新创建实例

这种精细化的资源管控需求对KFServing提出了新的功能要求——支持对推理服务进行启停控制。

技术方案设计

核心设计理念

采用声明式的控制方式，通过为InferenceService添加特定注解(annotation)来触发启停操作。这种设计保持了Kubernetes原生API的使用习惯，同时具备以下优势：

• 无需修改现有API结构
• 与Kubernetes的声明式管理哲学一致
• 便于通过kubectl等标准工具操作

具体实现方案

控制机制

引入serving.kserve.io/stop注解作为控制开关：

• 当设置为true时：停止服务并释放资源
• 当设置为false或移除时：重新启动服务

不同部署模式的处理

根据不同的部署模式采取差异化处理策略：

1. Serverless模式（基于Knative）

   • 停止时：删除KSVC(Knative Service)及其相关资源
   • 启动时：重建KSVC资源
   • 技术挑战：需要解决Knative中Pod优雅终止时间过长的问题

2. Raw Deployment模式

   • 停止时：删除HPA(Horizontal Pod Autoscaler)及相关资源
   • 启动时：重建HPA资源

3. ModelMesh模式

   • 待补充具体实现细节

状态管理

引入新的状态类型来明确表示服务启停状态：

status:
  conditions:
    - type: Stopped
      status: 'True/False'
      reason: Stopped
  modelStatus:
    transitionStatus: 'Stopped'

同时更新其他标准状态字段（如Ready、RoutesReady等）以反映停止状态。

配套资源处理

为确保完全停止服务，需要同时处理：

1. 删除底层Pod资源
2. 移除对应的Istio VirtualService
3. 清理其他相关资源（如ConfigMap、Service等）

技术价值与展望

核心价值

1. 资源利用率提升：实现GPU资源的动态分配与回收
2. 成本优化：减少闲置资源带来的云资源浪费
3. 运维便利性：提供标准化的服务启停接口

未来演进方向

1. 与Knative深度集成，优化Serverless模式的启停性能
2. 支持按计划自动启停（结合CronJob等机制）
3. 完善状态恢复机制，确保服务重启后的稳定性
4. 增加资源预留功能，避免频繁启停带来的冷启动延迟

实施建议

对于希望提前体验该功能的用户，可以考虑以下临时方案：

1. 对于Serverless模式：通过设置minReplicas/maxReplicas为0实现近似停止效果
2. 对于Raw模式：手动删除Deployment资源（需注意状态一致性）

该功能的完整实现将为KFServing用户提供更精细化的资源管控能力，特别是在资源受限的私有云环境中具有重要价值。