K8s 集群内服务间 mTLS：上 Istio sidecar 的落地成本太高，轻量替代方案怎么权衡？

背景 我们是一个 40 人团队、约 60 个 Java/Go 微服务，跑在 8 节点自建 K8s 1.28（containerd，CNI 是 Calico）。目前集群内东西向流量全是明文 HTTP，安全团队要求年底前把服务间通信升级为 mTLS，理由是"内网也不能裸奔"。

现象 / 卡点 我们评估了 Istio：

1. 每个 Pod 多一个 sidecar，按 60 个服务 × 平均 3 副本估算，新增约 180 个 sidecar 容器，压测下来每台节点内存占用涨了 15%–20%，我们节点余量很紧，基本要加 2 台节点，一年云成本多 3–4 万；
2. 60 个服务里有一批是 2019 年的老 Go 服务，用自研 RPC 框架（gRPC 魔改 + 自定义 header），接入 Istio 后出向连接被 sidecar 劫持，握手时偶发 mTLS 证书链校验失败，复现率约 1%，查了两周没定位到根因；
3. 团队没有专职 SRE 盯网格，istioctl 排障门槛对业务同学偏高。

已尝试的排查与结果

• 试过只给核心 10 个服务开 PeerAuthentication，其余保持 PERMISSIVE，能跑通但安全团队不接受"部分加密"；
• 调研过 Cilium Mesh / Linkerd，Linkerd 对老 Go 服务的兼容性没找到公开案例；
• 想过应用层自己集成 mTLS（Go 用 crypto/tls、Java 用 truststore），但 60 个服务统一证书轮转和 CA 管理要自己造轮子，怕引入新故障面。

期望得到的答案形态

1. 各位在实际项目里，"服务数 60 左右、团队无专职网格运维"这个规模下，最终选了什么方案（Istio / Linkerd / Cilium / 应用层 mTLS / 干脆只做网络层隔离）？各自的真实成本（人力 + 机器 + 故障率）大概是什么量级？
2. 老服务接入服务网格出向劫持导致证书校验偶发失败，有没有遇到过类似坑、根因是什么、怎么绕？
3. 如果走应用层 mTLS，证书轮转和 CA 管理有没有比较成熟的开源组件推荐，避免自研？ 欢迎带着具体版本号和配置来答，泛泛的"建议上 Istio"就不必了，我更需要踩坑细节和成本数据。