2. K8s 网关生态全景：Ingress、Gateway API、Service Mesh 的架构对比与选型
在 Kubernetes 集群升级前，网关层是流量入口与南北向/东西向通信的核心枢纽。理解当前主流的三种网关技术路线——Ingress、Gateway API 与 Service Mesh（以 Istio/Envoy 为代表）——的架构差异与适用场景，是构建容量规划基线的前提。错误的选型会导致升级过程中流量中断、性能瓶颈或运维复杂度失控。
2.1 三种网关技术的架构定位
下表从控制面、数据面、协议支持、扩展性等维度，对三种技术进行横向对比：
| 对比维度 | Ingress（传统） | Gateway API | Service Mesh（Istio/Envoy） |
|---|---|---|---|
| 标准来源 | Kubernetes 内置 API（networking.k8s.io/v1） | SIG-Network 主导的下一代 API（gateway.networking.k8s.io） | CNCF 生态，Istio 主导，Envoy 为数据面 |
| 控制面 | Ingress Controller（如 Nginx、HAProxy） | Gateway Controller + Provider 实现 | Istiod（Pilot、Mixer、Citadel 整合） |
| 数据面 | 反向代理（Nginx、Traefik 等） | 与 Ingress 类似，但支持更丰富的路由语义 | Sidecar Envoy 代理（每个 Pod 一个） |
| 南北向流量 | ✅ 原生支持 | ✅ 原生支持，更精细 | ✅ 通过 Ingress Gateway 支持 |
| 东西向流量 | ❌ 不支持 | ❌ 不支持（仅南北向） | ✅ 核心能力（服务间通信） |
| 协议支持 | HTTP/HTTPS 为主，gRPC 需扩展 | HTTP/HTTPS、gRPC、TCP 原生支持 | HTTP/HTTPS、gRPC、TCP、WebSocket、MongoDB 等七层协议 |
| 流量治理 | 基础（重定向、重写、限流需插件） | 高级（超时、重试、镜像、跨命名空间路由） | 全栈（熔断、限流、故障注入、灰度发布、mTLS） |
| 安全能力 | TLS 终止、基础认证 | TLS 策略、证书绑定、跨命名空间引用 | mTLS、RBAC、JWT 认证、授权策略 |
| 扩展性 | 通过 Annotation 或 CRD 扩展 | 分层 API + Policy Attachment 机制 | Envoy Filter + Wasm 扩展 |
| 成熟度 | ⭐⭐⭐⭐⭐ 生产广泛使用 | ⭐⭐⭐⭐（v1.0 已发布，生态快速成熟） | ⭐⭐⭐⭐（Istio 1.5+ 生产就绪） |
选型提示： 如果你的集群仅需简单的 HTTP 南北向路由，传统 Ingress 仍然够用。但若涉及多团队、多协议、灰度发布或东西向安全通信，Gateway API 或 Service Mesh 是更优选择。
2.2 架构对比：控制面与数据面分离视角
三种网关在架构上的核心差异在于控制面与数据面的耦合程度以及数据面的部署位置。下图展示了三者的逻辑架构：
架构要点：
- Ingress 控制面与数据面通常由同一个 Controller 进程管理，耦合较紧，扩展需修改 Controller 配置。
- Gateway API 通过分层资源（GatewayClass、Gateway、HTTPRoute）解耦了基础设施与路由策略，适合多租户场景。
- Service Mesh 将数据面下沉到 Sidecar，每个 Pod 自带 Envoy，控制面集中管理，东西向流量治理能力最强，但资源开销也最大。
2.3 选型决策矩阵
在集群升级前，需要根据团队规模、流量特征、运维能力进行选型。以下决策矩阵可辅助判断：
| 场景 / 需求 | 推荐方案 | 理由 |
|---|---|---|
| 单团队、简单 HTTP 路由、无东西向需求 | 传统 Ingress（Nginx） | 成熟稳定，运维成本最低，升级风险小 |
| 多团队共享集群、需跨命名空间路由 | Gateway API | 原生支持多租户隔离，路由策略可分层管理 |
| 微服务架构、需灰度发布、熔断、mTLS | Service Mesh（Istio） | 东西向治理能力不可替代，Envoy 数据面性能优异 |
| 混合场景：南北向 + 东西向统一管理 | Istio + Gateway API | Istio 1.10+ 已原生支持 Gateway API，可统一南北向与东西向策略 |
| 资源敏感、Sidecar 开销不可接受 | Gateway API + 轻量代理 | 避免 Sidecar 资源消耗，仅使用南北向网关 |
2.4 升级前网关容量规划的关键考量
无论选择哪种网关技术，在集群升级前都需要对网关层进行容量基线评估。以下是三个核心维度：
- 数据面资源消耗
- Ingress/Nginx：主要消耗 CPU 与内存，取决于 TLS 终止、连接数、请求体大小。
- Gateway API（Envoy 实现）：与 Ingress 类似，但多协议支持可能增加内存开销。
- Service Mesh（Sidecar Envoy）：每个 Pod 额外占用约 50-200MB 内存 + 0.5-2 核 CPU（视流量而定）。
- 控制面压力
- Ingress Controller：配置变更时重载，大规模集群可能触发 Reload 风暴。
- Gateway Controller：通过 Watch 机制监听资源变化，需评估 API Server 压力。
- Istiod：需处理所有 Sidecar 的 xDS 推送，集群规模超过 500 个 Pod 时建议独立部署并配置 HPA。
- 升级兼容性
- Ingress：K8s 版本升级通常不影响 Ingress 资源定义，但 Controller 版本需同步升级。
- Gateway API：CRD 版本与 API 版本需对齐，升级前务必检查 CRD 兼容性。
- Service Mesh：Istio 版本与 K8s 版本有严格映射关系，升级前需查阅兼容性矩阵。
升级风险提示： 在 K8s 集群升级过程中，网关层往往是第一个暴露问题的组件。建议在升级前至少完成以下操作：1）记录当前网关的 CPU/Memory 基线；2）在预发环境模拟升级流程；3）准备回滚方案（如保留旧版 Controller 的 Deployment 副本）。
2.5 选型总结与基线构建建议
综合以上分析，在《K8s集群升级前网关容量规划基线构建》课程中，我们建议按以下路径进行选型与基线构建：
- 如果集群规模 < 50 节点，且无东西向需求： 使用传统 Ingress（Nginx Ingress Controller），容量基线重点关注 CPU 与连接数。
- 如果集群规模 50-200 节点，多团队共享： 迁移至 Gateway API，利用其分层资源进行容量隔离，基线需覆盖 GatewayClass 与 Gateway 的资源配额。
- 如果集群规模 > 200 节点，微服务架构，需要灰度/安全能力： 采用 Istio + Envoy，容量基线需同时考虑 Sidecar 资源开销与 Istiod 控制面压力。