2. 服务网格核心概念：Sidecar代理、数据平面与控制平面、Istio架构组件详解

在进入金丝雀发布实战之前，必须透彻理解服务网格的三大基石：Sidecar 代理、数据平面与控制平面的分离架构，以及 Istio 的核心组件。这些概念是后续流量劫持、路由规则下发、TLS 证书管理的理论基础。

2.1 Sidecar 代理：流量拦截的“交通警察”

Sidecar 是服务网格中最小的执行单元。它是一个与业务容器同 Pod 部署的轻量级代理（通常是 Envoy），负责拦截该 Pod 所有进出流量。

Sidecar 流量劫持原理

1. 入站拦截： iptables 规则将发往 Pod IP 的请求重定向到 Sidecar 的 15006 端口。
2. 出站拦截： 业务容器发出的请求被重定向到 Sidecar 的 15001 端口。
3. 策略执行： Sidecar 根据控制平面下发的 VirtualService/DestinationRule 决定转发目标。
4. 指标上报： 每个请求完成后，Sidecar 将延迟、状态码、标签等数据上报给控制平面。

2.2 数据平面与控制平面：分离架构的智慧

服务网格将流量管理和安全策略从业务进程中剥离，形成两个独立的平面：

2.3 Istio 核心组件详解

Istio 是目前最成熟的服务网格实现。其控制平面由四个核心组件构成，每个组件承担不可替代的职责。

2.3.1 Pilot：流量规则的“翻译官”

• 功能： 将 VirtualService、DestinationRule 等 CRD 转换为 Envoy 可理解的 xDS 协议配置。
• 关键接口： 通过 gRPC 流式推送 LDS（监听器发现）、RDS（路由发现）、CDS（集群发现）、EDS（端点发现）给所有 Sidecar。
• 金丝雀关联： 修改 VirtualService 的权重后，Pilot 在几秒内将新规则推送到所有相关 Sidecar，触发流量切换。

2.3.2 Mixer：策略与遥测的“中央处理器”

• 功能： 前置检查（Check）和后置报告（Report）。
• Check： 每次请求前询问 Mixer 是否允许通过（白名单、限速、ACL）。
• Report： 请求结束后将日志、指标、追踪信息上报给 Mixer，再由 Mixer 转发给 Prometheus、Grafana、Jaeger 等后端。
• 注意： 新版本 Istio 已默认关闭 Mixer，改用 Envoy 原生 Wasm 扩展和 Telemetry v2，但理解 Mixer 有助于阅读旧版配置。

2.3.3 Citadel：安全证书的“发证机关”

• 功能： 自动生成、分发、轮换 TLS 证书，实现服务间 mTLS 加密。
• 工作流程： Citadel 监听 ServiceAccount 创建 → 为每个 ServiceAccount 签发 SPIFFE 格式证书 → 通过 Secret 挂载到 Pod → Sidecar 自动加载证书。
• 金丝雀安全： 金丝雀版本自动继承相同的 ServiceAccount 和证书，无需额外配置即可与其他服务建立加密通信。

2.4 组件协作流程：一次金丝雀请求的生命周期

以金丝雀发布场景为例，梳理各组件如何协作：

1. 运维人员 通过 kubectl apply 更新 VirtualService，将 v2 权重设为 10%。
2. Pilot 监听到 CRD 变更，生成新的 Envoy 路由配置（RDS），通过 gRPC 流推送到所有相关 Sidecar。
3. Sidecar 收到配置后，更新本地路由表。后续请求到达时，按 90:10 比例分发到 v1 和 v2。
4. Citadel 确保 v2 Pod 的 Sidecar 拥有合法证书，与其他服务建立 mTLS 连接。
5. Mixer（如启用） 接收 Sidecar 上报的请求指标，标记版本标签（version=v2），供监控系统区分金丝雀流量。