📚 课程目录第2章服务网格基础回顾

2. 服务网格基础回顾：Istio架构核心组件及流量管理模型

在深入Helm与OPA集成之前，必须牢固掌握服务网格的基石——Istio。Istio是目前最成熟的服务网格实现之一，它通过将流量管理、安全、可观测性从业务代码中剥离，下沉至基础设施层，实现了“透明代理”的治理模式。本节将回顾Istio的四大核心组件及其流量管理模型，为后续策略模板化部署奠定基础。

2.1 Istio架构总览：控制面与数据面

Istio架构严格遵循“控制面（Control Plane）”与“数据面（Data Plane）”分离的设计原则。数据面由一组与业务容器同Pod部署的Envoy代理组成，负责拦截并处理所有进出Pod的流量；控制面则负责下发配置、管理策略、收集遥测数据。

  核心理解： 数据面执行策略，控制面定义策略。这种分离使得运维人员可以集中管理数千个微服务的流量行为，而无需修改业务代码。

2.2 核心组件详解

Istio 1.5+版本将控制面组件整合为单一的istiod二进制，但逻辑上仍可拆分为以下核心功能模块。理解每个模块的职责，是编写精准策略的前提。

组件	逻辑角色	核心职责	与OPA策略的关联
Pilot	流量大脑	服务发现（对接K8s API Server）、将VirtualService/DestinationRule转换为Envoy路由配置（xDS协议下发）	OPA可校验VirtualService中路由规则的合法性，防止非法流量劫持
Citadel	安全中心	管理证书生命周期、签发SPIFFE身份、自动轮换mTLS证书	OPA可控制哪些命名空间/服务可以请求证书，或强制mTLS策略
Mixer (V1)	策略与遥测（已弃用）	前置策略检查（如速率限制、黑白名单）、后置遥测报告（日志、指标）	V1中OPA可作为Mixer Adapter；V2中OPA直接拦截Envoy请求
Envoy	数据面代理	Sidecar代理，执行路由、负载均衡、健康检查、mTLS、限流、故障注入	OPA通过Envoy External Authorization Filter实现细粒度访问控制

版本演进提示： Mixer在Istio 1.5+中已被移除，其策略检查能力被迁移至Envoy的Wasm插件或外部授权（ExtAuthz）机制。本课程后续章节将重点使用Envoy + OPA的集成模式，而非Mixer。

2.3 流量管理模型：从“请求”到“路由”

Istio的流量管理模型围绕“四层抽象”构建，这四层抽象是Helm Chart中需要模板化的核心资源。理解它们之间的关系，是编写可复用策略模板的关键。

Gateway — 网格入口/出口：管理进入或离开服务网格的流量（南北向流量）。通常与Ingress Gateway或Egress Gateway绑定。
VirtualService — 路由规则核心：定义流量在服务级别如何路由。支持基于权重、Header、URI路径等条件的路由分发。
DestinationRule — 子集与策略：定义服务子集（Subset，如v1、v2）以及连接池大小、负载均衡算法、mTLS模式等流量策略。
ServiceEntry — 外部服务注册：将网格外部的服务（如数据库、外部API）注册到网格内，使其可以被网格策略管理。

2.4 流量路由示例：基于权重的灰度发布

以下是一个典型的VirtualService + DestinationRule配置，实现v1与v2版本之间90:10的流量分发。这个配置将是后续Helm Chart模板化的基础素材。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: "/reviews"
    route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
    loadBalancer:
      simple: ROUND_ROBIN

常见陷阱： VirtualService中的host字段必须与Kubernetes Service名称匹配，否则路由规则不会生效。同时，DestinationRule中的subset标签选择器必须与Pod的version标签一致。这些一致性约束正是OPA策略可以自动校验的典型场景。

2.5 小结：从架构到策略

回顾Istio的核心组件与流量模型，我们明确了以下关键点：

Pilot 是策略下发的通道，所有VirtualService/DestinationRule最终由Pilot转换为Envoy配置。
Envoy 是策略执行的端点，OPA通过Envoy的ExtAuthz Filter介入请求路径。
流量模型 的Gateway → VirtualService → DestinationRule链路，为策略提供了清晰的“注入点”。

在下一阶段，我们将学习如何将这些Istio资源通过Helm Chart进行参数化封装，并利用OPA确保生成的配置符合安全与合规基线。