4. Gateway API 与 Ingress 对比：功能差异、表达能力、安全性、多团队协作、生态支持对比分析

Kubernetes 社区在 1.19 版本将 Ingress 资源标记为稳定（GA），但其设计局限在云原生网关快速演进的背景下日益凸显。Gateway API 作为下一代入口流量管理标准，在功能、表达能力、安全模型、多团队协作和生态支持五个维度上对 Ingress 进行了系统性升级。本章通过结构化对比，帮助架构师理解升级窗口的核心判断依据。

4.1 功能差异对比

Ingress 仅提供基础的 HTTP(S) 路由和 TLS 终止能力，而 Gateway API 将网关生命周期管理、流量拆分、跨命名空间路由等能力纳入标准 API。下表从 12 个关键功能维度进行对比：

功能维度 Ingress (v1) Gateway API (v1)
协议支持 HTTP/HTTPS 为主，gRPC/TCP 依赖注解 HTTP、HTTPS、gRPC、TCP、UDP、TLS 原生支持
流量拆分 不支持，需借助第三方 CRD HTTPRoute 原生支持权重、Header、QueryParam 匹配
跨命名空间路由 不支持，路由规则与后端服务必须在同一命名空间 支持跨命名空间引用，通过 ReferenceGrant 授权
网关生命周期 无标准 API，依赖控制器注解 GatewayClass → Gateway → Route 三层模型，声明式管理
后端类型 仅 Service Service、Pod、Fargate、外部服务（通过 BackendRef）
请求镜像 不支持 HTTPRoute 原生支持流量镜像
重定向/重写 部分实现依赖注解 HTTPRouteFilter 原生支持路径重写、Host 重写、重定向
会话保持 不支持 通过 BackendLBPolicy 等策略 API 支持
健康检查 依赖后端 Service 实现 Gateway API 策略可定义主动/被动健康检查
速率限制 不支持 通过 RateLimitPolicy 策略 API 支持
认证鉴权 依赖注解或 Sidecar SecurityPolicy 原生支持 OIDC、JWT、OAuth2
可观测性 无标准指标 标准 Status 条件、Metrics 暴露、AccessLog 策略
架构决策提示： 如果团队仅需要简单的 HTTP 路由和 TLS 终止，Ingress 仍然可用。但一旦涉及流量拆分、跨命名空间路由或协议扩展，Gateway API 的标准化能力可以显著降低维护成本。

4.2 表达能力对比

Gateway API 在表达能力上的核心提升体现在路由匹配规则、过滤器链和策略扩展三个方面。下图展示了两种 API 在路由规则定义上的表达能力差异：

