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

问题背景

在Kubernetes离线环境中部署KServe的InferenceService时，用户遇到了一个常见但棘手的问题：即使已经将所需镜像导入到本地容器运行时中，InferenceService仍然尝试从外部镜像仓库拉取镜像，导致部署失败。这种情况特别容易出现在使用Knative作为服务网格的环境中。

问题分析

通过深入分析，我们发现这个问题的根源在于Knative的一个核心机制——镜像标签解析。Knative默认会尝试将镜像标签解析为具体的镜像摘要(digest)，这个过程需要访问外部镜像仓库。即使在以下情况下，这个机制仍然会触发：

1. 镜像已经存在于本地容器运行时中
2. 显式设置了imagePullPolicy: Never或IfNotPresent
3. 使用了本地镜像仓库

解决方案

方法一：使用镜像摘要替代标签

最直接的解决方案是使用镜像的完整摘要而非标签来引用镜像。这样可以避免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字段，包含需要跳过的仓库地址：

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

技术原理详解

Knative的标签解析机制设计初衷是为了确保部署的确定性和可重复性。通过将标签解析为不可变的摘要，可以避免因标签内容变化导致的部署不一致问题。然而，在离线环境中，这一机制反而成为了障碍。

当Knative接收到一个包含镜像标签的部署请求时，它会：

1. 尝试联系镜像仓库获取该标签对应的摘要
2. 如果成功，使用摘要创建部署
3. 如果失败，整个部署过程会中止

通过上述两种解决方案，我们实际上是在不同层面上绕过了这个机制：要么直接提供摘要，要么告诉Knative不要对特定仓库执行解析。

最佳实践建议

1. 在生产环境中，推荐使用镜像摘要的方式，这能提供最强的部署确定性
2. 在开发和测试环境中，可以使用跳过标签解析的方式提高灵活性
3. 对于完全离线的环境，建议建立完整的内部镜像仓库体系，并配置适当的镜像缓存策略
4. 考虑使用imagePullPolicy: Never作为额外的保障措施

总结

在KServe的离线部署场景中，理解Knative的底层机制对于解决镜像拉取问题至关重要。通过本文介绍的两种方法，用户可以灵活地根据实际环境需求选择合适的解决方案，确保InferenceService能够顺利部署和运行。