深度解析 Istio 流量五虎将：Ingress、Egress、Gateway、ServiceEntry 与 VirtualService
文章目录
- 一、 角色定位：谁是实体？谁是配置？
- 二、 核心关联：流量是如何流动的？
- 场景 1：南北流量——外部用户访问内部服务（Ingress）
- 场景 2：东西/南北流量——内部服务访问外部 API（Egress）
- 三、 深度对比：ServiceEntry vs Gateway vs VirtualService
- 1. Gateway 资源 vs VirtualService
- 2. ServiceEntry vs VirtualService
- 四、 实战场景：我该什么时候用谁？
- 五、 总结：理清思路的架构图
在 Kubernetes 的原生世界里，我们习惯了 Ingress 和 Service。但当你踏入 Istio 服务网格（Service Mesh）的大门时，你会发现流量控制变得极其细腻但也更复杂。
很多初学者会被 Ingress Gateway、Egress Gateway、Gateway 资源、ServiceEntry 和 VirtualService 这几个概念绕晕。本文将通过“围城”理论，带你剥开这些概念的层层外壳。
一、 角色定位：谁是实体？谁是配置？
首先，我们要区分“物理实体”和“逻辑配置”。
物理实体（Envoy 代理）：
- Ingress Gateway：运行在网格边缘的 Envoy 代理 Pod。它是流量进入网格的“城门”。
- Egress Gateway：运行在网格边缘的 Envoy 代理 Pod。它是流量离开网格的“检查站”。
- 注：它们本质上都是 Deployment + Service (LoadBalancer)。
逻辑配置（CRD 资源）：
- Gateway (资源)：定义城门的“规格”。比如：开哪个端口？用什么协议（HTTP/HTTPS）？证书是什么？
- ServiceEntry：外来人口的“登记表”。让网格认识那些不在 Kubernetes 里的服务。
- VirtualService：流量的“交警”。决定流量匹配到规则后，具体甩给哪个后端服务。
二、 核心关联：流量是如何流动的？
我们可以通过两个经典的流量场景，看清它们如何“接力”。
场景 1：南北流量——外部用户访问内部服务（Ingress）
这是流量“进城”的过程。
- 用户访问
api.example.com。 - 流量命中Ingress Gateway Pod（物理实体）。
- Gateway 资源（配置）发挥作用：它被绑定到那个 Pod 上，配置了 Envoy 监听 443 端口并加载了 SSL 证书。
- VirtualService（配置）发挥作用：它关联了上面的 Gateway 资源，查看路径
/v1。 - VirtualService指向内部的 KubernetesService。
- 流量最终到达后端 Pod。
关系口诀：Gateway 开门，VirtualService 导航。
场景 2：东西/南北流量——内部服务访问外部 API（Egress）
这是流量“出城”的过程，也是最容易混淆的部分。
- 内部 Pod发起
curl https://google.com。 - ServiceEntry（配置）发挥作用：如果网格开启了“严格注册模式”，必须有 ServiceEntry，Istio 才知道
google.com是谁。 - VirtualService（配置）发挥作用：它可以定义——“凡是去往 google.com 的流量，必须先转发到 Egress Gateway Pod”。
- Egress Gateway Pod（物理实体）接收流量。
- Gateway 资源（绑定在 Egress 上）发挥作用：定义出口网关监听的协议和端口。
- 流量离开网格，到达真正的Google 服务器。
关系口诀：ServiceEntry 给身份，Egress Gateway 做审计。
三、 深度对比：ServiceEntry vs Gateway vs VirtualService
为了进阶理解，我们需要剖析它们的细微差别：
1. Gateway 资源 vs VirtualService
- Gateway关注的是L4-L6（网络层/传输层）：端口、协议、SNI、TLS 证书。它不关心具体的 URL 路径。
- VirtualService关注的是L7（应用层）：HTTP 路由、Header 匹配、重试、超时、流量比例切分。
- 联系：当流量从外部进来时，VirtualService 必须通过
gateways字段引用 Gateway 资源。
2. ServiceEntry vs VirtualService
- ServiceEntry解决了“有没有”的问题：它将外部主机名（如
mysql.aliyun.com）添加到 Istio 内部的服务发现中。 - VirtualService解决了“怎么走”的问题：你可以为 ServiceEntry 定义路由规则。例如，访问外部数据库时，如果失败了自动重试 3 次。
四、 实战场景：我该什么时候用谁？
| 需求场景 | 使用资源组合 |
|---|---|
| 暴露一个 HTTPS 网站给外网用户 | Ingress Gateway + Gateway(资源) + VirtualService |
| 将流量在 v1 和 v2 版本间做 90/10 灰度 | VirtualService + DestinationRule |
| 内部 Pod 需要调用公司老旧系统的物理机数据库 | ServiceEntry |
| 强制所有上外网的流量经过一个固定的安全出口进行审计 | ServiceEntry + VirtualService + Egress Gateway + Gateway(资源) |
| 内网服务 A 调用服务 B 时，响应超过 2s 就超时 | VirtualService |
五、 总结：理清思路的架构图
- Ingress Gateway= 城门。
- Egress Gateway= 边境检查站。
- Gateway 资源= 城门的准入手册（端口、TLS）。
- ServiceEntry= 驻外大使馆名单（让城里人认识外面的人）。
- VirtualService= 城市里的交警和路牌（负责所有的路由决策）。
专家提示：
在生产环境中，尽量保持VirtualService的简洁。如果是南北流量，VS 应该在istio-system或特定的入口命名空间管理；如果是东西流量，VS 应该随应用一起部署在同一个命名空间下。
通过这种“实体”与“配置”的分离，Istio 实现了极高的灵活性：你可以随时更换物理网关（扩容或升级），而无需修改复杂的业务路由逻辑（VirtualService）。