Kubernetes 1.37 最近有一个容易被忽略、但和 HTTPS/mTLS 关系很大的变化：Pod Certificates 与 Cluster Trust Bundles 的基础能力已经进入 GA。它不是“再加一个 Secret 类型”，而是把工作负载的 X.509 身份、私钥生成、证书签发、信任链分发和自动轮换，接进了 Kubernetes 的核心工作流。[1]
这件事对运维人员的实际意义是：以后给 Pod 配 mTLS，不一定要把证书和私钥提前烘进镜像，也不必让每个业务团队各自拼一套轮换脚本。证书生命周期可以由 Kubelet、Signer 和应用共同完成。不过，自动签发不等于应用自动生效，轮换文件之后，应用是否重新加载仍然是业务自己的责任。
一、Kubernetes 1.37 到底新增了什么
官方把这套能力拆成两部分：
- Pod Certificates：面向 Pod 请求和获取 X.509 证书、私钥以及证书链；
- Cluster Trust Bundles：把匹配到的信任锚证书集合投影到工作负载文件系统。
二者组合起来，应用可以使用 TLS 或 mTLS 与其他服务通信。Kubernetes 1.37 的发布说明显示，这一版本一共包含 67 项增强，其中 16 项进入 Stable、23 项进入 Beta、27 项进入 Alpha。[2]
二、它解决了 JWT 身份的哪个问题
ServiceAccount JWT 使用方便，而且已经深度集成到 Kubernetes。但它本质上是 bearer token：谁拿到 token，谁就可以代表这个身份发起请求。X.509 的思路不同，私钥用于证明“我确实持有这把密钥”，证书只描述公钥和身份。
更关键的是，Pod Certificate 设计要求私钥尽可能在工作负载侧生成并留在本地。Signer 看到的是证书请求和公钥，不需要接触业务私钥。这个边界很适合内部服务间的 mTLS，也符合私钥不离开使用方的基本原则。[1]
三、完整签发链路怎么跑
可以把链路理解成下面六步：
- Pod 被调度到 Node，Kubelet 发现 PodSpec 中声明了
podCertificate或clusterTrustBundle投影卷； - Kubelet 按
keyType生成私钥； - Kubelet 创建指向指定 Signer 的
PodCertificateRequest； - Signer Controller 审核请求并把证书链写入状态；
- Kubelet 把私钥、证书链和信任束写入容器文件系统；
- 证书接近刷新时间时，Kubelet 重复请求并更新文件。
这和传统的“先在 CI 里生成证书，再打包进 Secret”相比，最大的变化是签发动作靠近工作负载运行时，密钥生成也可以靠近工作负载本身。
四、自动轮换最容易踩的坑
官方明确提醒：自动轮换已经内置，但应用必须自己正确处理轮换。核心组件最终提供的证书最长可能只有 24 小时，其他 Signer 的最长有效期上限是 91 天。[1]
因此，应用不能只在启动时读取一次 tls.crt 和 tls.key。推荐优先使用 credential bundle，让 Kubelet 把私钥和证书链写到一个文件中，应用通过 inotify 或定时轮询发现文件变化后重新加载 TLS 配置。
如果把私钥和证书拆成两个文件，就要处理更新时序：应用可能刚读到新证书，却还没读到匹配的新私钥。生产环境中，这类竞态往往比证书过期更难排查。
五、Signer 还不是 Kubernetes 自带的万能 CA
这里要特别降温：Pod Certificates 的基础设施进入 GA，不代表 Kubernetes 1.37 已经自带一个可以直接用于生产的公共 CA。
官方示例使用了第三方 Tinycert Signer 来演示完整流程，并且明确说明 Tinycert 不是完整的生产方案。[1] 真正上线前，仍然要单独设计 Signer 的身份认证、授权范围、CA 私钥保护、审计日志、吊销策略和灾备方案。
也就是说，Kubernetes 负责把“申请、投影、轮换”的管道铺好；谁来签、签什么、信任谁，仍然是平台团队必须做的安全决策。
六、和传统 Secret 方案怎么选
| 方案 | 优点 | 主要风险 | 适合场景 |
|---|---|---|---|
| 手工 Secret | 简单、兼容性好 | 轮换依赖人工或外部脚本 | 低频内部服务、临时环境 |
| cert-manager | 生态成熟，ACME 和内部 CA 都能接 | 组件较多，需要管理 Secret 生命周期 | 已有 cert-manager 的生产集群 |
| Pod Certificates | 私钥可在工作负载侧生成，投影和轮换更贴近 Pod | Signer 与应用热加载仍需建设 | 平台级 mTLS、SPIFFE 类身份 |
没有必要为了追新把所有 Secret 一次性迁移。更稳妥的做法是先挑一条内部 mTLS 链路做试点，验证证书更新、应用 reload、故障回退和节点重启后的恢复。
七、上线前的检查清单
- 确认集群版本确实是 Kubernetes 1.37，并阅读对应发行说明；
- 确认目标 Signer 的实现、权限边界和 CA 私钥保护方案；
- 确认 Pod 只获得需要的证书和信任束，不要把整套根证书无差别投影进去；
- 模拟证书提前刷新，确认应用能通过 inotify 或轮询重新加载；
- 检查证书和私钥是否匹配：
openssl x509 -in tls.crt -pubkey -noout与私钥公钥结果对比； - 验证 Signer 不可用、Kubelet 重启、Node 漂移和旧证书过期时的行为；
- 把证书有效期、刷新时间、加载失败和握手失败接入监控。
八、我的判断：先把“自动更新”改成“自动生效”
Kubernetes 1.37 的 Pod Certificates 更像是把证书生命周期纳入平台，而不是替代所有证书系统。它最值得关注的地方，不是 API 名字变多了，而是私钥生成位置、信任束分发和自动轮换终于有了统一的工作流。
但真正决定体验的最后一公里仍然在应用：文件更新后能不能热加载，连接池会不会继续复用旧证书，证书异常时能不能快速回退。证书“已经换了”和业务“已经用上了”，中间还隔着一段很容易被忽略的距离。
🔕 评论已关闭