🚀 Kubernetes网络新标准：全面掌握Gateway API (GatewayClass, Gateway, HTTPRoute)

10 月 28, 2026

—

大家好！👋 今天，我们将深入探讨Gateway API，这是管理进入Kubernetes (k8s) 集群流量的新标准。您是否曾感受到现有Ingress方式的局限性，并好奇Gateway API如何解决这些问题并提供更好的体验？通过本文，我们将以GatewayClass、Gateway、HTTPRoute这三个核心资源为中心，从TLS证书的应用方法到与Ingress的区别，为您清晰地解释一切！🤓

🤔 为什么Kubernetes需要新的流量管理方式？

随着Kubernetes环境变得越来越复杂，以及多个团队共享一个集群的情况增多，现有的Ingress方式遇到了一些明显的局限性。

角色分离的缺失: 集群管理员和应用程序开发人员之间的职责和权限没有明确分离。基础设施配置和路由规则混杂在一个Ingress对象中，这带来了微小的路由更改可能影响整个基础设施的风险。 😰
非标准化的扩展: 除了基本功能外，要使用基于流量权重路由、基于头部路由等高级功能，每个Ingress控制器（如Nginx、Traefik等）都需要使用不同的注解（annotation）。这导致了对特定供应商的依赖，并使得配置难以移植到其他环境。
有限的协议支持: Ingress主要关注HTTP/HTTPS流量，对于处理TCP、UDP、gRPC等其他协议力不从心。

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

GATEWAY API的3个核心要素：GatewayClass, Gateway, HTTPRoute

Gateway API围绕三个明确划分角色的核心资源运行。这就像一个团队通过分工协作高效工作一样。


资源	负责人 (角色)	职责
GatewayClass	基础设施提供者 (Infra Provider)	定义使用哪种负载均衡器类型的模板 (例如：AWS LB, GCP LB, Nginx)
Gateway	集群操作员 (Cluster Operator)	使用GatewayClass创建实际的负载均衡器实例，定义使用哪些端口和协议，以及允许哪些路由规则
HTTPRoute	应用程序开发人员 (App Developer)	连接到Gateway，详细定义特定主机名或路径的入站流量应发送到哪个服务

这种角色分离使得每个负责人都可以专注于自己的职责范围，从而大大提高了稳定性和安全性。

1. GatewayClass: 负载均衡器的蓝图 📜

GatewayClass是一个集群范围的资源，它定义了哪个控制器将管理网关。您可以使用云提供商的负载均衡器，也可以指定直接安装在集群内的Nginx或Istio等控制器。

YAML 示例:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: example.com/gateway-controller

controllerName: 指定将实现和管理此GatewayClass的控制器的名称。

2. Gateway: 流量的入口 🚪

Gateway引用GatewayClass来创建实际的负载均衡器实例。集群操作员通过此资源配置接收外部流量的端口、协议以及TLS证书等。

YAML 示例 (包含TLS证书):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: my-app-ns
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: https-listener
    protocol: HTTPS
    port: 443
    hostname: "example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-tls-secret # 存储TLS证书和私钥的Secret
        kind: Secret
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            expose: "true"

gatewayClassName: 指定要使用的GatewayClass。
listeners: 定义接收流量的端口和协议。
hostname: 可以限制只处理特定主机名的流量。
tls.certificateRefs: 引用包含HTTPS通信所需TLS证书的Secret。mode: Terminate表示TLS连接将在该网关处终止，网关与内部Pod之间将进行未加密的HTTP通信。
allowedRoutes: 通过命名空间标签限制可以连接到此网关的Route（例如：HTTPRoute），从而增强安全性。

3. HTTPRoute: 智能交通警察 👮

应用程序开发人员使用HTTPRoute详细定义如何处理进入Gateway的流量。这允许进行精细控制，例如基于路径的路由、基于头部的路由、基于权重的流量分割（金丝雀部署）等。

YAML 示例 (基于权重的流量分割):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: my-app-ns
  labels:
    expose: "true" # 必须与Gateway的allowedRoutes选择器匹配
spec:
  parentRefs:
  - name: my-gateway # 指定要连接的父Gateway
    namespace: my-app-ns
  hostnames:
  - "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

parentRefs: 指定此路由规则适用的父Gateway。
hostnames: 明确此规则适用的主机名。
rules: 定义实际的路由规则。上述示例是一个金丝雀部署场景，将进入example.com/的流量的90%发送到my-app-v1服务，10%发送到my-app-v2服务。

Gateway API vs Ingress: 有何不同？


功能	Ingress	Gateway API
角色分离	❌ 无 (单一资源)	✅ 明确 (GatewayClass, Gateway, Route)
可移植性	⚠️ 低 (供应商特定注解)	✅ 高 (标准化字段)
表达能力	⚠️ 有限 (基于路径/主机)	✅ 优秀 (头部、权重、过滤器等)
协议	HTTP, HTTPS	HTTP, HTTPS, TCP, UDP, gRPC, TLS
权限模型	⚠️ 需要广泛权限	✅ 基于角色的细粒度权限控制
跨命名空间	⚠️ 有限且危险	✅ 提供安全的引用模型 (ReferenceGrant)

最大的区别在于基于角色的架构。Gateway API明确分离了基础设施提供者和应用程序开发人员的职责，为多个团队安全、独立地共享一个集群提供了强大的基础。开发人员不再需要关心基础设施的细节，可以专注于自己的应用程序路由。

✨ 结论：为未来的标准做好准备！

Gateway API不仅仅是Ingress的替代品。它是一场改变Kubernetes网络范式的演进。通过其灵活、可扩展的基于角色的架构，它使得复杂微服务环境中的流量管理变得更加安全和高效。

即使您仍在使用Ingress，Gateway API在未来成为标准也是显而易见的。现在就开始理解Gateway API的概念，并思考如何将其应用于您的集群！您的Kubernetes之旅将迈上一个新的台阶。 🌟

标签: Kubernetes, Gateway API, Ingress, GatewayClass, Gateway, HTTPRoute, MSA, DevOps, Cloud Native