适用场景

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

配置步骤（Sidecar 注入与命名空间管理）

kubectl label namespace app istio-injection=enabled
kubectl rollout restart deployment -n app
kubectl get pods -n app -o jsonpath='{.items[*].spec.containers[*].name}'

关键参数与建议

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

容易踩的坑

  • 系统命名空间被注入，影响集群组件
  • 注入后未重启 Pod，Sidecar 未生效
  • 资源限额未调整，Sidecar 抢占业务资源

验证与巡检

kubectl get ns --show-labels | grep istio-injection
  • 巡检：仅业务命名空间注入、Sidecar 状态正常

小结

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

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