3. Gateway API 架构原理：控制面与数据面分离、声明式 API、面向角色的设计理念

Gateway API 是 Kubernetes 社区下一代入口流量管理的标准，其架构设计围绕三个核心理念展开：控制面与数据面分离、声明式 API 以及 面向角色的设计。这三个理念共同解决了传统 Ingress 在扩展性、可维护性和多团队协作上的痛点。

3.1 控制面与数据面分离

在传统 Ingress 中，控制逻辑与数据转发逻辑往往耦合在同一个控制器中。Gateway API 通过明确的资源分层，将“谁来配置”与“谁来转发”彻底解耦。

• 控制面：由 GatewayClass 和 Gateway 资源组成，负责定义入口网关的拓扑结构、监听端口、TLS 证书等基础设施配置。控制面组件（如 Gateway Controller）监听这些资源，并驱动底层数据面组件生效。
• 数据面：由 HTTPRoute、TCPRoute 等路由资源组成，负责定义流量转发规则、后端服务选择、重定向、重写等业务逻辑。数据面组件（如 Envoy、HAProxy 实例）实际处理客户端请求。

3.2 声明式 API

Gateway API 遵循 Kubernetes 声明式模型。用户通过 YAML 或 JSON 描述期望的网关状态，控制器负责将实际状态收敛到期望状态。这种设计带来了以下优势：

• 可审计性：所有配置变更都记录在 Kubernetes API Server 中，形成完整的变更历史。
• 自愈能力：当数据面组件异常时，控制器会自动重新下发配置，确保流量规则持续生效。
• 版本化管理：支持通过 kubectl apply 进行增量更新，避免手动修改配置文件带来的风险。

以下是一个典型的声明式 Gateway API 配置示例：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: infra
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: apps
spec:
  parentRefs:
  - name: my-gateway
    namespace: infra
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-service
      port: 8080

3.3 面向角色的设计理念

Gateway API 将资源模型与组织角色对齐，每个角色只关注自己职责范围内的资源，降低了多团队协作的复杂度。

这种角色分离避免了传统 Ingress 中“一个 YAML 文件需要多个团队审批”的瓶颈。每个角色在自己的资源范围内独立工作，通过 parentRefs 字段建立跨资源的引用关系。

3.4 三种理念的协同效应

控制面与数据面分离、声明式 API、面向角色的设计并非孤立存在，它们共同构成了 Gateway API 的架构基石：

• 分离带来灵活性：控制面与数据面分离使得基础设施团队可以独立升级网关实现，而不影响应用团队的路由规则。
• 声明式保证一致性：声明式 API 确保所有角色的配置都通过统一的 Kubernetes API 进行管理，避免了配置漂移。
• 角色对齐降低复杂度：面向角色的设计让每个团队只关注自己熟悉的资源，减少了跨团队沟通成本。