2. 云原生网关基础：Gateway API、Ingress Controller、服务网格网关的对比与选型
在云原生架构中，网关是流量进入集群的第一道关卡。随着 Kubernetes 生态的演进，目前主流的网关技术路线主要有三条：Ingress Controller、Gateway API 和 服务网格网关（如 Istio Ingress Gateway）。理解三者的设计哲学、适用场景和局限性，是后续实现 Helm 回滚护栏与租户配额校准的前提。
2.1 三种网关技术路线概述
| 维度 | Ingress Controller | Gateway API | 服务网格网关 |
|---|---|---|---|
| 标准状态 | Kubernetes 原生 v1 稳定 API | Kubernetes SIG-Network 孵化，v1beta1/v1 | Istio / Linkerd 等网格项目定义 |
| 核心资源 | Ingress | GatewayClass / Gateway / HTTPRoute | Gateway / VirtualService / DestinationRule |
| 流量治理 | 基础（路径/域名转发、TLS） | 丰富（权重、Header、重定向、后端熔断） | 最丰富（全链路 mTLS、灰度、故障注入） |
| 多租户隔离 | 弱（Namespace 隔离依赖实现） | 强（Route 与 Backend 跨 Namespace 授权） | 中（通过 Sidecar 与 RBAC 实现） |
| 回滚场景适配 | 需手动管理 Ingress 资源版本 | 原生支持策略合并与回滚 | 需配合 Istio Revision 机制 |
选型提示： 如果你的团队正在从传统 Ingress 迁移，且需要精细的租户配额管理，Gateway API 是目前最平衡的选择——它既保留了 Kubernetes 原生声明式配置的简洁性，又提供了多租户路由隔离和策略扩展能力。
2.2 架构对比：从数据面到控制面
下图展示了三种网关在 Kubernetes 集群中的典型部署位置与控制面关系。注意观察 控制面与数据面的耦合程度，这直接影响回滚时流量中断的风险。
2.3 选型决策矩阵
在实际项目中，选型需要结合团队运维能力、多租户需求、回滚频率和性能要求。以下决策矩阵可以帮助你快速定位：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 团队规模小，仅需基础路由 | Ingress Controller（Nginx） | 配置简单，社区成熟，学习成本低 |
| 多团队共享集群，需租户配额 | Gateway API | 原生支持跨 Namespace 路由授权，配额校准接口标准 |
| 已有服务网格（Istio） | 服务网格网关 | 统一数据面，减少运维组件，全链路可观测 |
| 高频回滚，需零中断 | Gateway API + 支持策略合并的实现 | 控制面与数据面解耦，回滚仅更新 Route 资源 |
| 严格安全合规（mTLS 全链路） | 服务网格网关 | Sidecar 自动注入，双向 TLS 无需应用改造 |
2.4 回滚场景下的关键差异
本课程的核心场景是 Helm 回滚后租户配额的自动校准。三种网关在回滚时的行为差异直接影响校准逻辑的设计：
- Ingress Controller： 回滚 Ingress 资源时，Controller 会重新加载配置，可能导致短暂连接中断。租户配额通常通过 Annotation 传递，回滚后需手动检查 Annotation 是否一致。
- Gateway API： 回滚 HTTPRoute 时，Gateway 实现（如 Contour / Envoy Gateway）支持策略合并，旧版本 Route 平滑替换，流量无中断。配额信息可通过 Route 的
metadata.labels或spec.filters传递，Helm 回滚后自动触发配额重算。 - 服务网格网关： 回滚 VirtualService 时，Istio 控制面会进行版本比对，但 Sidecar 的 Envoy 配置更新存在秒级延迟。租户配额通常通过
exportTo和meshConfig控制，回滚后需确保配额策略与路由版本一致。
避坑提醒： 如果选择 Ingress Controller 作为网关，在 Helm 回滚后，务必在 post-upgrade hook 中增加 Ingress Annotation 的校验步骤。因为 Ingress 的 Annotation 不属于 Kubernetes 原生资源字段，Helm 不会自动追踪其变更历史，容易导致配额丢失。
2.5 本课程选型结论
综合考虑 多租户配额管理的原生支持、回滚时的策略合并能力 以及 与 Helm 的集成成熟度，本课程后续实战将基于 Gateway API 进行演示。具体实现选用 Envoy Gateway 作为数据面，因为它对 Gateway API 的实现最完整，且支持丰富的流量策略扩展，便于实现租户配额的自定义 CRD 校准。