Service Mesh 落地（Istio / Linkerd 流量治理）（Mesh 可观测与排障）

适用场景

Mesh 把流量治理从代码里拿出来放到 Sidecar：好处是统一，代价是资源开销与排障复杂度增加。判断标准是"服务数量与治理需求"。

配置步骤（Mesh 可观测与排障）

# 指标：请求量、成功率、P99、TCP 连接
# 链路：Jaeger/Zipkin 采集 span
# 排障：
istioctl proxy-status
kubectl logs 服务-xxx -c istio-proxy --tail=100

关键参数与建议

• 适用：服务数量多、需要细粒度流量治理（灰度、熔断、mTLS）
• 注入：按命名空间自动注入，注意排除 kube-system 等系统命名空间
• 资源：每个 Pod 增加 Sidecar，CPU/内存预算要提前算
• 可观测：Mesh 自带指标与链路，但对 PROMETHEUS 等平台要求更高
• 排障：理解 iptables 拦截与 Sidecar 日志，否则问题定位很痛苦

容易踩的坑

• 只关注业务日志，忽略 Sidecar 日志
• 采样率过低，问题请求没有链路数据
• 未监控 Sidecar 资源，内存上涨导致 OOM

验证与巡检

istioctl proxy-status

• 巡检：所有代理同步（SYNCED）、采样率合理、Sidecar 资源正常

小结

Mesh 的落地建议先在一个非核心业务试点：验证注入、灰度、mTLS 与可观测，再评估是否全量。别一上来就全集群启用。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。