KServe 项目中使用 InferenceService 时存储初始化失败的排查与解决

问题现象

在使用 KServe 项目部署第一个 InferenceService 时，发现 Pod 启动失败。查看 Pod 日志显示无法在 /mnt/models 目录下找到模型文件，错误信息表明该目录不存在。

环境配置

用户使用的是 Minikube 集群，Kubernetes 版本为 1.28.3，KServe 版本为 0.11.0。InferenceService 的 YAML 配置引用了 Google Cloud Storage 中的示例模型。

错误分析

从日志中可以清晰地看到两个关键错误：

1. 尝试从 /mnt/models 加载模型失败
2. 最终报错显示 /mnt/models 目录不存在

深入分析发现，问题的根源在于存储初始化容器（storage-initializer）没有被注入到 Pod 中。这个容器负责从指定的存储 URI 下载模型文件到 /mnt/models 目录。

排查过程

1. 检查 Pod 容器：发现只有 queue-proxy 和 kserve-container 两个容器运行，缺少关键的 storage-initializer 初始化容器。

2. 命名空间影响：发现当 InferenceService 部署在 kserve 命名空间时会出现此问题，而部署在其他命名空间则工作正常。

3. 控制平面标签：进一步调查发现，KServe 的变异 webhook 会跳过带有 'control-plane' 标签的命名空间，而 kserve 命名空间通常会被标记为控制平面。

解决方案

1. 使用专用命名空间：避免在 kserve 命名空间中部署 InferenceService，而是创建并使用专门的命名空间。

2. 检查命名空间标签：确保目标命名空间没有被标记为控制平面（control-plane）。

3. 验证存储初始化：部署后检查 Pod 描述，确认 storage-initializer 容器被正确注入并成功执行。

最佳实践建议

1. 命名空间规划：为模型服务创建专门的命名空间，与 KServe 系统组件隔离。

2. 部署验证：部署后立即检查 Pod 的初始化容器状态和日志。

3. 环境准备：在部署前确保集群网络能够访问模型存储位置（如 GCS、S3等）。

4. 权限配置：确保 ServiceAccount 有足够的权限从存储位置下载模型文件。

总结

这个问题揭示了 KServe 部署中的一个重要注意事项：控制平面命名空间与服务命名空间的隔离。通过将模型服务部署在专用命名空间，可以确保存储初始化等关键功能正常工作。KServe 社区已经更新文档，明确说明了这一限制，帮助用户避免类似问题。