KServe项目中使用Raw Deployment模式部署模型服务的实践指南

背景介绍

KServe作为Kubernetes原生的模型服务框架，支持多种部署模式。其中Raw Deployment模式是一种非Serverless的部署方式，与Knative Serving模式相比，它直接使用Kubernetes原生Deployment资源，更适合需要长期运行的稳定工作负载。

问题现象

在本地环境部署KServe后，当尝试使用Raw Deployment模式创建InferenceService时，发现通过curl命令进行模型推理请求时返回404错误。这与使用Knative Serving作为后端时的成功表现形成对比。

根本原因分析

经过深入排查，发现Raw Deployment模式与Knative Serving模式在网络层的实现机制存在重要差异：

1. 网络层依赖不同：Raw Deployment模式不自动创建Istio相关资源，而是依赖于Kubernetes Ingress资源进行流量路由
2. 缺少IngressClass配置：默认情况下，集群中缺少适当的IngressClass定义，导致Ingress控制器无法正确处理流量

解决方案

要解决这个问题，需要明确Raw Deployment模式下的网络配置要求：

1. 创建IngressClass资源：必须定义一个匹配集群中实际Ingress控制器的IngressClass

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: istio
spec:
  controller: istio.io/ingress-controller

2. 理解配置选项：

• disableIstioVirtualHost: 禁用Istio特有的虚拟主机配置
• disableIngressCreation: 控制是否自动创建Ingress资源
• ingressDomain: 设置Ingress的基础域名
• ingressGateway/ingressService: 控制Istio网关和服务的配置

最佳实践建议

1. 环境准备：在使用Raw Deployment前，确保集群中已安装并配置好Ingress控制器
2. 网络方案选择：根据实际需求选择适合的网络层方案（Istio、Nginx Ingress等）
3. 未来演进：关注KServe正在向Gateway API的迁移，这将提供更强大的网络功能

总结

Raw Deployment模式为KServe用户提供了更灵活的部署选择，但需要开发者对Kubernetes网络层有更深入的理解。通过正确配置IngressClass和相关参数，可以成功实现模型服务的部署和访问。随着Gateway API的引入，KServe的网络能力将得到进一步增强，为用户提供更丰富的部署选项。

对于刚接触KServe的开发者，建议从Knative Serving模式开始，熟悉基本概念后再尝试Raw Deployment等高级模式，以循序渐进地掌握KServe的各项功能。