2. Gateway API 基础：核心概念与传统 Ingress 对比

在云原生网关演进中，Kubernetes 原生 Ingress 资源因功能边界模糊、扩展性差、多团队协作困难等问题逐渐暴露出局限性。Gateway API 作为下一代网关标准，通过分层抽象和角色分离，为灰度发布、流量回滚等场景提供了更精确的控制面。本节将系统梳理 Gateway API 的三大核心概念，并与传统 Ingress 进行多维度对比。

2.1 三大核心概念

Gateway API 将网关配置拆解为三个独立资源，分别对应基础设施提供者、集群运维者和应用开发者三个角色：

2.2 核心概念关系图

下图展示了 GatewayClass、Gateway、HTTPRoute 三者之间的引用与绑定关系，以及它们如何共同构成完整的流量接入链路：

2.3 与传统 Ingress 的全面对比

传统 Ingress 在 v1 版本中仅提供基础的路由和 TLS 终止能力，而 Gateway API 在功能粒度、扩展性和多团队协作方面进行了根本性重构。以下从 8 个关键维度进行对比：

2.4 HTTPRoute 灰度规则示例

以下是一个典型的灰度发布 HTTPRoute 配置，展示了 Gateway API 如何原生支持权重分配和条件匹配：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-canary
  namespace: production
spec:
  parentRefs:
  - name: prod-gateway
    namespace: gateway-system
  rules:
  - matches:
    - headers:
      - name: "X-Canary"
        value: "true"
    backendRefs:
    - name: app-v2
      port: 8080
      weight: 100
  - backendRefs:
    - name: app-v1
      port: 8080
      weight: 90
    - name: app-v2
      port: 8080
      weight: 10

2.5 从 Ingress 迁移到 Gateway API 的路径

对于已有 Ingress 资源的集群，建议采用渐进式迁移策略：

• 阶段一（并行运行）： 安装 Gateway API CRD 和兼容的控制器（如 Nginx Gateway Fabric），保留现有 Ingress 资源，新建 Gateway 和 HTTPRoute 用于新服务。
• 阶段二（灰度迁移）： 将部分存量服务的 Ingress 规则逐步转换为 HTTPRoute，通过 DNS 权重或 Gateway 监听器切换验证功能正确性。
• 阶段三（全面切换）： 确认 HTTPRoute 稳定后，移除 Ingress 资源，统一使用 Gateway API 管理所有流量，并启用回滚护栏策略。