Kubernetes 1.37 Pod Certificates 怎么落地：签发接口、轮换信号与节点侧验收

如果一个 Pod 要用 mTLS 访问内部服务，过去常见做法是把证书交给 Secret 管理，或者让外部身份系统负责注入。Kubernetes 1.37 的变化是：Pod Certificates 与 ClusterTrustBundles 已经进入 Stable，Kubelet 可以按 Pod 声明生成私钥、请求签发并把凭据投影到容器文件系统。但这项能力不是“升级集群后自动有证书”，签发控制器仍要由管理员选择和部署，应用也必须处理证书轮换。

真正可落地的最小闭环是：Pod 声明投影卷，Kubelet 创建 PodCertificateRequest，signer controller 写回证书链，应用从 credential bundle 读取凭据，并在文件变化时重新加载。

Pod Certificates 进入 Stable，解决的不是普通密钥挂载

Kubernetes 官方在 1.37 的发布说明中把 Pod Certificates 和 ClusterTrustBundles 一起列为 Stable。它们把 X.509 凭据的申请、刷新和信任锚分发接到了 Kubelet 与投影卷机制上，适合需要 TLS 或双向 TLS 的工作负载。

它和普通 Secret 的差别在于生命周期。私钥应在工作负载侧生成，证书由签发控制器签名；Kubelet 负责把这套流程接到 Pod 的声明上。这样做的结果不是让所有 Pod 自动拥有身份，而是提供了一条可插拔的发行管道。

签发链路要看清四个角色

部署前先把边界画清：应用只负责读取文件并使用 TLS，Kubelet 负责创建请求和写文件，signer controller 决定是否签发，ClusterTrustBundle 则承载验证对端所需的信任锚。四者缺一不可。

实际顺序可以压缩为一条可验收的链：Pod 被调度后，Kubelet 识别 podCertificate 与 clusterTrustBundle 投影卷；随后按 keyType 生成私钥，创建指向 signer 的 PodCertificateRequest，签发器把证书链写入 status.certificateChain，再用 status.beginRefreshAt 告诉 Kubelet 何时刷新。

这里最容易误判的是“API 对象已创建”不等于“应用已拿到可用身份”。签发器拒绝请求、证书链为空、投影目录尚未更新，都会让 Pod 继续运行却无法完成 mTLS 握手。

从 Pod 声明到节点侧验收，先验请求再验文件

新闻里的 Stable 只说明接口和机制达到稳定阶段，落地时仍要先确认 signer controller 已部署，并且它认可你在投影卷中填写的 signer name。Kubernetes 官方示例使用第三方 Tinycert 进行试验，但官方明确提醒它不是完整生产方案。

验收建议按下面的顺序做，避免只盯着容器启动状态：

1. 核对 Pod spec 中的 podCertificate projected volume，确认 signer name、keyType 和目标文件名属于同一套约定。
2. 查看对应的 PodCertificateRequest，确认请求已由 Kubelet 创建，并等待 signer controller 写入 status.certificateChain。
3. 同时检查 status.beginRefreshAt，它是后续轮换观察的时间信号；空值或过期而没有新链，说明刷新链路需要继续排查。
4. 进入容器核对 credential bundle 或分离文件是否出现，使用证书检查工具确认链条和用途，再做一次实际 TLS/mTLS 握手。

节点侧要关注的是 Kubelet 是否能读取匹配的 ClusterTrustBundle。Kubelet 会按 signer name 和 label selector 收集信任锚，合并后稳定排序，再写入投影路径。应用不能假设文件中证书的顺序代表优先级。

轮换信号出现后，应用必须重新加载凭据

Pod Certificates 的自动轮换由 Kubelet 负责触发，但应用是否能继续通信取决于它是否重新打开凭据。官方文章建议应用通过 inotify 或轮询观察文件变化；只在进程启动时读一次证书的客户端，轮换后仍可能拿着旧证书。

更稳妥的文件组织是 credential bundle：私钥和证书链放在一个文件中，应用只需要订阅一个文件的变化。若把私钥和证书链拆成多个文件，应用需要处理轮换中间读到新旧文件混合状态的竞态。

生命周期也不能写死。官方说明核心未来签发器的最大生命周期为 24 小时，其他 signer 的最大生命周期为 91 天。这个数字不是应用应当自行推导刷新时间的理由，刷新时机以 signer 返回的 beginRefreshAt 为准。

与 ServiceAccount JWT 怎么选

ServiceAccount JWT 仍然是成熟的默认身份方案，生态支持广，也能用于集群外联邦认证。Pod Certificates 的优势是 proof-of-possession 风格的 X.509 身份：私钥可以留在工作负载侧，对端通过证书链验证身份，更适合已有 TLS/mTLS 体系的服务。

选择时别把“进入 Stable”理解成“全面替换 JWT”。如果下游只接受 JWT，继续使用 ServiceAccount token 反而更省事；只有在服务已经以证书认证、需要双向 TLS，或希望减少 bearer token 复制范围时，Pod Certificates 才值得投入 signer、轮换和客户端改造成本。

常见问题

升级到 Kubernetes 1.37 后会自动签发 Pod 证书吗？

不会。核心提供 Kubelet、API 对象和投影机制，但官方说明当前还没有随 Kubernetes 核心发布的 Pod Certificate signer，需要部署兼容的第三方签发器或自行实现。

PodCertificateRequest 已存在但证书文件为空，先查哪里？

先查 signer name 是否匹配、signer controller 是否观察并处理该请求，再看 status.certificateChain 是否写回；不要先把问题归因给容器权限。

ClusterTrustBundle 与证书链是同一个东西吗？

不是。证书链证明工作负载身份，ClusterTrustBundle 提供验证这些证书所需的信任锚，Kubelet 会按选择条件收集并投影到 Pod。

应用只在启动时加载一次证书可以吗？

不建议。证书会自动轮换，应用需要通过 inotify 或轮询发现文件更新并重新加载，否则轮换后可能继续使用旧凭据。

采用前的最小清单

把这项更新带进生产前，至少完成一次小范围验证：部署 signer，创建带两个投影卷的测试 Pod，确认请求对象、证书链、信任锚文件和实际 mTLS 握手都成功；再人为触发或等待一次刷新，确认应用重新加载。任何一项没有可见结果，都不要因为版本已经 Stable 就扩大范围。