2. Istio 架构回顾：控制面与数据面组件

在深入容量水位与 OPA 策略协同巡检之前，必须重新梳理 Istio 的经典架构。Istio 1.5+ 版本将多个控制面组件整合为单一的 istiod，但理解其原始组件职责（Pilot、Mixer、Citadel）对于诊断容量瓶颈和策略执行路径仍然至关重要。

2.1 整体架构分层

Istio 服务网格分为两个平面：

• 数据面（Data Plane）：由与每个业务容器同部署的 Envoy 代理组成，负责拦截、转发、观测所有进出流量。
• 控制面（Control Plane）：负责统一管理代理配置、颁发证书、下发策略。早期版本包含 Pilot、Mixer、Citadel 三个独立组件；1.5+ 合并为 istiod，但内部仍保留对应逻辑模块。

2.2 核心组件详解

2.3 Envoy 代理：数据面的核心

Envoy 是 Istio 数据面的唯一代理。每个 Pod 中作为 Sidecar 容器运行，通过 iptables 规则透明拦截所有入站和出站流量。

• 监听器（Listener）：绑定虚拟 IP 和端口，接收入站请求。
• 路由（Router）：根据 VirtualService/DestinationRule 规则匹配并转发流量。
• 集群（Cluster）：定义上游服务端点列表及负载均衡策略。
• 指标与日志：生成 TCP/HTTP 指标，支持访问日志和分布式追踪。

# Envoy 关键指标示例（通过 /stats/prometheus 暴露）
envoy_server_memory_allocated_bytes
envoy_cluster_upstream_rq_total
envoy_listener_downstream_cx_active
envoy_cluster_membership_healthy

2.4 Pilot：配置下发的枢纽

Pilot 负责将 Istio 的 CRD（VirtualService、DestinationRule、Gateway 等）转换为 Envoy 可理解的 xDS 配置（LDS、RDS、CDS、EDS）。

• 服务发现：对接 Kubernetes API Server，监听 Service/Endpoint 变化。
• 配置转换：将流量规则翻译为 Envoy 路由和集群配置。
• xDS 推送：通过 gRPC 流式推送至所有 Envoy 代理。

2.5 Mixer：策略与遥测（历史组件）

Mixer 在早期 Istio 版本中承担策略检查和遥测报告两大职责。它通过适配器模型对接后端系统（如 Prometheus、opa、Redis）。

• Check：每次请求前调用，验证是否满足访问控制策略。
• Report：请求结束后上报指标和日志。

由于 Mixer 引入的额外延迟（通常 2-10ms），社区在 1.5+ 版本中将其功能内联到 Envoy 中，称为 in-proxy 策略执行。

2.6 Citadel：安全基石

Citadel 负责 Istio 的证书管理体系，基于 SPIFFE 标准为每个工作负载签发身份证书。

• CA 管理：生成自签名根证书或对接外部 CA。
• 证书签发：通过 SDS（Secret Discovery Service）为 Envoy 下发 TLS 证书。
• 证书轮换：默认每 24 小时轮换一次，可通过环境变量调整。

# 检查 Citadel 证书签发状态
kubectl logs -n istio-system deployment/istio-citadel | grep "issued certificate"
# 查看证书过期时间
openssl s_client -connect <service>:443 -servername <service> 2>/dev/null | openssl x509 -noout -enddate

2.7 组件协同与容量水位关系

理解组件间的依赖关系是设定容量水位阈值的前提：

• Pilot 压力：当集群服务数 > 1000 或配置变更频繁时，Pilot 的 CPU 和内存成为瓶颈，导致 xDS 推送延迟升高，Envoy 配置滞后。
• Citadel 压力：大规模集群滚动更新时，大量 Envoy 同时请求证书轮换，可能导致 Citadel 的 gRPC 连接数飙升。
• Envoy 压力：每个 Envoy 实例维护的连接数、监听器数量、集群数量直接影响其内存占用。典型场景下，每个 Envoy 内存占用约 50-200MB。