Kubernetes 1.37 Pod Certificates 进入 GA：工作负载身份有哪些新边界

平台团队把集群升到 Kubernetes 1.37 后，Pod Certificates 和 Cluster Trust Bundles 已是默认开启的稳定能力，但这不等于应用会自动获得一套可直接用于生产的工作负载身份。真正的边界在三处：集群仍要提供签发控制器，Kubelet 只负责申请与投射，应用必须及时重新加载变化后的凭据文件。

Pod Certificates 与 Cluster Trust Bundles 改变了什么

Pod Certificates 把私钥和 X.509 证书链作为投射卷交给 Pod。Kubelet 根据 keyType 在节点侧生成私钥，创建面向指定 signerName 的 PodCertificateRequest，再把签发结果写进容器可读的文件。Cluster Trust Bundles 则把一个或多个信任锚合并、去重、规范化后写入指定路径，并随对象变化持续更新。

这两个能力一起解决了“身份凭据如何进入工作负载并轮换”的底座问题。它们没有替应用决定信任策略，也没有替平台选择签发机构。稳定的是 Kubernetes API 与 Kubelet 的交付链路，不是某一种具体 PKI 方案。

身份链路由谁负责

这里最容易误判的是“GA 就有内置签发器”。Kubernetes 官方专题明确说明，核心项目目前尚未随发行版提供 Pod Certificate signer。试验或生产接入仍要部署符合自身身份模型的签发实现，并单独评估它的授权规则、可用性与审计能力。

应用适配的边界在文件热更新

官方更推荐通过 credentialBundlePath 把私钥和证书链写入同一个 PEM 文件。应用只需监听一个文件的变化，再原子地换入新凭据；若把私钥和证书链分开写，读取动作可能刚好跨过轮换时点，应用要自行处理两份文件不一致的竞争窗口。

clusterTrustBundle 也会随集群对象变化更新。应用应使用 inotify 或有上限的轮询重新读取，而不是只在启动时加载一次。另一个硬边界是 subPath：以这种方式挂载投射卷源的容器不会收到后续更新。若依赖自动轮换，应直接挂载投射卷目录。

升级前用四项核对控制风险

• 签发路径：确认 signerName 对应的控制器已部署，并验证拒签、超时和故障恢复。
• 轮换路径：让应用在文件变化后重建 TLS 配置和长连接，观察旧证书是否仍被进程持有。
• 信任路径：核对 ClusterTrustBundle 的名称、标签选择器与 optional。默认找不到匹配对象时，Pod 会被阻止启动。
• 有效期：maxExpirationSeconds 默认 86400 秒，允许范围为 3600 秒到 7862400 秒；签发器可以返回更短的期限。

更稳妥的采用顺序是先在非关键工作负载启用，记录签发请求、文件更新时间和应用重载结果，再逐步扩大范围。身份能力进入 GA 降低了接口变动风险，却不会消除签发器故障、应用未重载或信任包选择错误带来的业务风险。

常见问题

Pod Certificates 能直接替代 ServiceAccount Token 吗？

不能一概而论。Pod Certificates 提供 X.509 凭据交付机制；能否替代 JWT 取决于签发器给出的身份语义、服务端验证方式以及现有授权策略。

升级到 Kubernetes 1.37 后需要立刻修改所有 Pod 吗？

不需要。能力默认可用并不代表既有工作负载会自动改用它。应先确定签发器、信任分发和应用热加载方案，再按工作负载逐步接入。