Gateway API

一、Gateway API 如何划分基础设施团队、集群运营与应用开发者的职责？

1. 三种角色的定义

• 基础设施提供商（Infrastructure Provider）：管理底层基础设施（如云厂商），负责提供可运行多租户集群的环境，并定义 GatewayClass，即声明网关的实现类别与控制器。
• 集群操作员（Cluster Operator）：管理集群，关注网络访问策略、应用权限与安全合规等平台级事项，负责创建 Gateway 与 Listener 配置，掌控流量暴露的边界。
• 应用开发者（Application Developer）：关注应用层配置与服务编排，在 Gateway 允许的范围内编写 HTTPRoute 等路由资源，定义自身服务的流量规则。

2. 角色分离带来的价值

• 职责边界清晰：平台团队掌控入口与策略，应用团队独立管理自身路由，避免了 Ingress 时代"实现特定的注解写满应用对象、平台却要兜底维护"的混乱。
• 安全可控：Gateway 通过 allowedRoutes 约束哪些命名空间的路由可绑定到监听器，平台保留流量暴露的最终控制权，降低多团队共用集群时的误操作与越权风险。

二、Gateway API 的核心资源对象有哪些？

1. 资源模型概览

Gateway API 通过一组相互关联的 CRD 描述服务网络，资源统一位于 gateway.networking.k8s.io API 组。核心对象包括：

• GatewayClass：集群级资源，定义一类网关的实现方式与控制器。
• Gateway：命名空间级资源，定义监听器（Listeners）与网络入口。
• Route（路由）：协议相关的路由资源，将 Gateway 监听器流量映射到后端服务。
• Policy（策略）：通过策略附着（Policy Attachment）机制，将超时、重试、鉴权等能力挂载到 Gateway 或 Route。
• ReferenceGrant：跨命名空间引用的安全授权机制。

2. 资源间的依赖关系

• 一个 Gateway 关联且只关联一个 GatewayClass；GatewayClass 通过 spec.controllerName 描述实现该类的控制器名称。
• 一个或多个 Route 通过 parentRefs 绑定到 Gateway 的监听器，形成双向信任模型：Gateway 过滤可绑定的路由，路由引用 Gateway 作为父级。
• 部分能力由独立资源承载，例如 BackendTLSPolicy 负责网关到后端的 TLS，ReferenceGrant 负责跨命名空间后端引用的授权。

三、Gateway API 中的 GatewayClass 资源有什么作用？

1. 定义网关实现类别

• GatewayClass 是集群级（Cluster-scoped）资源，声明"一类网关"的通用配置与行为，类似于 Ingress 的 IngressClass 或存储的 StorageClass。
• 每个 GatewayClass 通过 spec.controllerName 引用具体实现它的控制器（如 Envoy Gateway、Istio、NGINX Gateway Fabric 等）。

2. 由基础设施提供商创建

• 通常由基础设施提供商或平台团队创建，集群中至少需定义一个 GatewayClass 才能拥有可用的网关。
• 可通过 parametersRef 引用控制器专属的配置对象，实现实现特定的参数化定制，而无需改动通用字段。

3. 能力声明与一致性

• GatewayClass 的状态提供 supportedFeatures 字段（自 v1.4 起进入标准通道），由控制器主动声明其所支持的功能集合，用户与工具可据此判断该实现的能力范围；一致性测试套件也会基于该字段自动选取用例，无需依赖厂商文档猜测。

四、Gateway API 中的路由资源（Route）有哪些类型？

1. 协议相关的路由种类

• HTTPRoute：处理 HTTP/HTTPS 流量，是 Gateway API 中最常用的路由类型，支持基于路径、主机名、Header、Query 参数等匹配。
• GRPCRoute：专门处理 gRPC 流量，支持 gRPC 服务与方法级别的匹配。
• TLSRoute：基于 TLS 握手中的 SNI 进行路由，适用于 TLS 透传与终止场景。
• TCPRoute / UDPRoute：分别处理原始 TCP 与 UDP 流量，覆盖数据库、DNS、游戏服务器等四层场景。

2. 稳定性与发布通道

• HTTPRoute、GRPCRoute 已处于标准通道（GA，v1 版本）；TLSRoute 在 v1.5 中晋升为标准通道 v1；TCPRoute 与 UDPRoute 在 v1.6.0（2026 年 6 月 30 日发布）中一并晋升为标准通道 v1，其 v1alpha2 版本自 v1.6 起被弃用并将在未来版本移除。
• 仍处于实验通道的资源使用 X 前缀并归属 gateway.networking.x-k8s.io API 组，未来版本可能包含破坏性变更，晋升到标准通道时需以标准名称重建。

五、Gateway API 中的 Listener（监听器）有什么作用？

