📚 课程目录第3章流量拓扑概念

3. 流量拓扑概念：服务网格中的流量路由、VirtualService、DestinationRule、Gateway

在服务网格（Service Mesh）架构中，流量拓扑是定义微服务之间通信路径与规则的核心抽象。与传统的网络层路由不同，服务网格的流量路由工作在应用层（L7），能够基于 HTTP 头部、URI 路径、来源服务、权重比例等细粒度属性进行智能分发。本章将系统讲解构成流量拓扑的三大核心 CRD（Custom Resource Definition）：VirtualService、DestinationRule 和 Gateway，并阐明它们之间的协作关系。

3.1 流量路由的基本模型

服务网格（以 Istio 为例）将数据平面（Envoy Sidecar）与控制平面（Pilot/istiod）分离。控制平面将用户定义的流量规则转换为 Envoy 可识别的 xDS 配置，下发至每个 Sidecar 代理。流量路由的最终效果是：入口流量 → Gateway → VirtualService → DestinationRule → 目标服务子集。

  核心原则：VirtualService 定义“如何路由”，DestinationRule 定义“路由到谁”以及“如何连接”，Gateway 定义“哪些流量可以进入网格”。

3.2 VirtualService：路由规则引擎

VirtualService 是流量路由的核心编排对象。它定义了一组路由规则，决定将匹配特定条件的流量转发到哪个目标服务（Host）。一个 VirtualService 可以包含多个 http、tcp 或 tls 路由块，每个路由块内部支持丰富的匹配条件和路由动作。

3.2.1 关键字段

字段	类型	说明
hosts	string[]	路由的目标主机名，可以是 Kubernetes Service 名称或 FQDN
gateways	string[]	关联的 Gateway 名称，`mesh` 表示网格内部流量
http	HTTPRoute[]	HTTP 流量路由规则列表，支持 match、route、redirect、rewrite 等
tcp	TCPRoute[]	TCP 流量路由规则，适用于非 HTTP 协议

3.2.2 路由匹配与权重分发

以下示例展示了一个典型的 VirtualService，它将流量按权重分发到两个不同版本的服务：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v3
      weight: 20

最佳实践：使用 match 条件实现金丝雀发布或 A/B 测试。权重总和必须为 100，否则 Istio 会自动归一化。

3.3 DestinationRule：连接策略与子集定义

DestinationRule 定义了在路由决策之后，如何与目标服务建立连接。它负责声明服务的子集（Subset）、负载均衡算法、连接池大小、TLS 设置以及熔断器参数。

3.3.1 子集（Subset）与版本管理

子集通常对应服务的不同版本（如 v1、v2、v3），通过标签选择器（labels）匹配对应的 Pod。VirtualService 通过 subset 字段引用这些子集。

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

3.3.2 负载均衡与熔断

策略类型	可选值	适用场景
loadBalancer	ROUND_ROBIN, LEAST_CONN, RANDOM, PASSTHROUGH	流量分发策略，默认 ROUND_ROBIN
connectionPool	maxConnections, http1MaxPendingRequests, http2MaxRequests	限制连接数，防止过载
outlierDetection	consecutiveErrors, interval, baseEjectionTime	熔断器，自动剔除异常实例

3.4 Gateway：网格边界入口

Gateway 负责管理进出服务网格的南北向流量。它配置在网格边缘的 Envoy 代理上，监听指定的端口和协议，并将流量转发给内部的 VirtualService。Gateway 本身不执行路由逻辑，只做端口暴露和 TLS 终止。

3.4.1 典型配置

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"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: bookinfo-credential
    hosts:
    - "bookinfo.example.com"

注意：Gateway 的 selector 必须匹配实际运行的 Ingress Gateway Pod 的标签。默认情况下，Istio 使用 istio=ingressgateway。如果修改了标签，Gateway 将无法生效。

3.5 三者协作关系

Gateway、VirtualService 和 DestinationRule 三者通过 host 字段串联起来，形成完整的流量拓扑。下图展示了它们之间的绑定关系：

3.6 流量拓扑与 OPA 策略的集成点

在后续章节中，我们将使用 OPA（Open Policy Agent）对上述流量拓扑资源进行安全权限校验。以下是 OPA 策略可以介入的关键检查点：

Gateway 暴露检查：禁止将内部服务（如 kube-system 命名空间）暴露到外部 Gateway。
VirtualService 路由检查：确保金丝雀发布的权重比例在安全阈值内（如 v1 不低于 50%）。
DestinationRule TLS 检查：强制要求所有跨命名空间的 DestinationRule 启用 mTLS。
子集标签一致性：验证 DestinationRule 中定义的 subset 标签与 Deployment 的实际标签一致。

  课程预告：第 5 章将详细讲解如何编写 OPA 策略来拒绝不符合安全基线的 VirtualService 和 DestinationRule 资源。