Kubernetes Ingress，真的该说再见了吗？全面解析 Gateway API 🚀

8 月 12, 2026

—

cslab

in IT Security

大家好！您是否正在Kubernetes环境中运行服务？如果是这样，您可能对将外部流量连接到集群内部服务的“Ingress”非常熟悉。Ingress长期以来一直扮演着Kubernetes标准网关的角色。

然而，随着服务变得越来越复杂，需求也日益多样化，您可能曾有过这样的想法：

“我只想向移动用户展示不同的页面… 🤔”“能不能先将新版本的应用程序部署到10%的流量上进行测试？🐦”“我只想将带有特定HTTP头的请求发送到不同的服务… 🧐”

仅凭 Ingress 的基本功能，实现这些高级路由策略是相当困难的。当然，使用每个 Ingress Controller 提供的注解（annotation）可以实现部分功能，但这会导致对特定供应商的依赖，且缺乏标准化，从而降低了可移植性。

正是在这一点上，Kubernetes 的下一代网络标准——Gateway API——应运而生！

🧱 Ingress 的局限性：我们为什么需要新事物？

在理解 Gateway API 之前，明确现有 Ingress 的局限性至关重要。

有限的路由规则：Ingress 默认仅标准支持基于主机名（hostname）和路径（path）的路由。基于请求头、查询参数和权重的路由等并非标准功能。
供应商依赖的配置：如上所述，使用高级功能需要依赖特定 Ingress Controller 的注解，例如 nginx.ingress.kubernetes.io/rewrite-target。这意味着在更换不同的 Ingress Controller 时，所有设置都必须重新修改。😩
权限管理的困难：Ingress 资源通常由集群管理员或平台团队管理。但是，当应用程序开发人员想要修改特定路径的路由规则时，他们需要同时修改庞大的 Ingress YAML 文件，这使得权限分离变得困难，并存在冲突的风险。

为了解决这些问题，Gateway API 应运而生，它被设计得更加灵活、富有表现力且基于角色。

✨ Gateway API 的出现：有何不同？

Gateway API 是 Ingress 的后续项目，它通过将网络配置分离为多个独立的资源来最大化管理的灵活性。请记住以下三个核心组件：

GatewayClass：一个集群范围的模板。它定义了将使用哪种类型的负载均衡器（例如：AWS LB, NGINX, Istio）。（主要由集群管理员负责）☁️
Gateway：GatewayClass 的实际实例。它定义了特定的 IP 地址、端口、TLS 设置等，并代表负载均衡器本身。（主要由基础设施运维人员负责）🚪
HTTPRoute：定义实际的路由规则。它包含应用程序级别的规则，例如“将 /login 路径发送到 auth-service，将 /api/v2 路径发送到 new-api-service”。（主要由应用程序开发人员负责）🗺️

这种结构最大的优点是职责分离（Separation of Concerns）。基础设施团队通过 Gateway 提供稳定的网关，而开发团队只需关注其服务所需的 HTTPRoute 规则。他们可以独立工作，互不干涉。🤝

🎯 核心功能：无与伦比的流量控制能力

现在，我们将通过实际示例来探讨 Gateway API 为何能够实现“更精细的流量路由控制”。

1. 基于请求头的路由 (Header-based Routing)

假设您想区分移动应用用户和网页用户，并将他们发送到不同的后端服务。您可以根据 User-Agent 请求头来分流路由。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mobile-routing-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["example.com"]
  rules:
  - matches:
    - headers:
      - type: Exact
        name: User-Agent
        value: "MyMobileApp/1.0"
    backendRefs:
    - name: mobile-app-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-app-service
      port: 8080

上述 HTTPRoute 将 User-Agent 请求头为 MyMobileApp/1.0 的请求发送到 mobile-app-service，将所有其他请求发送到 web-app-service。这仅通过标准功能即可实现，无需 Ingress 注解！

2. 用于金丝雀部署的基于权重的路由 (Weight-based Routing) 🐦

您想部署新版本的 my-app-v2，并首先将总流量的 10% 发送给它以测试稳定性。Gateway API 为此提供了标准的 weight 字段。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-deployment-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["api.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-app-v1 # 现有版本服务
      port: 80
      weight: 90
    - name: my-app-v2 # 新版本服务
      port: 80
      weight: 10

只需这一个设置即可！my-app-v1 服务将接收 90% 的流量，my-app-v2 将接收 10%。不再需要依赖复杂的额外工具或非标准注解。⚖️

🌐 整体背景：为何要转向 Gateway API？

虽然单个功能的强大性很重要，但 Gateway API 带来的更大变化是 Kubernetes 网络的标准化和可移植性。

基于角色的 API：明确划分基础设施团队和开发团队的职责和权限，促进更顺畅的协作并减少错误。
可移植性：所有路由规则（请求头、权重等）都包含在标准规范中。这意味着即使您从 NGINX Gateway Fabric 切换到基于 Istio 的 Gateway，HTTPRoute 定义也可以基本原样重用。这使您摆脱了供应商锁定。🌍
表达能力和可扩展性：除了 HTTPRoute，它还支持 TCPRoute、UDPRoute、TLSRoute 等多种协议，并且可以通过自定义过滤器无限扩展路由规则。

结论

Ingress 仍然是暴露简单 Web 服务的出色工具。然而，在当今微服务架构日益复杂，金丝雀部署、A/B 测试和精细流量控制等高级功能成为必需的时代，Ingress 的局限性显而易见。

Gateway API 不仅仅是 Ingress 的替代品，它更是为满足现代云原生环境需求而设计的下一代标准。虽然目前没有必要立即替换所有 Ingress，但如果您正在启动新项目或感受到现有系统的局限性，那么是时候积极考虑 Gateway API 了。✨