📚 课程目录第2章 Istio架构回顾

2. Istio 架构回顾：控制平面与数据平面、Pilot/Proxy 设计、Sidecar 注入原理概述

在深入升级后的 Sidecar 注入策略重置之前，必须重新梳理 Istio 的核心架构。理解控制平面与数据平面的职责边界、Pilot 与 Envoy 的交互机制，以及 Sidecar 注入的完整链路，是诊断和修复注入策略问题的前提。

2.1 控制平面与数据平面

Istio 采用经典的 控制平面 / 数据平面 分离架构，两者通过 xDS 协议通信。

维度	控制平面 (istiod)	数据平面 (Envoy Proxy)
核心职责	服务发现、配置管理、证书签发、策略下发	流量拦截、路由转发、负载均衡、策略执行、遥测采集
主要组件	Pilot、Galley、Citadel（已合并为 istiod）	Envoy 进程（以 Sidecar 或 Gateway 形式运行）
通信协议	gRPC 流式推送 xDS（LDS/RDS/CDS/EDS/SDS）	监听 xDS 更新，动态重载配置
故障影响范围	配置无法更新，已有连接不受影响	流量中断或路由错误

  升级关键点： 控制平面 istiod 在升级后可能修改 xDS 资源命名规则或 Sidecar 配置模板，导致数据平面 Envoy 无法正确接收或解析配置，表现为注入策略“重置”或失效。

2.2 Pilot / Proxy 设计

Pilot 是控制平面中负责服务发现和流量管理的核心组件。在 Istio 1.5+ 版本中，Pilot 已合并入 istiod 单体进程，但其设计理念和接口协议保持不变。

Pilot 职责：
- 对接平台服务注册中心（Kubernetes API Server、Consul 等），构建统一服务模型。
- 将 Istio 的 VirtualService、DestinationRule 等 CRD 资源转换为 Envoy 可识别的 xDS 配置。
- 通过 gRPC 流式推送，将配置变更实时下发到所有数据平面 Envoy。
Envoy Proxy 职责：
- 作为 Sidecar 或 Gateway 运行，监听 xDS 端点获取配置。
- 执行 L4/L7 流量拦截、路由、熔断、重试、故障注入等策略。
- 上报访问日志、指标和链路追踪数据。

升级影响： 升级后，Pilot 可能启用新的 xDS 版本（如从 v2 切换到 v3），或修改 Envoy 引导配置（bootstrap）中的节点元数据。如果 Sidecar 注入策略未同步更新，Envoy 可能因元数据不匹配而拒绝连接 istiod。

2.3 Sidecar 注入原理概述

Sidecar 注入是 Istio 将 Envoy 代理自动附加到 Pod 的机制。注入方式分为 手动注入 和 自动注入，生产环境通常使用基于 MutatingWebhookConfiguration 的自动注入。

2.3.1 自动注入流程

Webhook 注册： Istio 安装时在集群中注册 MutatingWebhookConfiguration，监听 Pod CREATE 事件。
请求拦截： 当用户创建 Pod 时，API Server 将 Pod 的 AdmissionReview 请求发送到 istiod 的 Webhook 端点。
策略匹配： istiod 根据命名空间标签（istio-injection: enabled）或 Sidecar CRD 资源判断是否需要注入。
Patch 生成： 如果需要注入，istiod 生成 JSON Patch，包含：
- 初始化容器 istio-init（用于 iptables 流量重定向）。
- Sidecar 容器 istio-proxy（Envoy 进程）。
- 共享卷挂载（如 istio-、istio-certs）。
Pod 创建： API Server 应用 Patch 后创建包含 Sidecar 的 Pod。

升级风险： 升级后，Webhook 配置可能被覆盖或更新，导致注入策略（如命名空间标签、Sidecar CRD 选择器）与预期不符。此外，istiod 的注入模板可能变更，新注入的 Sidecar 版本与控制平面不匹配，引发兼容性问题。

2.4 注入策略的关键配置点

升级后，以下配置点最容易发生“重置”或漂移，需要重点检查：

命名空间标签： istio-injection: enabled 或 istio.io/rev: <revision> 是否被移除或修改。
MutatingWebhookConfiguration： Webhook 的 failurePolicy、namespaceSelector、objectSelector 是否与升级前一致。
Sidecar CRD 资源： 自定义的 Sidecar 资源是否被升级流程覆盖或删除。
istiod 注入模板： istio-sidecar-injector ConfigMap 中的模板内容是否变更，特别是 initContainers 和 containers 的镜像版本、资源限制、环境变量。

最佳实践： 在升级前，使用 kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml 和 kubectl get configmap -n istio-system istio-sidecar-injector -o yaml 备份当前配置。升级后对比差异，确保注入策略未被意外重置。