3. 网关在K8s集群中的角色：Ingress Gateway、API Gateway、Service Mesh Gateway
在 Kubernetes 集群的流量治理体系中，网关并非单一组件，而是根据职责边界划分为三个层次：Ingress Gateway（南北向流量入口）、API Gateway（业务策略执行点）和 Service Mesh Gateway（服务网格边界代理）。理解这三者的角色差异，是进行网关 Pod 容量规划的前提。
3.1 三种网关的核心职责对比
| 维度 | Ingress Gateway | API Gateway | Service Mesh Gateway |
|---|---|---|---|
| 流量方向 | 南北向（外部 → 集群内部） | 南北向 + 部分东西向 | 南北向 + 东西向边界 |
| 核心协议 | HTTP/HTTPS、gRPC、TCP | HTTP/HTTPS、gRPC、WebSocket | HTTP/HTTPS、gRPC、TCP、TLS |
| 主要功能 | 路由转发、TLS 终止、域名虚拟主机 | 认证鉴权、限流熔断、协议转换、API 版本管理 | mTLS 双向认证、流量镜像、访问控制、协议嗅探 |
| 配置粒度 | 路由规则（Host/Path） | API 级别（Method/Header/Query） | 服务级别 + 端口级别 |
| 典型实现 | nginx-ingress、traefik、HAProxy | Kong、APISIX、Gloo Edge | Istio Ingress/Egress Gateway、Envoy |
| 升级影响范围 | 全局流量入口 | 业务 API 策略 | 网格内所有服务间通信 |
容量规划提示： 三种网关在集群升级窗口中的 Pod 容量规划策略不同。Ingress Gateway 关注连接数峰值和 TLS 卸载性能；API Gateway 关注策略执行延迟和限流队列深度；Service Mesh Gateway 关注 mTLS 握手开销和 sidecar 代理的 CPU 预留。
3.2 Ingress Gateway：集群流量入口
Ingress Gateway 是 Kubernetes 集群的标准流量入口，负责将外部请求按域名和路径规则分发到内部 Service。在升级窗口期间，它是流量中断风险最高的组件。
- 职责边界： 仅处理 7 层路由和 TLS 卸载，不涉及业务逻辑。
- 容量关键指标： 并发连接数、每秒请求数（RPS）、TLS 握手速率、连接池大小。
- 升级风险： 滚动升级期间连接断开、优雅关闭超时、路由规则同步延迟。
- 规划要点： 至少保留 2 个冗余副本，配置 PodDisruptionBudget（PDB）确保最小可用数。
3.3 API Gateway：业务策略执行点
API Gateway 位于 Ingress Gateway 之后，承担业务级流量治理职责。它执行认证、限流、配额、请求转换等策略，是容量规划中 CPU 和内存消耗最密集的网关层。
- 职责边界： 处理业务策略，通常与 Ingress Gateway 串联部署。
- 容量关键指标： 策略执行延迟（P99）、限流计数器内存占用、插件链执行时间、上游连接复用率。
- 升级风险： 策略配置热更新失败、限流状态丢失、插件兼容性问题。
- 规划要点： 预留 20%-30% 的 CPU 余量应对策略计算峰值；使用分布式限流时需考虑 Redis/Etcd 连接池容量。
3.4 Service Mesh Gateway：网格边界代理
Service Mesh Gateway（如 Istio Ingress/Egress Gateway）是服务网格的边界代理，负责网格内外的流量隔离和安全通信。它通常基于 Envoy 实现，具备完整的 mTLS 和访问控制能力。
- 职责边界： 网格入口（Ingress）和出口（Egress）流量控制，支持协议嗅探和自动 mTLS。
- 容量关键指标： mTLS 握手速率、证书轮换频率、Envoy 线程模型下的 worker 数量、连接数/请求数比例。
- 升级风险： Envoy 版本升级导致配置兼容性变化、mTLS 证书过期、Egress 流量中断。
- 规划要点： 根据网格规模调整 Envoy worker 线程数（通常为 2-4）；为 mTLS 握手预留额外 CPU 资源（约 0.1-0.3 core/1000 TPS）。
3.5 三种网关的部署拓扑关系
下图展示了三种网关在典型 K8s 集群中的部署层次和流量路径。理解这个拓扑有助于在升级窗口期间确定网关 Pod 的依赖关系和升级顺序。
3.6 升级窗口中的网关角色差异
在集群升级窗口期间，三种网关的升级策略和容量规划存在显著差异。下表总结了关键区别：
| 升级维度 | Ingress Gateway | API Gateway | Service Mesh Gateway |
|---|---|---|---|
| 滚动升级策略 | maxSurge=1, maxUnavailable=0 | maxSurge=1, maxUnavailable=1（需预热） | maxSurge=0, maxUnavailable=1（严格顺序） |
| 优雅关闭超时 | 30-60s（等待连接耗尽） | 60-120s（等待策略执行完成） | 90-180s（等待 mTLS 握手完成） |
| Pod 副本数下限 | 2（生产环境建议 3+） | 2（考虑限流状态共享） | 2（考虑证书缓存） |
| CPU 预留策略 | 按峰值连接数 × 0.5 core/10K 连接 | 按峰值 RPS × 0.1 core/1000 RPS | 按 mTLS 握手速率 × 0.2 core/1000 TPS |
| 内存预留策略 | 连接池大小 × 16KB + 路由表大小 | 限流计数器 + 插件缓存 + 上游连接池 | Envoy 连接池 + 证书缓存 + 访问日志缓冲区 |
常见误区： 不要将三种网关的容量规划混为一谈。Ingress Gateway 的瓶颈通常在连接数，API Gateway 的瓶颈在 CPU 和内存，Service Mesh Gateway 的瓶颈在 mTLS 握手和 Envoy worker 线程数。升级窗口期间，应分别制定 Pod 副本数和资源预留策略。