在Kubernetes集群中，Ingress资源自诞生以来一直是暴露HTTP和HTTPS服务的主要方式。它通过一个相对简单的对象定义主机名、路径和后端服务，配合Ingress Controller完成流量转发。但随着集群规模扩大和微服务架构深入，传统Ingress的局限性逐渐显现：注解驱动导致配置可读性差、单一资源模型缺乏角色分离、跨命名空间路由难以实现。Kubernetes Gateway API作为社区维护的新一代入口标准，试图从资源设计层面解决这些问题。本文从核心资源模型、功能特性差异、迁移与选型建议三个维度进行深入对比，帮助读者判断是否应该从Ingress迁移到Gateway API。
核心资源模型对比
传统Ingress的资源模型非常简单：一个Ingress对象既描述路由规则，又隐含负载均衡器的入口信息。例如下面这个典型配置，通过注解指定Ingress Controller类型，通过规则定义路径转发。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: app.ippipp.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 8080
这种模型的问题在于：流量入口的配置（如负载均衡器类型、TLS证书、监听端口）和路由规则（路径匹配、后端服务）耦合在同一个对象中。当多个团队共享一个入口时，任何一个团队修改Ingress对象都可能影响其他团队的路由。虽然可以通过注解实现一些高级功能，但注解本身没有统一的规范，不同Ingress Controller的注解完全不兼容，导致基础设施配置高度依赖具体实现。
Gateway API将入口流量管理拆分为多个独立的资源，核心包括GatewayClass、Gateway和HTTPRoute。GatewayClass定义网关控制器类型，类似于StorageClass；Gateway定义具体的网关实例，包括监听端口、协议和TLS配置；HTTPRoute则纯粹描述HTTP路由规则，与网关实例解耦。下面是一个等价的Gateway API配置示例，它将网关实例和路由规则分离成两个对象。
# 网关实例：由基础设施管理员负责
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-gateway
spec:
gatewayClassName: nginx
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
---
# 路由规则：由应用开发者负责
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: api-route
spec:
parentRefs:
- name: shared-gateway
hostnames:
- app.ippipp.com
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: api-service
port: 8080
这种分离带来了明显的角色划分：集群管理员通过GatewayClass和Gateway控制基础设施层面的网络接入，应用开发者只需关注HTTPRoute中的路由规则。此外，HTTPRoute支持跨命名空间引用后端服务，但可以通过ReferenceGrant进行精细化授权，避免了Ingress中要么全局开启要么完全禁止的粗粒度控制。
功能特性差异
传统Ingress在协议支持上基本局限于HTTP和HTTPS，对于TCP、UDP或gRPC流量，通常需要依赖特定Ingress Controller的扩展（如NGINX Ingress使用ConfigMap或自定义资源）。Gateway API则从设计之初就考虑了多协议支持，除了HTTPRoute之外，还定义了TCPRoute、UDPRoute、TLSRoute和GRPCRoute等路由类型。例如，一个TCPRoute可以直接将TCP流量转发到后端服务，无需任何注解。
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: mysql-route
spec:
parentRefs:
- name: shared-gateway
sectionName: tcp-3306
rules:
- backendRefs:
- name: mysql-service
port: 3306
在流量治理能力方面，传统Ingress的注解方式虽然能够实现超时、重试、请求头修改等功能，但注解数量庞大且难以维护。例如，NGINX Ingress中设置超时需要使用nginx.ingress.kubernetes.io/proxy-connect-timeout、nginx.ingress.kubernetes.io/proxy-read-timeout等多个注解。Gateway API通过标准化的字段直接表达这些能力。在HTTPRoute中，可以使用timeouts字段设置请求超时，使用filters字段进行请求头修改、重定向等操作，还可以通过backendRefs中的weight字段实现金丝雀发布或蓝绿部署。
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: canary-route
spec:
rules:
- backendRefs:
- name: stable-service
port: 8080
weight: 90
- name: canary-service
port: 8080
weight: 10
timeouts:
request: 5s
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
set:
- name: X-Env
value: canary
另一个显著差异是可扩展性模型。传统Ingress的扩展依赖注解，而注解没有结构校验，拼写错误或版本不匹配往往只能在运行时被发现。Gateway API通过策略关联（Policy Attachment）机制实现扩展，任何自定义策略都可以通过targetRef关联到Gateway或HTTPRoute，并经过严格的CRD校验。此外，Gateway API引入了实验性通道和正式通道，用户可以按资源粒度选择启用不同的API版本，既保证了稳定性又允许提前体验新特性。
迁移与选型建议
对于现有集群，Gateway API并不要求立即替换Ingress。两者可以共存，前提是使用的Ingress Controller同时支持Gateway API。目前，包括NGINX、Envoy Gateway、Istio、Traefik、HAProxy在内的主流网关项目都已经提供Gateway API实现。迁移可以采用渐进式策略：先为新的服务创建Gateway和HTTPRoute，验证功能稳定后，再将旧的Ingress规则逐步转换为HTTPRoute。由于Gateway API对象与Ingress对象互不影响，整个迁移过程可以平滑进行。
判断是否应该向Gateway API迁移，可以从以下几个维度考虑。第一，团队规模与协作模式：如果多个团队共享同一个入口，Ingress的单一对象模型容易造成配置冲突，Gateway API的角色分离和命名空间隔离能显著降低运维复杂度。第二，协议需求：如果集群需要暴露TCP、UDP或gRPC服务，传统Ingress通常需要额外扩展，而Gateway API提供了原生支持。第三，多集群或统一网关需求：Gateway API允许通过编程方式管理网关生命周期，更适合平台团队构建统一的入口控制平面。第四，对可移植性的要求：如果希望避免被特定Ingress Controller的注解绑定，Gateway API提供了标准化的迁移路径。
对于小型集群或单团队场景，如果现有的Ingress配置已经满足需求，并且没有暴露非HTTP协议的计划，那么继续使用Ingress完全合理。传统Ingress的简单性意味着更低的学习成本和更少的资源消耗。不过，考虑到Gateway API已经成为Kubernetes社区推进入口标准化的方向，新项目可以直接采用Gateway API，避免未来二次迁移。建议读者在测试环境中部署Gateway API，用当前真实的路由规则进行验证，再决定是否在生产环境推广。
Kubernetes Gateway APIIngress流量路由修改时间：2026-08-26 18:37:04