2. Istio 架构回顾：控制面与数据面组件，Envoy Sidecar 注入原理
在深入探讨升级窗口的准入控制策略之前，必须牢固掌握 Istio 的核心架构。本章将系统回顾控制面与数据面的关键组件，并详细剖析 Envoy Sidecar 的注入原理。理解这些基础是后续故障排查的基石。
2.1 控制面与数据面组件总览
Istio 采用经典的服务网格架构，分为控制面（Control Plane）和数据面（Data Plane）。控制面负责管理和配置，数据面负责处理实际的网络流量。
| 层面 | 核心组件 | 主要职责 | 部署形态 |
|---|---|---|---|
| 控制面 | istiod |
统一管理 Pilot、Citadel、Galley 功能：服务发现、流量规则下发、证书签发、配置验证与分发。 | Deployment（通常 1-2 副本） |
| 数据面 | Envoy Proxy |
以 Sidecar 模式注入到每个 Pod，拦截所有进出流量，执行路由、负载均衡、熔断、遥测等策略。 | Sidecar 容器（每个业务 Pod 一个） |
| 数据面 | Ingress/Egress Gateway |
网格边缘的 Envoy 代理，管理南北向流量（入口/出口流量）。 | Deployment + Service（LoadBalancer/NodePort） |
关键认知： 升级过程中，控制面
istiod 的版本必须与数据面 Envoy 的版本保持兼容。升级窗口的准入控制策略核心目标之一，就是防止不兼容的 Sidecar 版本被注入到集群中。
2.2 控制面核心组件：istiod
在 Istio 1.5 版本之后，控制面组件被整合为单一的 istiod 二进制文件。它集成了三个关键功能模块：
- Pilot（服务发现与流量管理）：负责从平台（如 Kubernetes）获取服务注册信息，并将用户定义的流量规则（VirtualService、DestinationRule）转换为 Envoy 可理解的配置（xDS API）。
- Citadel（安全与证书管理）：负责管理密钥和证书，为每个工作负载提供强大的身份标识（SPIFFE），并自动进行 mTLS 证书的签发与轮换。
- Galley（配置验证与分发）：负责验证用户提交的 Istio 资源配置（如 VirtualService）的合法性，并将验证后的配置分发给 Pilot 和其他组件。
2.3 数据面核心组件：Envoy Proxy
Envoy 是一个高性能、开源的 L7 代理和通信总线。在 Istio 中，它作为 Sidecar 容器与业务容器共存于同一个 Pod 中。
Envoy 的核心能力包括：
- 流量拦截：通过 iptables 规则透明地劫持 Pod 内所有入站和出站流量。
- 协议支持：原生支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议。
- 高级负载均衡：支持加权轮询、最少请求、一致性哈希等算法。
- 熔断与重试：提供连接池限制、异常点检测、超时和重试策略。
- 可观测性：自动生成详细的访问日志、指标（Prometheus）和分布式追踪（Jaeger/Zipkin）。
2.4 Envoy Sidecar 注入原理
Envoy Sidecar 的注入是 Istio 网格化的第一步。Istio 支持两种注入方式：手动注入和自动注入。在生产环境中，自动注入是主流方式。
2.4.1 自动注入流程（基于 MutatingWebhook）
自动注入依赖于 Kubernetes 的 MutatingAdmissionWebhook 机制。当用户通过 kubectl apply 创建 Pod 时，Kubernetes API Server 会调用 Istio 注册的 Webhook 服务，在 Pod 被持久化到 etcd 之前对其进行修改。
注入流程步骤：
- Pod 创建请求：用户提交 Deployment/StatefulSet 等资源，触发 Pod 创建。
- Webhook 拦截：Kubernetes API Server 将 Pod 创建请求发送给
istiod的 Webhook 端点。 - 策略判断：
istiod检查 Pod 所在的 Namespace 是否启用了自动注入（Label:istio-injection=enabled），以及 Pod 自身是否有排除注入的注解。 - 配置生成：如果满足注入条件，
istiod根据全局配置（MeshConfig）和 Pod 注解，动态生成 Envoy Sidecar 容器的配置。 - Patch 返回：
istiod返回一个 JSON Patch 给 API Server，其中包含要添加的initContainers（istio-init）和containers（istio-proxy）。 - Pod 创建：API Server 应用 Patch，将修改后的 Pod 定义持久化到 etcd，并调度到工作节点上。
2.4.2 注入的容器详解
自动注入会在每个 Pod 中添加两个额外的容器：
| 容器名称 | 类型 | 镜像 | 核心作用 |
|---|---|---|---|
istio-init |
Init 容器 | proxyv2 |
设置 iptables 规则，将 Pod 的入站和出站流量透明地重定向到 Envoy 代理。该容器在业务容器启动前运行完毕即退出。 |
istio-proxy |
Sidecar 容器 | proxyv2 |
运行 Envoy 代理进程，负责实际的流量转发、策略执行和遥测数据收集。它与业务容器共享网络命名空间和存储卷。 |
升级窗口风险点： 在升级过程中，如果
istiod 的版本与 proxyv2 镜像的版本不匹配，注入的 Sidecar 可能无法从控制面获取正确的配置，导致流量中断。准入控制策略需要校验注入的 proxyv2 镜像版本是否与当前控制面兼容。
2.5 注入策略与配置来源
Sidecar 注入的决策不仅依赖于 Namespace 标签，还受到多种配置的影响。理解这些配置的优先级对于故障排查至关重要。
- Namespace 级别：通过 Label
istio-injection=enabled或istio.io/rev=canary（用于金丝雀升级）启用。 - Pod 级别：通过 Annotation
sidecar.istio.io/inject: "true"或"false"覆盖 Namespace 级别的设置。 - 全局配置：
MeshConfig中的defaultConfig定义了默认的注入参数（如资源限制、日志级别）。 - Sidecar 资源：用户可以通过创建
SidecarCRD 资源，精细控制特定工作负载的入站和出站流量捕获范围。
2.6 升级窗口中的关键考量
在升级 Istio 控制面时，Sidecar 注入的准入控制策略需要特别关注以下几点：
- 版本兼容性：确保新版本的
istiod能够兼容旧版本的 Envoy Sidecar。通常 Istio 官方支持 N-1 版本的兼容性。 - 金丝雀升级：使用
istio.io/rev=canary标签，可以控制部分 Namespace 或 Pod 使用新版本的控制面，实现灰度升级。 - 注入策略冻结：在升级窗口期间，建议暂时冻结自动注入策略的变更，避免因配置不一致导致新创建的 Pod 无法正常加入网格。
- 回滚方案：准入控制策略应能快速回滚到旧版本的注入配置，以便在升级失败时恢复服务。
实战提示： 在升级前，使用
istioctl x precheck 命令可以预先检查集群中是否存在可能导致升级失败的配置问题，包括 Sidecar 注入相关的资源冲突。