Ingress路由规则设置：对外暴露多个模型服务端点-洪萨配资

Ingress路由规则设置：对外暴露多个模型服务端点

在AI基础设施日益复杂的今天，一个典型的挑战是：如何在一个Kubernetes集群中同时运行上百个大模型服务，并让外部用户通过清晰、安全、可维护的方式访问它们？尤其是在魔搭（ModelScope）社区推动下，ms-swift框架已支持超过600个纯文本大模型和300个多模态模型的一站式部署，这种需求变得尤为迫切。

传统的做法——为每个模型分配独立的NodePort或LoadBalancer——早已不可持续。前者受限于防火墙策略与端口数量，后者则带来高昂的成本和运维负担。更糟糕的是，当团队需要频繁上线新模型时，网络配置往往成为瓶颈。

真正的解法，藏在Kubernetes原生的Ingress机制中。它不仅是七层负载均衡器，更是构建统一AI服务入口的核心组件。通过合理的路径路由规则，我们可以实现“单域名、多模型”的优雅架构：所有模型共享同一个公网IP和HTTPS证书，仅靠URL路径区分服务，如/llama3、/qwen-vl、/bge-embedding。

这不仅简化了客户端调用逻辑，也为后续的灰度发布、安全控制、监控追踪打下了坚实基础。

Ingress的本质，是一个声明式的HTTP(S)路由表。它本身不处理流量，而是由Ingress Controller（如Nginx、Traefik、Istio Gateway）监听其资源变化，动态生成反向代理配置。当用户请求到达时，Controller会根据Host和Path匹配规则，将请求精确转发到对应的后端Service。

以AI推理场景为例，每个模型通常以Deployment形式运行，绑定一个ClusterIP Service。而Ingress的作用，就是把外部世界的https://ai-platform.com/qwen-vl/infer这样的请求，“翻译”成内部可达的qwen-vl-inference-service:8080/infer。

这个过程看似简单，实则涉及几个关键设计点：

首先是路径匹配的准确性。我们希望/qwen-vl能同时匹配根路径和子路径（如/qwen-vl/v1/chat/completions），但又要避免前缀冲突（比如/qwen误命中/qwen-vl）。标准的Prefix类型路径匹配在某些情况下不够灵活，因此常需启用正则表达式支持。

其次是路径重写问题。大多数模型服务并不期望收到带前缀的路径。例如，qwen-vl服务内部只识别/v1/chat/completions，而不理解/qwen-vl/v1/chat/completions。这就要求Ingress在转发前剥离路径前缀——而这正是rewrite-target注解的价值所在。

再者是安全性与性能的平衡。TLS终止应在Ingress层完成，既减轻后端压力，又能集中管理证书轮换；但对于长耗时的大模型推理请求，还需调整代理超时时间（如proxy-read-timeout设为300s以上），防止连接被意外中断。

对比不同服务暴露方式，Ingress的优势一目了然：

方案	成本	可维护性	安全性	扩展性
NodePort	低	差（端口易冲突）	弱（直接暴露）	差
LoadBalancer	高	中	中	中
Ingress	极低	优	强	优

特别是在ms-swift这类批量部署场景下，Ingress真正体现了“一次接入，无限扩展”的能力。

来看一个实际配置示例。假设我们要将两个模型服务通过同一域名对外暴露：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: model-serving-ingress namespace: ai-models annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 nginx.ingress.kubernetes.io/use-regex: "true" spec: ingressClassName: nginx rules: - host: ai-platform.com http: paths: - path: /llama3(/|$)(.*) pathType: ImplementationSpecific backend: service: name: llama3-inference-service port: number: 8080 - path: /qwen-vl(/|$)(.*) pathType: ImplementationSpecific backend: service: name: qwen-vl-inference-service port: number: 8080 tls: - hosts: - ai-platform.com secretName: ai-platform-tls-secret

这里有几个细节值得深挖：

path: /llama3(/|$)(.*)使用正则捕获组，确保既能匹配/llama3也能匹配其子路径；
$2对应第二个括号的内容，即路径后缀，rewrite-target: /$2实现了自动去前缀；
ImplementationSpecific类型允许Ingress Controller解释路径含义，配合正则使用更灵活；
TLS配置通过Secret引用证书，实现HTTPS加密通信，且无需修改后端服务。

这套配置可以轻松横向扩展至数十甚至上百个模型，只需追加paths条目即可，完全适配ms-swift框架下的自动化部署流程。

说到ms-swift，它的价值远不止于模型推理命令封装。作为一个全链路训练部署框架，它真正解决了从环境初始化到服务注册的“最后一公里”问题。开发者只需执行一段脚本（如/root/yichuidingyin.sh），系统便可自动完成模型下载、依赖安装、服务启动等操作，默认监听8080端口并提供OpenAI兼容接口。

这意味着，每一个由ms-swift启动的服务，天生就具备被Ingress接入的能力。你不需要关心容器镜像构建、健康检查路径或API版本兼容性——这些都已标准化。

典型的工作流是这样的：

创建GPU实例，执行初始化脚本；
选择“启动推理”，输入模型名称（如qwen-vl-chat）；
系统自动拉取权重并启动服务：swift infer --model_type=qwen_vl_chat --port=8080；
在Kubernetes中创建对应Service；
更新Ingress规则，添加新路径映射；
外部即可通过https://ai-platform.com/qwen-vl/...访问。

整个过程无需重启任何现有服务，Ingress Controller会热加载新规则，实现无缝更新。

系统的整体架构也由此变得清晰：

[Client] ↓ HTTPS (host: ai-platform.com, path: /llama3/infer) [Cloud DNS] ↓ [Load Balancer] ↓ [Ingress Controller (Nginx/Traefik)] ↓ 根据 path 路由 ├──→ [Service: llama3-inference-svc:8080] │ └──→ [Pod: Deployment=llama3-infer, Container=ms-swift] ├──→ [Service: qwen-vl-inference-svc:8080] │ └──→ [Pod: Deployment=qwen-vl-infer, Container=ms-swift] └──→ [Service: embedding-bge-svc:8080] └──→ [Pod: Deployment=bge-infer, Container=ms-swift]

所有服务共用一个入口，却彼此隔离。这种“单入口、多出口”的模式，极大提升了资源利用率和系统可观测性。

实践中常见的痛点也在这一架构下迎刃而解：