Kubeflow KFServing 在离线环境中部署 InferenceService 的解决方案

问题背景

在 Kubernetes 环境中使用 Kubeflow KFServing 部署机器学习推理服务时，用户遇到了一个典型问题：当集群处于离线环境（无互联网连接）时，即使已经预先加载了所需的容器镜像，InferenceService 仍然无法正常启动。系统会错误地尝试从外部镜像仓库拉取镜像，导致服务部署失败。

问题分析

经过深入排查，发现这个问题与 Knative 的工作机制密切相关。KFServing 底层使用了 Knative Serving 来实现无服务器（Serverless）模式，而 Knative 有一个默认行为：它会尝试将镜像标签（tag）解析为具体的镜像摘要（digest）。这个解析过程需要访问外部的容器镜像仓库服务。

具体表现为：

1. 用户已经通过 ctr images import 将镜像导入到 containerd 中
2. 在 Deployment 中可以直接使用这些本地镜像
3. 但在 InferenceService 中，Knative 仍然会尝试连接外部仓库进行标签解析
4. 在离线环境中，这种外部连接会失败，导致服务无法启动

解决方案

方法一：使用镜像摘要而非标签

最直接的解决方案是使用镜像的完整摘要（digest）而非标签来指定镜像。这样可以避免 Knative 进行标签解析的步骤。例如：

image: "yurkoff/torchserve-kfs@sha256:1b771d7c0c2d26f78e892997cb00e6051c77cf3654827c4715aa5a502267ee76"

方法二：配置 Knative 跳过特定仓库的标签解析

对于需要继续使用标签的场景，可以修改 Knative 的配置，使其跳过对特定镜像仓库的标签解析：

1. 编辑 Knative Serving 的 ConfigMap：

kubectl edit configmap config-deployment -n knative-serving

2. 添加或修改 registries-skipping-tag-resolving 配置项，包含需要跳过的仓库域名：

data:
  registries-skipping-tag-resolving: "kind.local,ko.local,dev.local,index.docker.io"

这个配置告诉 Knative 不要尝试解析这些仓库的镜像标签，直接使用本地已有的镜像。

技术原理

Knative 的标签解析机制设计初衷是为了确保部署的确定性和可重复性。通过将易变的标签解析为不可变的摘要，可以保证每次部署使用的都是完全相同的镜像版本。然而，在离线环境中，这种机制反而成为了障碍。

修改 registries-skipping-tag-resolving 配置后，Knative 会：

1. 对于匹配的镜像仓库，直接使用指定的标签
2. 不尝试连接外部仓库获取摘要信息
3. 依赖 Kubernetes 本身的镜像拉取策略（如 imagePullPolicy）来处理镜像获取

最佳实践建议

1. 在生产环境中，推荐使用镜像摘要来确保部署的一致性
2. 在开发和测试环境中，可以使用标签跳过配置来提高灵活性
3. 对于完全离线的环境，建议建立内部镜像仓库并配置适当的镜像缓存策略
4. 定期验证镜像的完整性和安全性，特别是在跳过标签解析的情况下

总结

KFServing 在离线环境中的部署问题揭示了 Knative 底层机制与特定使用场景之间的不匹配。通过理解其工作原理并合理配置，我们可以灵活地适应各种部署环境的需求。无论是使用镜像摘要还是调整 Knative 配置，都能有效解决离线环境中的部署问题，为机器学习模型的部署提供更大的灵活性。