Istio 解决微服务规模化后的通信失控问题，通过 Envoy Sidecar 统一治理网络行为，使业务代码专注逻辑；VirtualService 定义“往哪走”，DestinationRule 控制“怎么走”；需确保服务名、标签、FQDN 等全链路一致。
为什么微服务调用总在“连不上、超时、雪崩”里循环？
Istio 解决的不是某个具体 bug，而是微服务规模化后必然出现的通信失控问题：服务发现靠硬编码或 SDK 自注册、负载均衡只靠 Kubernetes Service 的简单轮询、熔断要每个语言都集成 Hystrix/Sentinel、出问题后根本不知道请求卡在哪一跳——这些都不是代码写得不够好，而是治理逻辑不该长在业务进程里。
它把原本散落在各服务中的网络行为（如重试、超时、TLS 加密、指标上报）统一收编到 Envoy Sidecar 中，让应用只管业务逻辑。比如你有个 Python 写的图像识别服务，不用改一行 inference.py，就能让它自动启用 mTLS、被限流、在失败率超 50% 时自动熔断、流量按权重分发给 v1/v2 版本。
- 服务发现不再依赖客户端 SDK 拉取注册中心，而是由
Pilot从 Kubernetes API 实时同步Endpoints，推给每个 Envoy - 负载均衡策略（
ROUND_ROBIN/RANDOM/LEAST_REQUEST）在DestinationRule里声明，不绑定任何语言运行时 - 故障恢复（重试、超时、熔断）全部在数据平面生效，无需等待应用层响应或抛异常
VirtualService 和 DestinationRule 到底谁管什么？
初学者常混淆这两个核心 CRD：VirtualService 负责“往哪走”，DestinationRule 负责“怎么走”。前者定义路由规则（比如把带 cookie: user-type=premium 的请求打到 reviews-v2），后者定义目标服务的连接与弹性策略（比如对 reviews 启用连接池限制和异常检测）。
一个典型错误是：只配了 VirtualService 做灰度，却没在 DestinationRule 里为 v2 子集开启 outlierDetection，结果 v2 实例挂了，流量还在持续打过去，直接触发雪崩。
-
VirtualService.hosts必须和 Kubernetes Service 名字完全一致（包括命名空间，如reviews.default.svc.cluster.local） -
DestinationRule.subsets中定义的标签（如version: v2）必须和 Pod 的metadata.labels对齐，否则子集不生效 - 熔断阈值（如
consecutive_5xx: 5）作用于单个 Envoy 实例视角，不是全局统计；若集群有 20 个 reviews 实例，需确保每个实例的失败都独立达标才会触发摘除
Sidecar 注入失败的三个高频原因
执行 kubectl label namespace default istio-injection=enabled 后 Pod 还没自动带上 Envoy？别急着重装 Istio，先看这三处：
- Pod 的
spec.template.metadata.annotations中存在sidecar.istio.io/inject: "false"—— 这个 annotation 优先级高于 namespace 标签，会强制跳过注入 - Deployment 使用了
initContainers且镜像不可拉取，Istio 注入器会静默放弃整个 Pod 注入（日志里只有 “skipping injection”） - Pod 指定了
hostNetwork: true或hostPID: true，Envoy 无法共享网络命名空间，注入器默认拒绝处理
验证是否注入成功，别只看 kubectl get pod 的容器数，用 kubectl get pod -o jsonpath='{.spec.containers[*].name}' 确认是否存在 istio-proxy 容器名。
可观测性不是“开了就行”，指标源头得对上
Istio 默认暴露的 istio_requests_total 等指标，看起来开箱即用，但实际排查时经常发现“监控图有数据，但和日志对不上”。根本原因是：这些指标只统计经过 Envoy 代理的流量——如果服务间直连（绕过 Sidecar）、或用了 ClusterIP + headless service 导致 DNS 直解析到 Pod IP，那这部分流量就完全不会出现在 Istio 指标里。
- 必须确保所有服务间调用都走
FQDN（如http://ratings.default.svc.cluster.local:9080），而非http://ratings:9080或 Pod IP - 检查
DestinationRule是否设置了trafficPolicy.portLevelSettings，否则某些端口可能被 Envoy 忽略（尤其非标准端口如 8001） -
istio_request_duration_seconds的 bucket 默认只到 60s，高延迟 AI 推理服务（如 >10s）需要手动调整stat_name: request_duration_milliseconds的 histogram 配置，否则大量数据落入+Inf桶，失去分析价值
真正落地时，最常被忽略的是“服务名一致性”：Kubernetes Service 名、VirtualService.hosts、应用代码里写的调用地址、Prometheus 抓取 job 名，四者只要有一处拼错或缺命名空间，整条链路的指标就断了。这不是配置问题，是契约问题。