1. 监听器的职责

• Listener 是 Gateway 资源中的子对象，定义网关在某一端口上监听的协议与网络端点，是流量进入数据平面的入口。

2. 关键字段

• name：监听器名称。
• port / protocol：监听端口与协议（HTTP、HTTPS、TCP、UDP、TLS 等）。
• hostname：监听器匹配的主机名，支持通配符。
• tls：TLS 配置，包含模式（Terminate 终止 / Passthrough 透传）与证书引用 certificateRefs。
• allowedRoutes：约束哪些命名空间、以何种方式可以将路由绑定到该监听器。

六、Gateway API 中的 backendRefs 如何将请求转发到后端服务？

1. 后端引用机制

• Route 规则的 backendRefs 字段将匹配到的请求转发到后端网络端点，最常见的是 Kubernetes Service（亦可指向其他后端类型）。
• 每个 backendRef 指定后端名称与端口，从而将流量导向 Service 背后的 Pod 端点。

2. 流量权重与分流

• backendRefs 支持为多个后端设置 weight（权重），网关按权重比例将请求分发到各版本，实现流量分割。
• 例如将 90% 流量指向稳定版本、10% 指向新版本，即可在单条路由中实现金丝雀发布，无需额外组件。

3. 网关到后端的安全性

• 自 v1.4 起，BackendTLSPolicy 晋升为标准通道，可要求网关以 TLS 方式连接后端并校验证书，加密"网关到 Pod"这段此前常为明文传输的链路，无需依赖注解或厂商专属 CRD。

七、Gateway API 支持哪些网络协议？

1. 应用层与四层协议覆盖

• HTTP / HTTPS：由 HTTPRoute 承载，支持丰富七层路由能力。
• gRPC：由 GRPCRoute 承载，支持服务与方法级匹配。
• TLS：由 TLSRoute 承载，基于 SNI 路由。
• TCP / UDP：由 TCPRoute、UDPRoute 承载，覆盖四层流量。

2. 协议无关的设计理念

• 与仅原生支持 HTTP/HTTPS 的 Ingress 不同，Gateway API 通过协议专属的路由资源原生支持多协议，无需借助注解或厂商 CRD 来扩展协议能力，提升了配置的可移植性。

八、Gateway API 如何处理 TLS 终止与 TLS Passthrough？

1. TLS 终止（Terminate）

• 在 Gateway 监听器上将 TLS 配置为 Terminate 模式，网关负责解密客户端流量，再以内层协议（如 HTTP）转发到后端，并通过 certificateRefs 引用 Secret 中的证书。

2. TLS 透传（Passthrough）

• 在 Passthrough 模式下，网关不解密 TLS，而是依据客户端握手时的 SNI 将加密流量直接转发到后端，适用于对安全要求严格、需端到端加密的场景，典型由 TLSRoute 实现。

3. 网关到后端的加密

• 除客户端到网关的 TLS 外，还可通过 BackendTLSPolicy 为"网关到后端"这段链路配置 TLS 校验，形成端到端加密，满足多租户集群中跨命名空间网络不加密的隐患治理需求。

九、Gateway API 如何实现流量分割与灰度发布？

1. 基于权重的流量分割

• 在 HTTPRoute 等路由的 backendRefs 中为不同后端设置 weight，网关按权重比例将请求分发到各版本，实现流量分割。

2. 灰度发布的典型做法

• 将新版本后端以较小权重（如 10%）接入同一路由，配合监控逐步调大权重，完成金丝雀发布。
• 同一路由还可按 Header、Query 参数或路径将特定流量导向新版本，进行 A/B 测试与蓝绿发布。

十、Gateway API 支持哪些请求级别的流量治理能力？

1. 路由规则内的治理能力

• 请求/响应头修改：在路由规则中添加、删除或改写 HTTP 头。
• URL 重写与重定向：支持路径重写与内部/外部重定向。
• 请求镜像（Mirroring）：将生产流量复制一份发往观测服务，不影响主线响应。
• 超时与重试：通过 HTTPRoute 的超时、重试字段（或 BackendTrafficPolicy 等策略）控制请求级容错。

2. 跨资源策略扩展

• 鉴权、限流、CORS 等能力通过策略附着（Policy Attachment）机制挂载到 Gateway 或 Route，实现细粒度、可移植的流量治理，避免各控制器自定义注解互不兼容。

十一、Gateway API 如何实现跨命名空间的流量路由？

1. allowedRoutes 控制绑定范围

• Gateway 监听器通过 allowedRoutes 限定可绑定的命名空间来源（如 Same、Selector、All），默认仅接受同命名空间路由，防止未授权暴露。

2. ReferenceGrant 授权跨命名空间引用

