3. Envoy 部署模式：Sidecar 模式、边缘代理模式（Front Proxy）、网关模式（Ingress Gateway）对比与适用场景
Envoy 作为云原生数据面的核心组件，其部署模式直接决定了集群的流量模型、安全边界和运维复杂度。本章深入对比三种主流部署模式：Sidecar 模式、边缘代理模式（Front Proxy） 和 网关模式（Ingress Gateway），帮助你在不同业务场景下做出最优选择。
3.1 三种部署模式概述
Envoy 的部署模式本质上是对“代理与工作负载之间距离”和“代理职责范围”的权衡。下表从核心特征维度进行对比：
| 维度 | Sidecar 模式 | 边缘代理模式（Front Proxy） | 网关模式（Ingress Gateway） |
|---|---|---|---|
| 部署位置 | 与每个应用容器同 Pod | 集群边缘，独立部署 | 集群边缘，独立部署 |
| 代理粒度 | 每个 Pod 一个代理 | 全局共享一组代理 | 全局共享一组代理 |
| 流量路径 | 进出 Pod 的所有流量 | 进入集群的外部流量 | 进入集群的外部流量 |
| 配置复杂度 | 高（实例数多） | 中 | 低（标准化） |
| 资源开销 | 高（每 Pod 额外资源） | 中（按需扩展） | 中（按需扩展） |
| 安全隔离 | 最强（进程级隔离） | 中（共享代理） | 中（共享代理） |
| 典型场景 | 服务网格、mTLS、可观测性 | API 网关、南北向流量统一入口 | Kubernetes Ingress 替代、多租户入口 |
3.2 Sidecar 模式
Sidecar 模式是 Istio 服务网格的默认部署方式。Envoy 作为 sidecar 容器与业务容器共享同一个 Pod，拦截所有进出 Pod 的流量。
核心特征：每个工作负载实例拥有专属代理，实现细粒度的流量控制和零信任安全。
适用场景
- 服务间通信治理：需要对每个服务实例进行细粒度流量控制（超时、重试、熔断）。
- 零信任安全：要求所有服务间通信强制 mTLS 加密，实现身份认证和授权。
- 全链路可观测性：需要采集每个请求的分布式追踪、日志和指标。
- 多语言异构系统：业务应用无法或不愿集成网络库，由 Sidecar 透明接管网络。
注意：Sidecar 模式会显著增加集群中的 Pod 总数和资源开销（每个 Sidecar 约 50-200MB 内存）。在超大规模集群（>5000 Pod）中，需评估控制面 xDS 推送压力和资源预算。
3.3 边缘代理模式（Front Proxy）
边缘代理模式在集群入口处部署一组独立的 Envoy 实例，作为所有外部流量的统一接入点。它不与应用容器绑定，而是独立运行在集群边缘节点上。
适用场景
- 南北向流量统一入口：所有外部请求先经过 Front Proxy，再进行路由分发。
- API 网关：需要统一的认证、限流、日志、监控策略。
- 多协议接入：同时支持 HTTP/1.1、HTTP/2、gRPC、WebSocket 等协议。
- 流量镜像与灰度：在入口层实现金丝雀发布、A/B 测试。
最佳实践：Front Proxy 通常部署为 Deployment + Service（Type: LoadBalancer），并配置 HPA 基于 CPU/连接数自动扩缩。建议至少运行 2 个副本保证高可用。
3.4 网关模式（Ingress Gateway）
Ingress Gateway 是 Istio 生态中专门为 Kubernetes Ingress 场景设计的部署模式。它本质上是 Front Proxy 的标准化实现，但深度集成 Istio 控制面，支持更丰富的路由规则和安全管理。
| 对比维度 | Front Proxy（通用） | Ingress Gateway（Istio） |
|---|---|---|
| 配置方式 | 手动编写 Envoy 配置或使用控制面 | 通过 Kubernetes CRD（Gateway/ VirtualService） |
| 多租户隔离 | 需自行实现 | 原生支持（通过 Gateway 资源隔离） |
| TLS 管理 | 手动管理证书 | 自动 mTLS + SDS 证书分发 |
| 可观测性 | 需额外配置 | 与 Istio 遥测系统无缝集成 |
| 社区生态 | 通用 Envoy 生态 | Istio + Kubernetes 原生生态 |
适用场景
- Kubernetes 原生入口：替代 Nginx Ingress Controller，获得更丰富的 L7 路由能力。
- 多租户集群：每个租户通过独立的 Gateway CRD 定义入口规则，实现配置隔离。
- 自动化 TLS：结合 cert-manager 和 SDS，实现证书自动签发和轮换。
- 混合协议网关：同时暴露 HTTP API 和 gRPC 服务，通过协议嗅探自动路由。
3.5 模式选择决策树
在实际架构设计中，可以根据以下条件快速选择部署模式：
- 是否需要服务间流量治理？ → 是 → Sidecar 模式
- 是否需要统一的外部流量入口？ → 是 → 进入下一步
- 是否使用 Istio 服务网格？ → 是 → Ingress Gateway 模式
- 是否需要独立于网格的通用代理？ → 是 → Front Proxy 模式
生产建议：大多数云原生集群采用“Sidecar + Ingress Gateway”组合模式。Sidecar 负责东西向流量治理，Ingress Gateway 负责南北向流量接入，两者通过 Istio 控制面统一管理，实现全栈流量治理。
3.6 多租户隔离中的部署选择
在多租户场景下，三种模式对隔离的支持程度不同：
| 隔离需求 | Sidecar 模式 | Front Proxy 模式 | Ingress Gateway 模式 |
|---|---|---|---|
| 网络隔离 | Pod 级（最强） | 共享代理（弱） | 共享代理 + CRD 隔离（中） |
| 配置隔离 | 每个 Sidecar 独立配置 | 需手动分区 | 通过 Gateway/VirtualService 命名空间隔离 |
| 性能隔离 | 天然隔离（独立资源） | 共享资源，需限流 | 共享资源，支持租户级限流 |
| 运维复杂度 | 高（实例多） | 中 | 低（标准化 CRD） |
对于要求严格租户隔离的场景（如金融、SaaS 平台），推荐 Sidecar + Ingress Gateway 组合：Sidecar 保证服务间通信的租户隔离，Ingress Gateway 通过 CRD 实现入口流量的租户路由隔离。