Gateway API vs Ingress 表达能力对比 Ingress 表达能力 host: example.com path: /api/* service: svc-api:8080 tls: secret-tls 匹配规则：仅 host + path 前缀 过滤器：无标准定义 Gateway API 表达能力 hostnames: ["example.com", "*.example.com"] path: /api/* (Prefix/Exact/Regex) method: GET, POST (Method Match) header: X-Version: v2 (Header Match) query: ?env=staging (Query Match) filter: URLRewrite + Redirect + Mirror 匹配规则：多维组合 + 精确/正则/前缀 过滤器：标准链式定义

Gateway API 的匹配规则支持多维组合（Host + Path + Method + Header + Query），而 Ingress 仅支持 Host + Path 的简单匹配。在过滤器方面，Gateway API 定义了标准化的 HTTPRouteFilter 链，支持请求/响应修改、重定向、镜像等操作，而 Ingress 需要依赖实现特定的注解。

表达能力升级关键点：
  • 匹配维度： Ingress 2 维 → Gateway API 5 维（Host/Path/Method/Header/Query）
  • 匹配精度： Ingress 仅前缀匹配 → Gateway API 支持 Exact、Prefix、Regex
  • 过滤器链： Ingress 无标准 → Gateway API 支持链式组合（重写+重定向+镜像+自定义）
  • 后端引用： Ingress 仅 Service → Gateway API 支持 Service/Pod/外部服务/多权重后端

4.3 安全性对比

安全性是 Gateway API 相对于 Ingress 最显著的改进领域。Ingress 的安全配置分散在注解、TLS Secret 和外部工具中，而 Gateway API 通过策略 API 和细粒度授权模型实现了安全能力的标准化。

4.3.1 安全模型对比

安全维度 Ingress 实现方式 Gateway API 实现方式
TLS 管理 Secret 引用，不支持 SNI 多证书 Gateway 监听器支持 SNI、TLS 版本、密码套件配置
认证鉴权 依赖注解（如 nginx.ingress.kubernetes.io/auth-url） SecurityPolicy 原生支持 OIDC、JWT、OAuth2、BasicAuth
跨命名空间安全 无控制，默认允许或拒绝 ReferenceGrant 显式授权，最小权限原则
速率限制 依赖注解，实现不统一 RateLimitPolicy 标准化配置，支持全局/路由级限制
IP 白名单 依赖注解 SecurityPolicy 原生支持 CIDR 白名单/黑名单
CORS 依赖注解 HTTPRouteFilter 原生支持 CORS 配置
安全审计 无标准 AccessLogPolicy 标准化日志格式和采样率

4.3.2 安全策略分层模型

Gateway API 的安全策略采用分层附加模型，允许不同角色在各自范围内定义安全规则：

Gateway API 安全策略分层模型 集群级安全策略 (ClusterSecurityPolicy) 全局 TLS 最低版本、全局 IP 黑名单、全局速率限制基线 网关级安全策略 (GatewaySecurityPolicy) 监听器 TLS 配置、网关级认证、网关级 CORS 路由级安全策略 (RouteSecurityPolicy) 路由级 JWT 验证、路由级速率限制、路由级 IP 白名单 策略继承：路由级覆盖网关级，网关级覆盖集群级
安全迁移注意事项： 从 Ingress 迁移到 Gateway API 时，原有的安全注解（如 nginx.ingress.kubernetes.io/auth-url）需要转换为对应的 SecurityPolicy 资源。建议先使用 Gateway API 的 BackendTLSPolicy 管理后端 TLS，再逐步迁移认证和速率限制策略。

4.4 多团队协作对比

多团队协作是 Gateway API 相对于 Ingress 最突出的设计优势。Ingress 的扁平化模型导致团队间权限边界模糊，而 Gateway API 通过角色分离和命名空间隔离实现了清晰的协作模型。

4.4.1 角色模型对比

角色 Ingress 模型 Gateway API 模型
基础设施团队 管理 Ingress Controller 部署，但无法限制路由创建 管理 GatewayClass 和 Gateway，控制监听器端口、TLS 证书
平台团队 无明确角色，通常通过 RBAC 限制 Ingress 创建 管理 Gateway 和 Namespace 级别的策略，定义路由准入规则
应用团队 直接创建 Ingress，可能覆盖其他团队的路由 仅能创建 HTTPRoute/TCPRoute，且必须引用已授权的 Gateway
安全团队 无独立角色，安全配置分散在 Ingress 注解中 管理 SecurityPolicy，独立于路由资源，可全局审计

4.4.2 跨命名空间协作流程

Gateway API 通过 ReferenceGrant 机制实现安全的跨命名空间路由，解决了 Ingress 中跨命名空间引用无法标准化的问题：

Gateway API 跨命名空间协作流程 infra-ns Gateway: shared-gw GatewayClass: istio 基础设施团队管理 监听器: 443, 80 app-a-ns HTTPRoute: route-a Service: svc-a:8080 应用团队 A 管理 路由规则: /api/v1/* app-b-ns HTTPRoute: route-b Service: svc-b:8080 应用团队 B 管理 路由规则: /api/v2/* ReferenceGrant 显式授权跨命名空间引用
多团队协作最佳实践：
  • 基础设施团队 定义 GatewayClass 和 Gateway，控制监听器端口和 TLS 证书，不参与路由细节
  • 平台团队 通过 ReferenceGrant 控制哪些命名空间可以引用共享 Gateway
  • 应用团队 仅需关注 HTTPRoute 定义，无需关心网关基础设施
  • 安全团队 通过 SecurityPolicy 独立管理安全策略，与路由解耦

4.5 生态支持对比

生态支持是技术选型的重要考量因素。Ingress 经过多年发展拥有广泛的实现，但 Gateway API 作为 CNCF 孵化项目，生态支持正在快速追赶并超越。

4.5.1 实现支持对比

实现 Ingress 支持 Gateway API 支持 备注
nginx-ingress ✅ 成熟稳定 ✅ v1.0+ 实验性支持 社区版支持有限，企业版更完善
Istio ✅ 支持 ✅ 原生支持，推荐使用 Istio 1.16+ 默认使用 Gateway API
Contour ✅ 支持 ✅ 原生支持，早期采用者 Contour 是 Gateway API 的主要贡献者
Kong ✅ 支持 ✅ v2.0+ 支持 Kong Gateway Operator 支持
Traefik ✅ 支持 ✅ v2.5+ 实验性支持 CRD 方式支持
AWS ALB Ingress ✅ 支持 ⚠️ 部分支持 AWS 提供 VPC Lattice 集成
GKE Ingress ✅ 支持 ✅ GKE Gateway Controller Google Cloud 原生支持
Azure Application Gateway ✅ 支持 ⚠️ 预览阶段 AGIC 逐步迁移

4.5.2 社区与标准化进展

Gateway API 的生态发展速度显著快于 Ingress 同期：

  • CNCF 状态： Ingress 为 Kubernetes 内置资源，Gateway API 为 CNCF 孵化项目（SIG-NETWORK 管理）
  • 版本迭代： Gateway API v1.0（2023年10月）已发布稳定版，v1.1 增加 TCPRoute/UDPRoute 稳定支持
  • 贡献者规模： Gateway API 拥有 400+ 贡献者，来自 Google、Red Hat、Istio、Contour 等核心团队
  • 扩展机制： Gateway API 通过 Policy Attachment 和 Custom Route 实现标准化扩展，Ingress 依赖非标准注解
  • 工具链支持： kubectl、kustomize、Helm、ArgoCD 均已支持 Gateway API 资源
生态迁移建议：
  • 新项目： 优先选择 Gateway API 原生支持的服务网格（Istio）或 API 网关（Contour、Kong）
  • 存量 Ingress： 评估现有注解使用量，制定分阶段迁移计划，优先迁移流量拆分和跨命名空间路由场景
  • 云厂商： GKE 和 AWS 已提供成熟的 Gateway API 实现，Azure 和阿里云正在跟进

4.6 对比总结与升级决策矩阵

基于以上五个维度的对比分析，以下决策矩阵帮助架构师判断是否以及何时升级到 Gateway API：

评估维度 建议继续使用 Ingress 建议升级到 Gateway API
路由复杂度 仅需 host + path 简单路由 需要多维匹配、流量拆分、请求镜像
团队规模 单团队，无跨命名空间需求 多团队协作，需要角色分离和权限控制
安全需求 基础 TLS，无复杂认证 OIDC/JWT 认证、速率限制、IP 白名单
协议需求 仅 HTTP/HTTPS gRPC、TCP、UDP、TLS 多协议
云原生成熟度 传统部署，无服务网格 服务网格、GitOps、声明式基础设施
迁移成本 注解依赖少，路由规则简单 注解依赖多，需要重构安全策略
升级窗口提示： 建议在以下时机启动 Gateway API 升级：① 新集群建设时；② 网关版本大升级时；③ 引入服务网格时；④ 多团队协作冲突频繁时。避免在业务高峰期或大规模注解迁移期间进行升级。
← 上一章 📖 返回目录 下一章 →