故障隔离在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），防止线程/连接耗尽
这些参数共同作用，能让一次故障停留在最小作用域内，不会因重试风暴或连接堆积演变成雪崩。
