3、Istio 核心概念：数据平面与控制平面，Envoy 代理，Istiod 组件，流量管理模型
好，咱们今天聊聊 Istio 的核心概念。说实话，刚接触 Service Mesh 那会儿，我也被一堆术语搞得头晕。什么数据平面、控制平面，听着就高大上。但说白了，它就是一套帮你管理微服务通信的「交通系统」。
我个人习惯把 Istio 拆成两大部分来看：一个是干活的，一个是管事的。干活的叫数据平面，管事的叫控制平面。咱们一个一个说。
数据平面 vs 控制平面
数据平面，其实就是一组智能代理。在 Istio 里，这些代理就是 Envoy。它们以 Sidecar 的形式跟你的业务容器跑在同一个 Pod 里。每个请求进来，都得先经过 Envoy 再转发到业务容器。你想想看，这样一来，所有流量都在 Envoy 的掌控之下。
我在项目中遇到过一个问题：业务团队抱怨延迟增加了。排查了半天，发现是 Envoy 的默认配置没调优。嗯，这里要注意，Envoy 虽然强大，但默认配置不一定适合你的场景。
控制平面，就是负责下发指令的大脑。在 Istio 1.5 之后，控制平面被整合成了一个组件——Istiod。它负责管理证书、下发配置、收集指标。说白了，你写的那些 YAML 文件，最终都是交给 Istiod 去解析，然后转换成 Envoy 能理解的配置。
核心关系：
- 数据平面：执行策略，处理流量
- 控制平面：制定策略，下发配置
- 两者通过 xDS 协议通信
Envoy 代理：数据平面的核心
Envoy 是 Istio 数据平面的默认代理。它不是 Istio 独有的，但 Istio 把它用到了极致。Envoy 是用 C++ 写的，性能很好。它支持热重启，动态配置，这些特性在云原生环境里特别实用。
Envoy 的核心能力包括：
- 服务发现：自动发现上游服务实例
- 负载均衡：支持多种算法，比如轮询、最少连接
- 健康检查：主动探测后端是否存活
- 熔断：防止故障扩散
- 指标收集：生成详细的请求指标
我的经验：Envoy 的日志默认是关闭的。如果你在调试阶段，记得开启访问日志。我曾经因为没开日志，排查一个 503 错误花了整整一天。命令很简单：在 Istio 配置里设置 accessLogFile: /dev/stdout。
Istiod：控制平面的核心
Istiod 是 Istio 1.5 之后引入的「大一统」组件。它把原来分散的 Pilot、Mixer、Citadel 等功能全部整合到了一起。为什么要这么做？说白了，就是为了简化部署和运维。
Istiod 主要干这几件事：
| 功能模块 | 职责描述 |
|---|---|
| Pilot | 服务发现、流量管理配置下发 |
| Citadel | 证书签发、身份认证 |
| Galley | 配置验证、处理 |
| Sidecar Injector | 自动注入 Envoy Sidecar |
你想想看，以前要维护三个组件，现在一个 Istiod 全搞定。运维成本降低了不少。我记得刚升级到 1.5 的时候，团队里还有人担心稳定性。实际跑下来，发现比之前更稳了。
流量管理模型
Istio 的流量管理模型，说白了就是通过 CRD（自定义资源）来定义流量规则。你不需要改代码，只需要写 YAML 文件。这对开发团队来说，简直是福音。
核心的流量管理资源有这几个：
- VirtualService：定义路由规则，比如根据 header 分流
- DestinationRule：定义目标策略，比如负载均衡、连接池
- Gateway：管理入口流量，类似 Ingress
- ServiceEntry：注册外部服务到网格内
- Sidecar：控制 Sidecar 的监听端口和转发规则
举个实际例子。假设你要做金丝雀发布，把 10% 的流量引到新版本：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-service
spec:
hosts:
- my-service
http:
- match:
- headers:
version:
exact: v2
route:
- destination:
host: my-service
subset: v2
- route:
- destination:
host: my-service
subset: v1
weight: 90
- destination:
host: my-service
subset: v2
weight: 10避坑指南：我曾经在配置 VirtualService 时，忘了写 subset 对应的 DestinationRule。结果流量全乱了，新版本一个请求都没收到。记住：VirtualService 和 DestinationRule 是配合使用的，缺一不可。
流量管理的核心逻辑其实很简单：
- 请求到达 Sidecar（Envoy）
- Envoy 根据 VirtualService 规则匹配路由
- 根据 DestinationRule 确定目标策略
- 转发到目标服务实例
整个过程对业务代码完全透明。你想想看，这有多爽？开发只管写业务逻辑，运维只管配流量规则。各司其职，互不干扰。
嗯，这一章的内容就到这里。记住：数据平面是 Envoy，控制平面是 Istiod，流量管理靠 CRD。这三个点抓住了，Istio 的大门就算敲开了。
公众号:蓝海资料掘金营，微信deep3321