Kubernetes中通过mTLS实现微服务安全通信需构建可信PKI体系、借助Istio等服务网格自动处理双向认证，或在应用层手动集成证书加载与校验，并辅以可观测性保障证书轮换与故障排查。
在 Kubernetes 中通过 mTLS（双向 TLS）实现微服务间安全通信，核心是让每个服务既能验证对方身份（服务端证书校验），又能向对方证明自身身份（客户端证书提供）。这需要证书管理、服务网格或应用层集成、以及网络策略协同。下面分几个关键环节说明怎么做。
证书体系设计与自动化签发
mTLS 依赖一套可信的 PKI 体系。不建议手动签发和分发证书，应借助自动化工具：
- 使用 cert-manager + Let’s Encrypt（适合公网场景）或更推荐 cert-manager + private CA（如自建 Vault 或使用 Istio 内置 CA）；
- 为每个服务（或每个 ServiceAccount）签发唯一证书，私钥只注入对应 Pod，且禁止挂载到可读卷；
- 证书需包含 SAN（Subject Alternative Name），通常是
spiffe://或 DNS 名（如/ns/ /sa/ svc-name.ns.svc），便于服务网格识别身份。
通过服务网格（如 Istio）启用 mTLS
Istio 是目前 K8s 中落地 mTLS 最成熟的方式，无需修改业务代码：
- 安装 Istio 时启用
mtls: STRICT策略（通过PeerAuthentication资源全局或按命名空间/服务设置）； - 确保所有服务 Sidecar 已注入（
istio-injection=enabled），Envoy 会自动处理证书加载、TLS 握手、双向校验； - 用
DestinationRule设置trafficPolicy.tls.mode: ISTIO_MUTUAL，显式声明目标服务要求 mTLS； - 验证方式：进入 Pod 执行
curl -v https://target-svc.ns.svc.cluster.local，响应头中应有200 OK且连接未被拒绝；也可查 Envoy 日志确认SSL handshake completed和verified peer certificate。
应用层自行实现 mTLS（无服务网格时）
若不用 Istio/Linkerd，需在业务代码中加载证书并配置 HTTP/TCP 客户端和服务端：
- 将证书和私钥作为 Secret 挂载进容器（如
/etc/tls/certs/），权限设为0400； - 服务端（如 Go Gin/Python FastAPI）监听 HTTPS，配置
tls.Config{ClientAuth: tls.RequireAndVerifyClientCert}并加载 CA 证书用于校验客户端； - 客户端发起请求时，必须设置
TLSConfig，含Certificates（自身证书+私钥）和RootCAs（信任的服务端 CA）； - 注意：DNS 名校验需开启（
InsecureSkipVerify: false），并正确设置ServerName匹配服务证书的 SAN。
可观测性与故障排查要点
mTLS 配置错误常导致连接拒绝或 503，需重点关注：
- 检查证书有效期、私钥是否匹配、CA 是否被双方信任；
- 用
openssl s_client -connect target-svc:port -cert client.crt -key client.key -CAfile ca.crt手动测试握手； - 查看 Envoy 访问日志中的
upstream_transport_failure_reason字段，或 Istio 的istioctl authz check； - 确保 NetworkPolicy 允许 443/端口通信，且 CNI（如 Calico/Cilium）未拦截 TLS 握手包。
不复杂但容易忽略的是证书轮换机制——cert-manager 默认支持自动续期，但需确保 Secret 更新后应用能热重载证书，或依赖 Sidecar 自动感知（如 Istio）。只要 PKI 可信、身份标识明确、传输链路受控，mTLS 就能成为微服务零信任通信的坚实基础。
