故障隔离在Istio中需协同Sidecar、VirtualService和DestinationRule实现：Sidecar限制命名空间间通信，VirtualService+DestinationRule控制版本调用边界，并配合超时、重试与连接池策略抑制级联故障。

故障隔离在 Istio 中不是靠“开启某个开关”实现的，而是通过流量治理能力组合设计出来的效果。核心思路是：用 VirtualService 控制请求流向、用 DestinationRule 定义服务版本和连接策略、再配合 Sidecar 资源限制服务可见范围——三者协同，才能让故障不扩散。

明确隔离目标：按命名空间或服务粒度切分

实际中常见两类隔离需求：

• 同一集群内，测试环境和服务环境完全互不干扰（比如 dev 和 prod 命名空间）
• 同一服务多个版本共存时，防止 v2 的异常影响 v1 的稳定调用（如灰度发布期间）

前者靠 Sidecar 资源做网络级收口，后者靠 VirtualService + DestinationRule 做路由级控制。

配置 Sidecar 实现命名空间级流量收口

默认情况下，一个 Pod 的 Sidecar 可以访问整个网格内的所有服务。要限制它只跟本命名空间通信，需定义 Sidecar 资源：

示例：限制 dev 命名空间只能访问自身服务和公共配置中心

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: dev-sidecar
  namespace: dev
spec:
  egress:
  - hosts:
    - "dev/*"
    - "istio-system/*"  # 允许访问 istiod、Prometheus 等系统服务

这样，dev 下的任何服务都无法主动调用 prod 或 staging 的服务，从网络层面切断了横向影响路径。

用 VirtualService + DestinationRule 控制版本间调用边界

当多个版本并存（如 orders-v1、orders-v2），可通过规则阻止 v2 主动调用 v1，或限制 v1 不响应来自 v2 的请求：

• 在 DestinationRule 中为每个子集设置独立的连接池和熔断阈值，避免一个子集拖垮另一个
• 在 VirtualService 中移除跨版本的路由条目，例如不配置 v1 → v2 的转发规则
• 对关键链路启用故障注入（httpFault），提前验证 v2 故障是否真的不影响 v1 流量路径

这样即使 v2 因代码缺陷持续超时或返回 5xx，v1 的调用链也不会被连带拖慢或失败。

配合超时与重试策略降低级联风险

单纯路由隔离还不够，必须约束调用行为本身：

• 在 VirtualService 的 http.route 下设置 timeout: 2s，防止单次调用无限等待
• 禁用非幂等接口的自动重试（retries: { attempts: 0 }），避免错误放大
• 对下游依赖启用 connection pool 限流（在 DestinationRule 中配置 connectionPool），防止线程/连接耗尽

这些参数共同作用，能让一次故障停留在最小作用域内，不会因重试风暴或连接堆积演变成雪崩。