istio 能省掉 90% 的 mtls 手动配置，但必须由 sidecar 全面接管通信，并显式声明 peerauthentication（mode: strict）和 destinationrule（trafficpolicy.tls.mode: istio_mutual）；否则默认走明文，且手动配置 tls.config 会与 envoy 冲突。
直接说结论：Istio 能帮你省掉 90% 的 mTLS 手动配置，但前提是它必须接管所有服务间通信，且你不能跳过 PeerAuthentication 和 DestinationRule 这两个关键资源的声明。
为什么不用自己写 tls.Config？
Istio 的 Sidecar（Envoy）在 Pod 启动时自动注入，并劫持所有出站/入站流量。只要你没显式绕过它（比如直连 localhost:8080 或用 http://10.244.x.x:8080），Go 服务本身完全不需要调用 crypto/tls、加载证书、设置 ClientAuth——这些由 Envoy 统一完成。手动在 Go 里配 tls.Config 反而会和 Istio 冲突，导致握手失败或 fallback 到明文。
常见错误现象：
- Go 服务启用了
http.ListenAndServeTLS，但 Istio 注入后请求 503 或 connection reset - curl 报错
remote error: tls: bad certificate，其实是客户端（Envoy）没拿到服务端证书链，不是 Go 代码问题 - 本地开发时用
go run直连服务，绕过 Sidecar，误以为 mTLS 没生效
必须声明的两个 CRD：PeerAuthentication 和 DestinationRule
Istio 不会默认开启 mTLS，哪怕 Sidecar 已注入。你需要显式告诉它“哪些服务之间必须双向认证”。
PeerAuthentication 控制服务端是否接受并校验客户端证书：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 作用范围：namespace 级或 mesh 级，设为
mode: STRICT才强制 mTLS - 不写这个资源 → 所有服务间通信走明文（即使 Sidecar 存在）
- 写成
mode: DISABLE或漏掉spec→ 等价于没开
DestinationRule 控制客户端如何发起连接，特别是 TLS 模式：
- 必须设置
trafficPolicy.tls.mode: ISTIO_MUTUAL，这是 Istio 内置的 mTLS 模式，自动使用内置 CA 签发的证书 - 如果只写
DISABLE或SIMPLE，就退化成单向 TLS 或纯 HTTP - 目标服务名要和 Kubernetes Service 名一致，否则策略不生效
验证 mTLS 是否真在跑：看 Envoy 日志和指标
别信 “Sidecar 注入了就一定安全”。实际通信是否加密，得看流量路径上两个 Envoy 的行为。
- 查服务端 Pod 的 Envoy 访问日志：
kubectl logs -l app=your-service -c istio-proxy | grep "mTLS"，应看到类似upstream_peer_subject: "spiffe://cluster.local/ns/default/sa/default" - 查指标：
istio_requests_total{connection_security_policy="mutual_tls"}应有非零值；若全是unknown或none，说明 mTLS 没触发 - 用
istioctl auth check your-service-xxx可快速诊断该 Pod 是否处于 mTLS 流量路径中
注意：Istio 默认 CA 是自签名的，客户端和服务端都信任同一根 CA（istio-ca Secret），你无需准备任何 PEM 文件——除非你替换为自己的 CA，那就要改 MeshConfig 并挂载证书。
灰度迁移时最容易翻车的点
老服务还没注入 Sidecar，新服务已启用 STRICT mTLS，结果请求全挂——这不是 Istio 的 bug，是你没做兼容性设计。
- 双模式并存：先用
PeerAuthentication设为PERMISSIVE（接受 mTLS 和明文），等所有服务 Sidecar 就位后再切到STRICT - 避免跨 namespace 调用遗漏：
PeerAuthentication默认只作用于同 namespace，跨 ns 调用需单独定义或设为 mesh-wide - API Gateway（如 ingressgateway）是特例：它面向外部，通常只做单向 TLS，
PeerAuthentication对它无效，要用Gateway+VirtualService单独配 TLS 终止
真正的难点不在配置语法，而在拓扑可见性——你得清楚每个请求经过哪几个 Envoy，哪个环节卡在证书校验，哪个环节被路由规则拦截。一旦出问题，优先查 istioctl proxy-status 和 istioctl analyze，而不是翻 Go 代码里的 tls.X509KeyPair 权限。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
