Istio流量治理详解：目标服务无Sidecar，策略还能生效吗？

在 Istio 的实战中，我们经常使用 DestinationRule 来配置连接池、熔断和负载均衡。

但随之而来的一个经典疑问往往困扰着开发者：“如果我的目标服务是一个未注入 Sidecar 的普通 K8s 服务，甚至是外部的数据库，这些治理策略还有用吗？”

答案可能出乎你的意料：非常有用，而且这正是 Istio 强大的地方。

本文将带你深入理解 Istio 的“客户端侧治理”机制，并展示如何利用这一特性来治理那些未注入 Sidecar 的服务。

一、 核心原理：我管不了你，但我能管好我自己

要理解为什么策略能生效，首先要纠正一个误区：流量治理不一定需要服务端参与。

Istio 的核心机制是 客户端侧治理。

1. 策略下发：控制平面会将你定义的 DestinationRule 转换成配置，推送到网格内所有的 Envoy 代理（包括 Sidecar 和 Ingress Gateway）。
2. 流量拦截：当网格内的服务 A 想要调用服务 B 时，请求还没发出，就被 A 自己的 Sidecar 拦截了。
3. 本地决策：A 的 Sidecar 根据 DestinationRule 的约束对流量进行本地化处理：
   • “最大连接数 100？好，那我检查一下本地连接池。”
   • “要用最小连接数负载均衡？好，我挑一个最闲的 Pod IP 发过去。”
   • “这个 Pod IP 最近老报错？好，我先把它暂时隔离（熔断）。”

结论：整个过程完全是调用方（客户端）的自律行为。目标服务是否有 Sidecar，是否在网格内，甚至是不是 K8s 服务，都不影响客户端执行这些“自我约束”。这正是 Service Mesh 架构中将控制逻辑下沉到数据平面的体现。

二、 场景实战：治理无 Sidecar 服务

为了更透彻地理解，我们来看两个典型的实战场景。

场景 1：治理网格内的遗留服务

假设你正在渐进式迁移应用，Service-A 已经注入了 Sidecar，而 Service-B 还是传统的 Deployment（无 Sidecar）。

即使 Service-B 处于未注入 Sidecar 的状态，你依然可以通过 DestinationRule 为其配置强大的治理策略：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: legacy-service-b
spec:
  host: service-b.default.svc.cluster.local
  trafficPolicy:
    # 1. 负载均衡策略：生效 ✅
    # 客户端 Envoy 会自主选择连接数最少的 Pod IP，
    # 这比 K8s Service 默认的轮询（Round-Robin）更智能，更能应对长尾延迟。
    loadBalancer:
      simple: LEAST_CONN

    # 2. 连接池管理（含并发控制）：生效 ✅
    # 客户端 Envoy 会限制自己发往 Service-B 的 TCP 连接数和 HTTP 请求并发数，
    # 防止把脆弱的遗留服务压垮。
    connectionPool:
      tcp:
        maxConnections: 100       # 最大 TCP 连接数
        connectTimeout: 30ms      # 建连超时时间
      http:
        http1MaxPendingRequests: 10 # HTTP/1.1 最大排队请求数
        http2MaxRequests: 100       # HTTP/2 最大并发请求数
        maxRequestsPerConnection: 10 # 每连接最大请求数

    # 3. 熔断策略 (Outlier Detection)：生效 ✅
    # 客户端 Envoy 会自动统计错误率，
    # 如果某个 Pod 连续返回 5xx 错误，客户端会暂时将其踢出负载均衡池（Ejection）。
    outlierDetection:
      consecutive5xxErrors: 5     # 连续 5 次 5xx 错误触发熔断
      interval: 10s               # 统计时间窗口
      baseEjectionTime: 30s       # 基础驱逐时间
      maxEjectionPercent: 100     # 允许驱逐 100% 的实例（极端保护）

效果：Service-A 发出的流量会被精确控制。不仅实现了智能负载均衡，还通过限制并发保护了目标服务，并通过被动熔断机制隔离了故障实例。

场景 2：治理网格外的第三方服务

这是一种更高级的玩法。假设你需要通过 Ingress Gateway（或内部 Sidecar）访问外部的数据库 external-db.com。

通过结合 ServiceEntry 和 DestinationRule，你可以把外部服务当成网格内服务一样来治理：

1. 注册服务：用 ServiceEntry 把 external-db.com 引入网格。
2. 定义策略：用 DestinationRule 限制连接数。

# 1. 注册外部服务
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-db
spec:
  hosts:
  - external-db.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  endpoints:
  - address: 1.1.1.1
  - address: 2.2.2.2
---
# 2. 施加治理策略
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: external-db-dr
spec:
  host: external-db.com
  trafficPolicy:
    # ✅ 生效：Gateway 会在多个外部 IP 间进行负载均衡
    loadBalancer:
      simple: LEAST_CONN
    # ✅ 生效：Gateway 会限制到外部数据库的总连接数
    connectionPool:
      tcp:
        maxConnections: 50

这不仅生效，而且是 Istio 治理出口流量的标准最佳实践，扩展了 Kubernetes 原生能力的边界。

三、 避坑指南：TLS 需要“双向奔赴”

虽然大多数策略（连接池、负载均衡、熔断）都是客户端的独角戏，但 TLS（mTLS） 是个例外。

如果你的目标服务没有 Sidecar，它就无法理解 Istio 的双向认证协议。如果你在 DestinationRule 中错误地开启了 ISTIO_MUTUAL，客户端 Envoy 会尝试握手，而服务端会因无法识别协议而拒绝，导致连接失败。

正确姿势：针对无 Sidecar 的目标，必须显式禁用 mTLS。

trafficPolicy:
  tls:
    mode: DISABLE  # ⚠️ 关键：目标无 Sidecar 时必须关闭
  connectionPool:
    # ... 其他策略依然生效 ...

四、 总结

Istio 的强大之处在于它赋予了调用端极大的控制力。

这意味着，只要你的入口网关或核心服务在网格内，你就可以利用 Istio 强大的能力，去治理发往数据库、外部 API、遗留系统的所有流量。你不需要强求整个世界都穿上 Sidecar，一样可以享受服务网格带来的红利。

对于更多云原生技术实践和深度讨论，欢迎前往 云栈社区 的对应板块交流分享。