2. Istio 基础架构：控制面与数据面组件详解、Envoy 代理原理、Sidecar 注入机制

2.1 Istio 整体架构概览

Istio 服务网格采用经典的控制面/数据面分离架构。数据面由一组与业务容器同 Pod 运行的 Envoy 代理组成，负责拦截并处理所有进出 Pod 的流量；控制面则统一管理代理的配置下发、证书签发与访问策略。

核心设计原则： 控制面不接触业务流量，数据面不参与策略决策。两者通过 xDS 协议（Discovery Service）进行配置同步，实现流量的透明劫持与精细化治理。
Istio 控制面与数据面整体架构 Istio 控制面与数据面整体架构 控制面 (Control Plane) — istiod Pilot (xDS 下发) Citadel (证书签发) Galley (配置校验) Webhook 数据面 (Data Plane) — Envoy Sidecar 代理 Pod A 业务容器 Envoy iptables 规则拦截流量 Pod B 业务容器 Envoy iptables 规则拦截流量 Pod C 业务容器 Envoy iptables 规则拦截流量 说明：控制面通过 xDS 协议向所有 Envoy 下发监听器、路由、集群和端点配置；Envoy 之间直接转发业务流量，不经过控制面。

2.2 控制面核心组件详解

Istio 1.5+ 版本将原有多个独立组件（Pilot、Citadel、Galley、Sidecar Injector）合并为单一的 istiod 进程，简化了部署与运维。下表列出各模块的核心职责：

组件 核心职责 关键协议/接口
Pilot 服务发现、流量管理规则转换、通过 xDS 向 Envoy 下发配置 xDS (LDS/RDS/CDS/EDS)
Citadel 证书签发与管理、mTLS 密钥分发、身份认证 SPIFFE、Kubernetes CSR
Galley 配置验证、格式转换、状态报告 MCP (Mesh Configuration Protocol)
Sidecar Injector 基于 Webhook 自动注入 Envoy Sidecar 容器 MutatingAdmissionWebhook
运维提示： 在回滚护栏场景中，Pilot 的 xDS 配置下发速度直接影响灰度发布和回滚的生效时间。建议监控 pilot_xds_push_time 和 pilot_proxy_convergence_time 指标，确保配置收敛延迟在 5s 以内。

2.3 数据面核心：Envoy 代理原理

Envoy 是 Istio 数据面的核心代理，以 Sidecar 模式与业务容器同 Pod 运行。它通过 L4/L7 过滤器链 实现流量拦截、协议解析、负载均衡和可观测性。

2.3.1 Envoy 核心架构

  • Listener（监听器）：绑定 Pod 网络接口，接收入站和出站流量。Istio 默认创建 virtualInbound 和 virtualOutbound 两个监听器。
  • Filter Chain（过滤器链）：按顺序处理流量，包括 TLS 终止、HTTP 协议解析、RBAC 鉴权、故障注入等。
  • Cluster（集群）：定义上游服务端点集合，支持主动健康检查、负载均衡策略（轮询、最少请求、一致性哈希）。
  • Endpoint（端点）：具体的 Pod IP:Port，由 Pilot 通过 EDS 动态下发。
Envoy 代理内部处理流程 Envoy 代理内部处理流程 入站流量 Listener virtualInbound Filter Chain TLS → HTTP → RBAC Cluster 负载均衡策略 出站流量 Listener virtualOutbound Filter Chain 路由 → 重试 → 限流 Cluster EDS 动态端点 上游端点 (Upstream Endpoints) — 目标 Pod IP:Port xDS 配置下发：Pilot 通过 LDS/RDS/CDS/EDS 动态更新 Listener、路由、Cluster 和 Endpoint

2.3.2 Envoy 关键特性

特性 说明 回滚场景价值
热重启 不中断现有连接，平滑升级配置或二进制 回滚时无需重启 Pod，降低影响面
动态转发 支持按权重、Header、URI 动态路由 灰度发布中精确控制流量比例
故障注入 可注入延迟、中断等故障用于混沌测试 回滚前验证新版本稳定性
可观测性 内置 Metrics、Tracing、Access Log 回滚前后对比流量和错误率

2.4 Sidecar 注入机制

Istio 通过 MutatingAdmissionWebhook 实现 Sidecar 自动注入。当 Pod 创建请求到达 API Server 时，Webhook 拦截请求并修改 Pod Spec，注入 Envoy 容器和 istio-init 初始化容器。

2.4.1 注入流程

  1. Webhook 注册：istiod 在启动时向 API Server 注册 MutatingWebhookConfiguration，监听 namespace 标签为 istio-injection=enabled 的 Pod 创建事件。
  2. 请求拦截：用户执行 kubectl apply 创建 Pod，API Server 将 Pod 的 AdmissionReview 请求发送给 istiod 的 Webhook 端点。
  3. 配置模板渲染：istiod 根据 istio-sidecar-injector ConfigMap 中的模板，结合 Pod 注解（如 sidecar.istio.io/inject: "true"）渲染注入内容。
  4. Patch 返回：istiod 返回 JSON Patch，在 Pod Spec 中添加：
    • istio-init 容器：设置 iptables 规则，将入站和出站流量重定向到 Envoy。
    • istio-proxy 容器：运行 Envoy 代理，挂载证书和配置卷。
  5. Pod 创建：API Server 应用 Patch 后创建 Pod，Sidecar 与业务容器同时启动。
回滚护栏关键点： Sidecar 注入依赖 Webhook 的可用性。如果 istiod 故障或 Webhook 超时，新 Pod 将无法创建。建议配置 failurePolicy: Fail 并设置合理的 timeoutSeconds: 10，同时监控 sidecar_injection_requests_total 和 sidecar_injection_failure_total 指标。

2.4.2 注入后的 Pod 结构

注入完成后，Pod 内包含三个容器：

容器名称 镜像 职责
业务容器 用户自定义 处理业务逻辑，流量被 iptables 透明劫持
istio-init proxyv2 初始化 iptables 规则，运行后退出（Init 容器）
istio-proxy proxyv2 运行 Envoy，处理所有进出流量，上报指标

2.4.3 手动注入与验证

在回滚护栏场景中，有时需要手动注入 Sidecar 以绕过 Webhook 故障：

# 手动注入 Sidecar（不依赖 Webhook）
istioctl kube-inject -f deployment.yaml | kubectl apply -f -

# 验证注入是否成功
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.containers[*].name}'
# 输出示例：business-container istio-proxy

# 查看 iptables 规则（需进入 istio-proxy 容器）
kubectl exec <pod-name> -c istio-proxy -- iptables-save | grep ISTIO
最佳实践： 在回滚操作前，建议通过 istioctl proxy-status 确认所有 Envoy 代理已同步最新配置。如果出现 SYNCED 状态之外的代理，应先排查配置下发链路再执行回滚。

2.5 本章小结

  • 控制面：istiod 统一管理 Pilot（xDS 下发）、Citadel（证书签发）、Galley（配置校验）和 Webhook（Sidecar 注入）。
  • 数据面：Envoy 通过 Listener → Filter Chain → Cluster → Endpoint 的流水线处理流量，支持动态配置和热重启。
  • Sidecar 注入：基于 MutatingAdmissionWebhook 自动注入 istio-init 和 istio-proxy 容器，实现流量的透明劫持和治理。
  • 回滚关联：xDS 配置收敛速度、Webhook 可用性、Envoy 热重启能力直接影响回滚操作的时效性和安全性。
← 上一章 📖 返回目录 下一章 →