Gateway API 成熟度变化怎样影响入口治理

我在评估共享 Kubernetes 入口时，最明显的变化不是又多了一个 Route 类型，而是 Gateway API 开始把“哪些能力可以长期依赖、哪些能力仍需试验”写进 API 边界。Gateway API v1.6 让 TCPRoute、UDPRoute 进入 Standard，并把新的实验资源移到独立的 gateway.networking.x-k8s.io API 组；入口治理因此要从“控制器能不能跑”升级为“团队能不能清楚地管理稳定性、权限和回滚”。

官方资料入口：https://gateway-api.sigs.k8s.io/

Gateway API v1.6 变化，真正改变的是治理边界

v1.6 将 TCPRoute 和 UDPRoute 从 Experimental 推进到 Standard，并采用 v1 API 版本。以前，HTTP 和 TLS 有较成熟的通用路由模型，而数据库、DNS、VoIP 或物联网等原始 TCP/UDP 流量往往只能使用 Service 或控制器专属 CRD。现在，平台团队可以用统一的 Gateway、Listener 和 Route 关系表达这类入口。

与此同时，新的实验资源使用 gateway.networking.x-k8s.io，类型名带有 X 前缀。这个变化很适合写进治理规范：生产基线默认接受 Standard；Experimental 只能进入试验命名空间、评审清单或明确的兼容性豁免。它把“版本号里的 alpha”变成了资源组层面的醒目标记。

Standard 不等于所有控制器都能无差别接管

我更愿意把成熟度分成两层看。第一层是规范本身是否稳定，第二层是具体实现是否完成对应的 conformance 测试、是否支持目标协议和策略。官方 v1.6 公告列出了当时通过一致性验证的实现，但这仍然不能替代团队对目标版本、安装的 CRD、GatewayClass 状态和控制器文档的核对。

从 Ingress 转过去，不能只改 apiVersion

Ingress2Gateway 1.0 的价值不在于“一键替换”，而在于把不可直接翻译的行为显式提示出来。官方说明提到，它支持 30 多个常见 Ingress-NGINX 注解，但正文大小、URL 规范化、正则匹配和超时等行为仍可能需要人工确认。尤其是注解背后的默认值，换成 Gateway API 后未必还有标准字段。

转换后的资源应该先进入开发集群。可以把关键对象简化成下面这种关系，注释只解释治理意图，不把示例当成某个控制器的完整生产配置：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-edge
spec:
  gatewayClassName: example-gateway-class # 先确认控制器与 conformance 能力
  listeners:
    - name: tcp-entry
      protocol: TCP # L4 入口要显式声明协议
      port: 12345
      allowedRoutes:
        kinds:
          - kind: TCPRoute # 只允许约定的 Route 类型挂载
---
apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: billing-tcp
spec:
  parentRefs:
    - name: shared-edge
      sectionName: tcp-entry # 绑定到指定 Listener，避免误挂载
  rules:
    - backendRefs:
        - name: billing-service
          port: 6000 # 后端端口必须与服务契约一致

入口治理要采用双轨灰度，而不是一次切换

更稳妥的迁移顺序是：先用 Ingress2Gateway 生成候选资源；再人工复核超时、正文大小、重写、正则和 URL 规范化；随后在开发集群验证请求行为；最后让旧 Ingress 与 Gateway API 并行运行，用加权 DNS、云负载均衡或平台的流量切分逐步迁移。任何一步出现差异，都应该能把流量切回旧入口。

我的判断是：Standard 能降低长期维护的不确定性，但不能替团队完成迁移决策。入口配置里只要存在实现专属注解，就应把它视为待验证的行为，而不是可自动继承的事实。对共享集群来说，Listener 的归属、Route 的跨命名空间引用和回滚权限，和 API 版本本身同样重要。

相关问题

Gateway API Standard 是否代表所有网关都支持 TCPRoute？

不代表。Standard 描述规范的稳定承诺，仍需核对具体 GatewayClass、控制器版本和一致性能力，并检查实际资源状态。

Ingress2Gateway 生成的 YAML 可以直接上线吗？

不建议。它会帮助翻译并提示缺失行为，但超时、正文大小、正则和 URL 规范化等边界必须在开发集群重新验证。

实验 API 组为什么值得单独限制？

独立 API 组让实验资源在清单、RBAC 和审计规则中更容易被识别。它仍然可以用于试验，但不应未经评审混入生产稳定基线。

详细版本变化可继续查阅 Kubernetes 官方公告：https://kubernetes.io/blog/2026/08/03/gateway-api-v1-6-release/；迁移工具说明：https://v1-35.docs.kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/。