illegalCreed

中文

English

中文

English

Appearance

流量管理：VirtualService 与 DestinationRule ​

基于 Istio 1.22 · 核于 2026-08

速查 ​

  • 流量管理核心 CRD：VirtualService（定义请求如何路由）+ DestinationRule（定义目标实例策略）。两者配合实现精细流量控制，由 istiod 翻译成 Envoy 配置下发，秒级生效。
  • VirtualService：声明「匹配什么请求 + 路由到哪个目标」。匹配条件（match）按 URI/method/headers/port 筛选；路由（route）按权重（weight）分发到各 destination（host + subset + weight）。这是金丝雀/AB/流量镜像的基础。
  • DestinationRule：定义目标 host 的策略——subset（版本分组，如 v1/v2）、负载均衡（轮询/随机/最少连接/一致性 hash）、熔断（connectionPool 连接池、outlierDetection 异常实例摘除）、mTLS 策略（PEER_AUTHENTICATION）。
  • Gateway：入口网关，把集群外流量（如互联网）接入网格。Gateway 定义监听端口与协议，VirtualService 绑定 Gateway（gateways 字段）定义路由。Istio Ingress Gateway 默认基于 Envoy。
  • ServiceEntry：把集群外部服务（如第三方 API）纳入网格管理，让它也能享受 Istio 的路由/mTLS/指标。
  • 金丝雀发布：VirtualService 按 weight 分流量（如 90% v1 + 10% v2），逐步调整权重（v2 从 10%→50%→100%），无需改业务代码。
  • AB 测试：VirtualService 按 headers/cookie 路由不同用户到不同版本（如 header[x-user-group]=beta 走 v2，其他走 v1）。
  • 流量镜像（Mirror）：把生产流量复制一份到新版本（v2）做测试，不影响真实响应（mirror 流量的响应被丢弃）。用于上线前用真实流量验证新版本。
  • 超时与重试：VirtualService 的 timeout（请求超时）与 retries（重试次数/间隔/perTryTimeout），让 Sidecar 自动重试故障请求，业务无感。
  • 故障注入：VirtualService 的 fault（delay 延迟 / abort 中断），主动注入故障测试系统韧性（混沌工程）。

一、VirtualService：路由规则 ​

VirtualService 定义「请求该怎么路由」。一个简单金丝雀发布：

yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service          # 目标服务（K8s Service 名）
  http:
    - match:                 # 匹配条件（可选）
        - headers:
            x-canary:
              exact: "true"  # header x-canary=true 的请求
      route:
        - destination:
            host: order-service
            subset: v2       # 路由到 v2 subset
    - route:                  # 默认路由（其他请求）
        - destination:
            host: order-service
            subset: v1
          weight: 90          # 90% 到 v1
        - destination:
            host: order-service
            subset: v2
          weight: 10          # 10% 到 v2（金丝雀）
      timeout: 5s             # 请求超时
      retries:
        attempts: 3           # 最多重试 3 次
        perTryTimeout: 2s     # 每次尝试超时
  • hosts：本 VirtualService 作用于哪个服务（K8s Service 名或外部域名）。
  • http：HTTP 路由规则数组，按顺序匹配。每条含 match（匹配条件）+ route（路由目标）。
  • match：按 URI（uri.prefix/uri.exact）、method、headers、port 等筛选请求。可多条 match（OR 关系）。
  • route.destination：路由目标，含 host（服务名）、subset（版本分组，由 DestinationRule 定义）、weight（权重百分比）。
  • weight 加权路由：多条 route 按 weight 分流，实现金丝雀（90/10 → 50/50 → 0/100）。
  • timeout/retries：Sidecar 自动超时与重试，业务无感。

二、DestinationRule：目标策略 ​

DestinationRule 定义目标 host 的策略，最重要的是 subset（版本分组）——VirtualService 的 subset 必须在 DestinationRule 中定义：

yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  subsets:                   # 版本分组（VirtualService 按 subset 路由）
    - name: v1
      labels:
        version: v1          # 匹配 Pod label version=v1
    - name: v2
      labels:
        version: v2
  trafficPolicy:             # 全局流量策略
    loadBalancer:
      simple: LEAST_REQUEST  # 负载均衡：最少连接
    connectionPool:
      tcp:
        maxConnections: 100  # 最大连接数
      http:
        http1MaxPendingRequests: 50  # 最大 pending 请求
    outlierDetection:        # 熔断：异常实例摘除
      consecutive5xxErrors: 5    # 连续 5 次 5xx 标异常
      interval: 10s
      baseEjectionTime: 30s      # 摘除 30s
  • subsets：按 Pod label 把实例分组（如 version=v1、version=v2）。VirtualService 的 route.destination.subset 引用这里定义的 subset 名。
  • loadBalancer：负载均衡算法——ROUND_ROBIN（默认轮询）、LEAST_REQUEST（最少连接）、RANDOM（随机）、CONSISTENT_HASH（一致性 hash，会话保持）。
  • connectionPool：连接池限制——maxConnections（最大连接）、http1MaxPendingRequests（最大 pending），超限拒绝新请求（熔断）。
  • outlierDetection：异常检测——实例连续返回 N 次 5xx 标异常，从负载均衡摘除 baseEjectionTime（如 30s），到期半恢复试探。这是「被动熔断」（基于实际错误，非主动探活）。

三、Gateway：入口流量 ​

Gateway 把集群外流量接入网格：

yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: ingress-gateway
spec:
  selector:
    istio: ingressgateway    # 选中 Istio Ingress Gateway Pod（Envoy）
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "api.example.com"  # 监听该域名

---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-vs
spec:
  hosts:
    - "api.example.com"
  gateways:                  # 绑定上面定义的 Gateway
    - ingress-gateway
  http:
    - match:
        - uri:
            prefix: "/order"
      route:
        - destination:
            host: order-service  # /order/* 路由到 order-service
  • Gateway 定义「监听什么端口/协议/域名」，VirtualService（gateways 字段）绑定 Gateway 并定义「请求路由到哪个内部服务」。两者配合做入口流量分发。
  • Ingress Gateway：Istio 默认提供的入口 Envoy（istio-ingressgateway Deployment），承载所有外部入口流量。
  • HTTPS/TLS：Gateway 可配 TLS 终止（tls.mode: SIMPLE）或透传（tls.mode: PASSTHROUGH）。

四、金丝雀、AB 与流量镜像 ​

金丝雀发布（按权重） ​

VirtualService 按 weight 逐步把流量从旧版本切到新版本：

yaml
http:
  - route:
      - destination: { host: order, subset: v1 }
        weight: 90         # 旧版本 90%
      - destination: { host: order, subset: v2 }
        weight: 10         # 新版本 10%（金丝雀）
# 验证无误后调整：50/50 → 0/100（全量 v2）

AB 测试（按用户特征） ​

按 headers/cookie 把不同用户路由到不同版本：

yaml
http:
  - match:
      - headers:
          cookie:
            regex: ".*user-group=beta.*"   # beta 用户
    route:
      - destination: { host: order, subset: v2 }
  - route:                                  # 其他用户
      - destination: { host: order, subset: v1 }

流量镜像（影子流量） ​

把生产流量复制一份到新版本测试，真实响应仍是原版本（镜像响应被丢弃）：

yaml
http:
  - route:
      - destination: { host: order, subset: v1 }   # 真实流量到 v1
    mirror:                                         # 镜像流量
      host: order
      subset: v2                                    # 复制一份到 v2（测试）
    mirrorPercentage:
      value: 100.0                                  # 100% 镜像
  • 镜像用途：用真实生产流量验证新版本（v2），观察它的延迟/错误率，但不影响真实用户（响应用 v1 的，v2 的响应丢弃）。这是上线前的「真实流量压测」。

五、超时、重试与故障注入 ​

  • 超时（timeout）：VirtualService 的 timeout: 5s，Sidecar 等响应最多 5s，超时返回 504。防慢实例拖垮调用方。
  • 重试（retries）：retries: { attempts: 3, perTryTimeout: 2s, retryOn: 5xx,connect-failure }，Sidecar 自动重试故障请求（5xx、连接失败），最多 3 次。对临时故障（如网络抖动）有效，但要注意幂等性（非幂等接口重试可能重复操作）。
  • 故障注入（fault）：主动注入故障测试韧性——delay: { percentage: { value: 10 }, fixedDelay: 5s }（10% 请求延迟 5s）或 abort: { percentage: { value: 5 }, httpStatus: 500 }（5% 请求返回 500）。用于混沌工程，验证降级/熔断/重试是否生效。

交互演示 ​

本叶无专门可视化。建议在 K8s 集群装 Istio 后，用 Kiali（http://kiali.istio-system）观察服务拓扑与流量走向，配合 istioctl analyze 校验配置。

下一步 ​

理解了流量管理后，下一步看安全与 Ambient 模式——mTLS 双向认证、AuthorizationPolicy 授权、Ambient GA 详解、与 Linkerd 对比。