• 当某命名空间的 Route 需要引用另一个命名空间的后端 Service 时，目标命名空间必须存在对应的 ReferenceGrant，显式授权该引用。
• ReferenceGrant 通过 from（引用方 group/kind/namespace）与 to（被引用方 group/kind/name）描述授权关系，是 Gateway API 跨命名空间安全模型的基石，缺失授权时跨命名空间后端引用会被拒绝。

十二、Gateway API 的 Status 字段提供了哪些可观测信息？

1. 标准条件（Conditions）

• 每个资源通过 Status.Conditions 反映其状态，核心条件包括 Accepted（是否被控制器接受）与 Programmed（配置是否已下发到数据平面）。

2. 监听器级状态

• Gateway 的 Status 会逐监听器汇报 attachedRoutes（已绑定的路由数）、Ready 等状态，便于快速定位路由绑定或监听器配置错误。

3. 运维价值

• 由于 Gateway API 强调可观测性，检查资源 Status 是排障最快的方式，例如通过 kubectl describe gateway 查看条件与事件，即可判断配置是否被正确接管。

十三、Gateway API 的 Standard 通道与 Experimental 通道有何区别？

1. 两种发布通道的定位

• 标准通道（Standard）：包含已晋升为 GA 或 Beta 的资源与字段，承诺稳定性，适合生产使用。v1.0 于 2023 年 10 月 GA 后，GatewayClass、Gateway、HTTPRoute、GRPCRoute、ReferenceGrant 等陆续进入该通道。
• 实验通道（Experimental）：在标准通道基础上加入实验性资源与字段，用于快速迭代新特性，但未来版本可能包含破坏性变更。

2. 安装与演进

• 项目以标准通道与实验通道两套 YAML 发布；自 v1.3.0 起，新增实验性资源使用 X 前缀并归属 gateway.networking.x-k8s.io API 组，v1.6 进一步将实验性资源统一迁移至该独立 API 组，使实验与标准的边界一目了然；资源晋升到标准通道时需以标准名称重建。
• 特性随版本从实验通道晋升到标准通道，例如 TLSRoute 在 v1.5 晋升为 v1，ListenerSet、BackendTLSPolicy 等也相继 GA，体现项目"先实验、后稳定"的演进节奏。

十四、Gateway API 的一致性测试（Conformance）有什么作用？

1. 保障可移植性

• 一致性测试验证各实现是否真正按规范支持核心功能，使相同配置在不同控制器间产生一致行为，是 Gateway API 区别于 Ingress 注解乱象的关键机制。

2. 三级支持级别

• 功能分为 Core （核心，所有实现都应支持）、Extended （扩展，可移植但非普遍支持）、Implementation-specific （实现特定，厂商自定义） 三级；一致性测试重点覆盖 Core 与所声明支持的 Extended 特性。

3. 两类一致性画像

• 项目定义 Gateway 画像（南北向流量，由 Gateway 控制器实现）与 Mesh 画像（东西向流量，由服务网格控制器实现）；实现需通过对应画像的核心一致性测试并公示报告，用户可据此比对各实现的能力边界。

十五、目前有哪些主流的 Gateway API 控制器实现？

1. 网关控制器（南北向）

• 社区与厂商提供了多种网关控制器，代表性开源实现包括 Envoy Gateway、NGINX Gateway Fabric、Istio、Cilium、Traefik、HAProxy Ingress、Kong Gateway、Contour 等；主流云厂商也提供托管式 Gateway 控制器。

2. 服务网格控制器（东西向）

• 服务网格侧，Istio、Cilium、Linkerd、Kuma 等提供对 Mesh 画像的一致性支持。

3. 选型参考

• 各实现的一致性状态随版本演进，项目官网的"实现（Implementations）"页面按发布版本公示一致性报告，建议在选型时以最新报告为准，而非仅凭厂商文档判断。

十六、在实际生产中应该如何选择 Gateway API 的控制器？

1. 按流量维度选型

• 仅需要南北向入口（入集群流量）时，优先选择网关控制器（如 Envoy Gateway、NGINX Gateway Fabric、Traefik 等）；若还需东西向服务间治理，则需选择支持 Mesh 画像的实现（如 Istio、Cilium、Linkerd）。

2. 按环境与技术栈选型

• 云上托管集群可优先采用云厂商提供的托管 Gateway 控制器，降低控制面运维成本；已有服务网格（如 Istio 体系）的团队，可沿用同一数据面统一南北向与东西向流量，减少学习多套 API 的成本。

3. 以一致性报告为准

• 关注目标实现在当前 Gateway API 版本下是否通过所需 Core 与 Extended 特性的一致性测试，避免依赖尚未稳定支持的能力，尤其在生产关键路径上。

