📚 课程目录第2章 Istio核心概念回顾

2. Istio 核心概念回顾：VirtualService、DestinationRule、Gateway、Sidecar 原理

在深入 VS 快照与回滚护栏 之前，必须对齐 Istio 数据面与控制面的四个核心抽象。这些资源共同定义了流量如何进入网格、如何路由、如何负载均衡，以及 Sidecar 代理如何工作。理解它们之间的协作关系，是后续演练回退策略的基础。

核心认知： VirtualService 定义“路由逻辑”，DestinationRule 定义“目标策略”，Gateway 定义“入口边界”，Sidecar 定义“代理范围”。四者缺一不可。

2.1 四类资源的关系全景

下面的 SVG 展示了四类资源在 Istio 控制面与数据面之间的协作流程。请求从外部或内部发起，经过 Gateway 或直接进入 Sidecar，由 VirtualService 匹配规则并转发到 DestinationRule 定义的子集，最终到达 Pod。

2.2 VirtualService — 流量路由的核心

VirtualService 定义了如何将请求路由到特定版本或子集。它通过匹配 HTTP 头、URI、权重等条件，将流量分发到 DestinationRule 中定义的 subset。

字段	作用	典型值
`hosts`	匹配的目标服务名	`reviews`、`reviews.default.svc.cluster.local`
`http`	HTTP 路由规则列表	`match` + `route` + `rewrite`
`match`	请求匹配条件	`uri.prefix: /api`、`headers`
`route`	目标子集与权重	`destination.subset: v2`、`weight: 80`

  关键点： VirtualService 本身不定义目标 Pod 的版本标签；它引用 DestinationRule 中定义的 subset 名称。这种解耦使得路由策略与版本定义可以独立变更。

2.3 DestinationRule — 目标子集与负载均衡

DestinationRule 定义了服务的子集（subset）划分、负载均衡策略、连接池大小以及TLS 设置。它是 VirtualService 路由的“落地”配置。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

配置项	说明	回滚关注点
`subsets`	基于标签划分版本子集	子集名称变更会导致 VS 路由失效
`trafficPolicy.loadBalancer`	负载均衡算法	切换算法可能影响流量分布
`trafficPolicy.tls`	服务间 mTLS 模式	误关闭 mTLS 会导致连接失败

2.4 Gateway — 网格入口边界

Gateway 管理南北向流量，即从网格外部进入的请求。它配置在网格边缘，通常与 VirtualService 绑定，决定哪些外部请求可以进入内部服务。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookinfo.example.com"

回滚陷阱： 如果 Gateway 的 selector 指向了错误的 ingressgateway Pod 标签，或者 hosts 配置了不存在的域名，整个入口流量将中断。回滚演练中必须验证 Gateway 的 selector 与 ingressgateway 的标签匹配。

2.5 Sidecar — 代理范围与隔离

Sidecar 资源控制每个 Envoy 代理的监听端口、可访问的服务范围以及流量捕获模式。默认情况下，每个 Pod 中的 Sidecar 会监听所有端口并转发所有流量；通过 Sidecar 资源可以精细化限制。

字段	默认行为	自定义后效果
`workloadSelector`	匹配命名空间下所有 Pod	只匹配特定标签的 Pod
`ingress`	监听所有端口 (15006)	只监听指定端口，减少攻击面
`egress`	允许访问所有服务	只允许访问指定 host，实现微隔离

回滚关联： 在 VS 快照回滚场景中，如果 Sidecar 资源限制了 egress 范围，而回滚后的 VirtualService 引用了被限制的服务，流量将被拒绝。因此回滚前必须检查 Sidecar 的 egress 配置是否覆盖目标服务。

2.6 四类资源在回滚场景中的依赖关系

下面的 SVG 聚焦于回滚操作时四类资源的依赖链，帮助理解为什么修改 VirtualService 后需要同时检查 DestinationRule 和 Sidecar 的状态。

2.7 小结：回滚演练前的知识准备

VirtualService 是回滚操作的主要对象，快照保存的是它的完整 YAML。
DestinationRule 必须与 VS 的 subset 定义保持一致，否则回滚后路由失效。
Gateway 的 host 和 selector 决定了外部流量能否进入，回滚后需验证入口连通性。
Sidecar 的 egress 范围决定了回滚后的服务能否访问下游依赖，是常被忽略的“隐形护栏”。