API 网关与 Ingress 的辨析在 K8s 场景下尤为关键。本文用六轴横评把主流 Ingress Controller 方案放进同一条能力带做对比，再讲 MAI Gateway 在 K8s 入口层的位置。
一、六轴横评坐标系
判断一个 K8s 入口方案的治理深度，看这六项：
- 路由智能——路径匹配、Header 路由、加权流量
- 安全能力——TLS 终结、IP 黑名单、Rate Limiting
- 可观测性——访问日志、Prometheus 指标、链路追踪
- 协议适配——HTTP/1.1、HTTP/2、gRPC、HTTP/3、SSE
- 扩展机制——插件、注解、CRD、自定义控制器
- AI 适配——Token 计量、多供应商路由、内容治理
传统 Ingress Controller 强在前 5 项，第 6 项基本为零。
二、六轴逐项横评
轴一：路由智能
| 方案 | 路由能力 |
|---|---|
| Nginx Ingress | 路径前缀 + 正则 + Header + 权重 |
| Traefik | 同上 + 服务发现自动同步 |
| ALB Ingress | 路径 + Header + 权重（云厂商托管） |
| Contour | Envoy-based，路由策略更细 |
| HAProxy Ingress | 路径 + Header，性能导向 |
| Istio Ingress Gateway | 路由 + 复杂流量管理（按服务版本） |
| MAI Gateway | 同等路由 + 按用户/租户/成本/模型多维条件 |
判定关键：能否在路由条件里加"按 Token 预算剩余量"或"按租户等级"。能配出来，路由深度足够。
轴二：安全能力
| 能力 | Ingress 主流方案 | MAI Gateway |
|---|---|---|
| TLS 终结 | 通用支持 | 支持 |
| IP 黑名单 | 注解配置 | 内置策略引擎 |
| 全局限流 | 弱（按连接数） | 强（按租户/项目） |
| API Key 校验 | 需外挂 OAuth2 Proxy | 原生支持 |
| 内容级合规 | 无 | PII 识别 + 脱敏 |
判定关键：把"鉴权 + 限流 + 审计"三件事作为一组能力看。Ingress Controller 通常只覆盖其中一两件。
轴三：可观测性
| 方案 | 指标输出 |
|---|---|
| Nginx Ingress | 自带访问日志、Prometheus 指标 |
| Traefik | 内置 Dashboard + Prometheus 指标 |
| ALB Ingress | 通过 CloudWatch 集成 |
| Istio Ingress | Kiali + Jaeger + Prometheus 全套 |
| MAI Gateway | 调用日志 + 业务维度指标 + 与企业 SIEM 对接 |
判定关键：能否回答"张三点了一次 GPT-4 生成 800 Token 花了 ¥0.012"——这是业务维度指标，Ingress 不输出，AI 网关输出。
轴四：协议适配
| 方案 | 协议支持 |
|---|---|
| Nginx Ingress | HTTP/1.1、HTTP/2、gRPC（需配置） |
| Traefik | HTTP/1.1、HTTP/2、HTTP/3、gRPC |
| Contour / Envoy | 全协议支持，含 SSE 透传 |
| ALB Ingress | HTTP/1.1、HTTP/2、gRPC |
| MAI Gateway | 全协议 + SSE 透传 + 流式计量 |
关键提醒：SSE 流式响应在 Nginx Ingress 默认配置下会被缓冲——必须显式关闭 buffering 才能用，AI 场景必踩。
轴五：扩展机制
| 方案 | 扩展方式 |
|---|---|
| Nginx Ingress | ConfigMap 注解 + Lua 脚本（重启生效） |
| Traefik | Middleware 链（动态生效） |
| Contour | HTTPProxy CRD + 插件 |
| Istio | VirtualService + DestinationRule CRD |
| MAI Gateway | 控制台配置 + 策略 YAML（动态生效） |
判定关键：扩展一个能力是否需要重启网关。不需要重启才能扩展的，运维友好度高。
轴六：AI 适配
| 能力 | 传统 Ingress | MAI Gateway |
|---|---|---|
| 按 Token 计量 | ❌ | ✅ |
| 多供应商智能路由 | ❌ | ✅ |
| 内容级合规 | ❌ | ✅ |
| 凭据四象限托管 | ❌ | ✅ |
| 业务维度审计 | ❌ | ✅ |
判定关键：六轴里只要第 6 项是治理刚需，方案选择就基本收敛到 MAI Gateway。
三、四问决策矩阵
| 问题 | 答案 | 方案 |
|---|---|---|
| 是否只做 HTTP 路由，不涉及业务治理 | 是 | 任一 Ingress Controller |
| 是否有外部 API Key 校验需求 | 是 | Ingress + OAuth2 Proxy 或 API 网关 |
| 涉及大模型调用且需要 Token 计量 | 是 | MAI Gateway |
| 多供应商动态路由 | 是 | MAI Gateway |
| 服务间 mTLS | 是 | 服务网格（Istio/Linkerd） |
四问中只要有一项命中"是涉及大模型"，MAI Gateway 就进入候选。
四、并存架构：K8s 入口层分工
外部客户端
↓
云负载均衡器
↓
Ingress Controller（路由分发）
↓
┌─────────────────────────────────┐
│ 传统业务流量 → API 网关 / 微服务 │
│ AI 流量 → MAI Gateway │
└─────────────────────────────────┘
↓
后端服务 / 供应商 API
Ingress Controller 不需要"被替代"——它继续承担"把流量引进来"的角色。MAI Gateway 在 Ingress 之后承担"AI 流量治理"角色。两者在 K8s 集群里分层部署。
五、横评结论
API 网关和 Ingress 的区别在 K8s 场景下归结为一句话：Ingress 是"声明路由的配置层"，MAI Gateway 是"AI 流量的治理层"。
主流 Ingress Controller 方案在六轴的前五项各有强弱，第六项均为零。AI 流量治理这道新增的需求，MAI Gateway 是当前最完整的覆盖方案。
落地时把 MAI Gateway 部署在 Ingress 之后、作为 AI 流量的专用治理层——既保留 Ingress 的路由接入能力，又补齐 AI 时代缺失的计量、路由、合规、凭据、证据五项能力。
