1. 云原生网关概述
云原生网关是构建在云原生基础设施之上，专为微服务、容器化、动态编排环境设计的统一流量入口层。它不仅是南北向流量的代理，更是服务治理、安全策略、可观测性与弹性能力的集中控制面。在 Kubernetes 与 Service Mesh 架构中，云原生网关已逐步取代传统 API 网关与反向代理，成为微服务架构的“前门”与“枢纽”。
1.1 云原生网关的定义
云原生网关是一种完全拥抱云原生理念的网关实现：
- 声明式配置：通过 CRD（Custom Resource Definition）或声明式 API 定义路由、限流、重试等策略，而非手动修改配置文件。
- 动态感知：自动监听 Kubernetes Service、Endpoint、Pod 变化，实时更新上游端点，无需重启或 Reload。
- 弹性伸缩：基于 HPA（Horizontal Pod Autoscaler）或 KEDA 自动扩缩网关实例，适配流量波峰波谷。
- 可观测性内建：原生集成 Prometheus 指标、OpenTelemetry 链路追踪、结构化访问日志。
- 安全左移：支持 mTLS、OIDC、JWT 验证、OPA 策略引擎，在网关层完成身份认证与授权。
核心代表项目： Envoy Gateway、Kong for Kubernetes、APISIX Ingress、Traefik、Contour、Gloo Edge。其中 Envoy 作为数据面，结合控制面（如 Istio、Kuma）已成为云原生网关的事实标准。
1.2 与传统网关的区别
传统网关（如 Nginx、HAProxy、传统 Kong）在静态配置、手动运维、单体部署模式下运行良好，但在云原生动态环境中暴露出明显短板。下表从多个维度对比两者差异：
| 对比维度 | 传统网关 | 云原生网关 |
|---|---|---|
| 配置方式 | 静态文件（nginx.conf）、Reload 或重启生效 | 声明式 CRD / API，热更新，零停机 |
| 服务发现 | 手动配置 upstream，或依赖外部脚本 | 自动监听 K8s Endpoint / Consul / Nacos |
| 弹性扩缩 | 手动增加机器，配置同步复杂 | HPA 自动扩缩，Pod 级生命周期管理 |
| 可观测性 | 依赖第三方插件（如 nginx-module-vts） | 原生 Prometheus + OpenTelemetry + 结构化日志 |
| 灰度发布 | 脚本切流，蓝绿部署需额外编排 | 内置权重路由、Header 匹配、金丝雀发布 |
| 安全策略 | IP 黑白名单、Basic Auth | mTLS、JWT、OIDC、OPA、RBAC |
| 运维模式 | SSH 登录、手动修改、重启 | GitOps、Operator、声明式生命周期 |
迁移建议： 从传统网关迁移至云原生网关时，建议先以“旁路模式”部署新网关，逐步将路由规则通过 CRD 声明，验证动态感知与灰度能力后再切换主流量。
1.3 在微服务架构中的核心作用
云原生网关在微服务架构中承担四个核心角色，缺一不可：
- 统一流量入口：所有外部请求（Web、移动端、第三方 API）统一经过网关，避免客户端直接调用分散的微服务，降低耦合度。
- 服务治理执行点：在网关层集中实施限流、熔断、重试、超时、负载均衡策略，无需在每个微服务中重复实现。
- 安全防线：TLS 终止、JWT 校验、 验证、IP 白名单、防 SQL 注入/ XSS 等安全能力前置到网关，保护后端服务。
- 可观测性数据面：网关作为所有流量的必经节点，天然适合采集请求延迟、错误率、吞吐量、链路追踪上下文，为 SRE 提供全局视图。
1.4 灰度发布与升级窗口中的网关角色
在云原生网关的升级窗口演练中，网关本身也是需要灰度升级的关键组件。网关的灰度批次升级直接影响所有后端微服务的流量稳定性，因此回归报告留痕尤为重要：
- 网关升级影响面大：网关升级失败会导致全站不可用，必须通过灰度批次逐步验证。
- 回归报告留痕：每次灰度批次升级后，自动生成回归报告，记录请求成功率、延迟变化、错误码分布、下游服务健康状态。
- 回滚决策依据：回归报告中的指标对比（基线 vs 当前批次）是判断是否继续下一批次或触发回滚的核心依据。
常见误区： 很多团队只关注后端微服务的灰度，却忽略了网关自身的灰度升级。网关作为所有流量的必经节点，其升级风险远高于单个微服务。务必为网关升级设计独立的灰度批次与回归报告留痕机制。