十七、如何在一个 Kubernetes 集群中安装和启用 Gateway API？

1. 安装 CRD

• Gateway API 以 CRD 形式提供，并非 Kubernetes 内置，需先安装对应版本的 CRD 包。
• 通过官方发布的 standard-install.yaml（标准通道）或 experimental-install.yaml（实验通道）以 kubectl apply 安装；v1.6.0 于 2026 年 6 月 30 日发布，当前最新补丁版本为 v1.6.1。

2. 安装控制器

• 安装一个实现 Gateway API 规范的控制器，多数控制器会在部署时自动安装 CRD；在腾讯云容器服务（TKE）等托管 Kubernetes 集群中，同样先安装 CRD，再部署所选控制器即可获得路由能力。

3. 验证与排障

• 控制器运行后，可通过部署示例 Gateway 与 HTTPRoute 验证路由是否生效，并查看资源 Status 条件确认配置已下发到数据平面。

十八、GAMMA 计划如何让 Gateway API 支持服务网格？

1. GAMMA 的定位

• GAMMA（Gateway API for Mesh Management and Administration）是 Gateway API 子项目中专注于服务网格的工作流，目标是用同一套路由原语同时管理南北向与东西向流量，且尽量减少对 API 的改动、保持角色导向特性。

2. parentRef 翻转机制

• GAMMA 的关键做法是：入集群场景下 Route 绑定到 Gateway，而服务网格场景下，同一个 HTTPRoute / GRPCRoute 直接绑定到 Service（通过 parentRefs 指定 kind: Service），表示该 Service 收到的所有流量都按此路由规则处理，无需引入新的资源类型。

3. 标准化与成熟度

• GAMMA 自 2022 年启动，于 v1.1.0（2024 年 5 月）晋升为标准通道并达到 GA；Istio、Linkerd（2.14+）、Kuma（2.3+）、Cilium 等实现对 Mesh 画像一致性达标。腾讯云服务网格（TCM，100% 兼容 Istio API）亦可作为 GAMMA 一致的数据面，统一承载集群内服务间流量治理。

十九、Gateway API 适合哪些典型应用场景？

1. 多团队共享入口与多租户

• 角色分离模型让平台团队掌控 Gateway 与策略、应用团队独立管理路由，天然适合多团队共用集群、按需安全暴露服务的场景。

2. 高级路由与渐进式发布

• 流量分割、Header/路径匹配、重定向重写、请求镜像等能力，开箱即用地支撑金丝雀、A/B 测试、蓝绿发布，无需依赖厂商专属注解。

3. 南北向与东西向统一治理

• 借助 GAMMA，同一套 HTTPRoute / GRPCRoute 既管入集群流量、也管服务间流量，减少学习多套 API 的成本；在腾讯云容器服务（TKE）上配合腾讯云服务网格（TCM），可一体化落地南北向入口与东西向网格治理。

4. 多协议与跨集群

• 原生多协议支持适配 HTTP/gRPC/TCP/UDP/TLS 等混合负载；结合多集群服务（MCS）API，还可实现跨集群流量路由与就近接入，支撑多集群高可用架构。

二十、Gateway API 与 Kubernetes Ingress 在设计理念上有什么本质区别？

1. 角色模型

• Ingress 缺乏明确的角色划分，应用团队常在自身对象上写满实现特定的注解；Gateway API 以基础设施提供商、集群操作员、应用开发者三层角色明确划分职责，平台与应用各司其职。

2. 资源结构与可扩展性

• Ingress 是单一、单体资源，扩展能力依赖各控制器自定义的注解，互不兼容；Gateway API 采用 GatewayClass、Gateway、Route 等多资源组合，并通过 Policy Attachment 标准化扩展点，扩展能力与核心能力同样可移植。

3. 协议与表达能力

• Ingress 仅原生支持 HTTP/HTTPS，复杂路由（流量分割、镜像、头改写）需靠注解实现；Gateway API 原生支持多协议，并以类型化字段提供丰富七层路由能力，相同配置在不同实现间行为一致。

二十一、Gateway API 能否完全取代 Ingress？

1. 能力覆盖

• 对绝大多数入集群流量与渐进式发布场景，Gateway API 在表达能力、协议覆盖与角色治理上均优于 Ingress，是社区推荐的下一代服务网络标准。

2. 共存与迁移

• Gateway API 与 Ingress 可长期共存；官方提供从 Ingress 迁移的指南，建议逐个主机名或路由域迁移，校验策略、TLS 行为与可观测性后再下线对应 Ingress 规则。
• 是否"完全取代"取决于具体控制器对 Gateway API 特性的支持进度与存量注解逻辑的迁移成本，生产上通常采取逐步迁移而非一刀切切换，以降低风险。