随着 Ingress NGINX 逐步进入退役周期，Kubernetes 入口治理能力也正在加快从 Ingress 向 Gateway API 演进。
面向这一变化，KubeSphere 正式推出 Gateway API 网关扩展。这意味着，KubeSphere 基于 Gateway API 的网关能力已正式落地，并进入可用阶段。
我们从实际场景出发，看看 KubeSphere Gateway API 网关扩展解决了什么问题、适合哪些场景，以及现有 Ingress 业务如何平滑迁移。
Gateway API 解决的首先是 API 标准层 的问题。对于一个真实的多租户平台来说，还需要继续回答几个更落地的问题：
谁来部署和维护 GatewayClass 背后的数据面工作负载？不同团队的 Gateway 如何按企业空间、项目等组织结构隔离？网关资源能否在控制台中直接管理，而不是只能通过命令行维护？网关相关的监控和日志如何接入平台能力？
KubeSphere Gateway API 网关扩展，解决的正是这一层平台化能力。
三个核心概念，对应 Gateway API 标准
为了让 Gateway API 能够真正适用于企业级、多租户场景，KubeSphere 在标准模型之上引入了三个核心概念，并与 Gateway API 的角色保持一致。
1. 网关实现（Gateway Implementation）
网关实现对应 Gateway API 背后的实现组件，包含网关实现工作负载以及一个 GatewayClass 实例。流量真正被接收和转发的位置，就在这一层。
网关实现通过 Service 对外暴露，当前支持 NodePort 和 LoadBalancer 两种方式，用户可以根据集群环境和基础设施条件进行选择。
2. 网关（Gateway）
网关对应 Gateway API 中的 Gateway 资源。它通过 listeners 引用同层级网关实现中的 entrypoints，用于定义监听端口、协议以及 TLS 证书等配置。
这一层通常更接近平台团队的职责边界，用来统一定义入口能力。
3. 应用路由（Route）
应用路由对应 Gateway API 中的各类路由资源，用于定义流量进入 Gateway 之后应如何转发到后端服务。
当前，KubeSphere 已支持以下四种 Route 类型：
HTTPRouteGRPCRouteTLSRouteTCPRoute
这覆盖了从七层到四层的常见入口场景，也使不同协议下的路由规则能够以更标准化的方式进行配置。
整体来看，这三类资源分别对应实现层、入口层和路由层，职责划分比传统 Ingress 模型更清晰，也更适合平台团队和业务团队分工协作。
三层级治理：把 API 字段对齐到组织结构
支持 Gateway API 只是第一步。对于企业级平台来说，更关键的是如何把这套能力真正纳入组织结构和权限体系中。KubeSphere Gateway API 网关扩展将网关实现和网关划分为三个层级：集群、企业空间、项目。
在这一模型下，网关层级与网关实现层级一一对应。Gateway 只能引用同层级的网关实现，而 Route 的可绑定范围也会随着 Gateway 的层级受到限制。
这种隔离并不是界面上的“软约束”，而是通过 Gateway 的路由允许范围在控制面进行约束。跨层级的 Route 即便配置了 parentRefs，也不会被对应 Gateway 接受或生效。
这套机制对应着三类典型使用场景：
集群层级网关：由平台管理员维护，作为集群统一的南北向入口，允许集群范围内的 Route 挂载。企业空间层级网关：由企业空间管理员维护，作为某个业务线或部门边界内的入口。项目层级网关：由项目级用户维护，生命周期和项目对齐。
对于此前使用 Ingress 构建多租户入口体系的用户来说，这类问题并不陌生。过去很多隔离能力依赖 RBAC 和运维约定来维持，而现在，这些边界可以直接落到资源层级和标准 API 字段中。
监控和日志：依赖 WizTelemetry 扩展
网关实现的可观测性通过独立扩展接入：
WizTelemetry 监控：提供网关实现的指标采集与监控面板，覆盖连接数、QPS、延迟、错误率等指标。WizTelemetry 日志：提供网关日志的搜索与排查能力。
网关扩展本身聚焦数据面和控制面能力，观测层则可按需启用。如果生产环境对请求级排查、访问日志检索和故障定位有要求，建议同时启用 WizTelemetry 监控和 WizTelemetry 日志扩展。
如果你正在规划新的入口方案，建议从测试环境或新业务开始体验 Gateway API 网关扩展。
我们也非常欢迎你在实际使用中的反馈，这将直接影响后续默认网关方案的选择。如有问题或建议，欢迎通过 GitHub Issue 或开发者论坛与我们交流。
