KServe在RawDeployment模式下使用Kong Ingress Gateway的配置问题解析

背景介绍

KServe作为Kubernetes上的机器学习服务框架，提供了多种部署模式。其中RawDeployment模式允许用户直接使用原生Kubernetes资源进行模型部署。当结合Kong Ingress Gateway使用时，用户期望能够自动创建网关实例Pod和LoadBalancer服务，但在实际配置过程中可能会遇到一些问题。

问题现象

在KServe v0.14.1版本中，用户尝试通过Helm配置使用Kong作为Ingress Gateway时发现：

1. 按照文档配置后，系统未自动创建预期的网关实例Pod和LoadBalancer服务
2. 手动创建Gateway资源时遇到"unknown field 'spec.infrastructure'"错误
3. 删除infrastructure节点后Gateway创建成功，但仍未生成预期的网关资源

根本原因分析

经过深入分析，发现以下关键点：

1. 版本兼容性问题：Gateway API支持功能是在KServe v0.15.0rc0版本才引入的，v0.14.1版本并不完全支持相关配置
2. 资源配置差异：Kong Gateway API的实现与标准Gateway API规范存在差异，特别是对infrastructure字段的处理
3. 控制器行为：在RawDeployment模式下，KServe不会自动管理网关基础设施的完整生命周期

解决方案

针对这一问题，建议采取以下解决步骤：

1. 升级KServe版本： 确保使用v0.15.0或更高版本，以获得完整的Gateway API支持

2. 正确配置GatewayClass：

   apiVersion: gateway.networking.k8s.io/v1
   kind: GatewayClass
   metadata:
     name: kong
   spec:
     controllerName: konghq.com/kic-gateway-controller
   

3. 简化Gateway资源配置：

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: kserve-ingress-gateway
     namespace: kserve
   spec:
     gatewayClassName: kong
     listeners:
     - name: proxy
       port: 80
       protocol: HTTP
       allowedRoutes:
         namespaces:
           from: All
   

4. 独立管理网关基础设施： 在RawDeployment模式下，建议单独部署和管理Kong Ingress Controller，而不是依赖KServe自动创建

最佳实践建议

1. 生产环境建议使用Serverless模式而非RawDeployment，以获得更完整的KServe功能支持
2. 对于Kong Ingress Gateway，考虑使用Kong官方提供的Helm chart进行独立部署
3. 在Gateway资源配置中，避免使用非标准字段，确保与Kong控制器的兼容性
4. 监控网关资源状态，确保Gateway被正确关联和配置

总结

KServe与Kong Ingress Gateway的集成需要特别注意版本兼容性和资源配置规范。通过正确理解各组件的工作原理和版本特性，可以构建稳定可靠的机器学习服务网关架构。对于关键生产环境，建议进行充分的测试验证后再进行部署。