Service Mesh 落地（Istio / Linkerd 流量治理）（流量治理（灰度 / 熔断 / mTLS））

适用场景

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

配置步骤（流量治理（灰度 / 熔断 / mTLS））

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: { name: web, namespace: app }
spec:
  hosts: [web]
  http:
  - route:
    - destination: { host: web, subset: v1 }
      weight: 90
    - destination: { host: web, subset: v2 }
      weight: 10

关键参数与建议

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

容易踩的坑

• 权重灰度未配合指标观察，等于直接全量
• 熔断阈值不合理，正常抖动被误熔断
• mTLS 全开后未处理未注入的服务，调用失败

验证与巡检

istioctl analyze -n app

• 巡检：配置分析无告警、灰度切换有记录、mTLS 状态一致

小结

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

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