在现代云原生架构中，服务网格(Linkerd)的稳定运行高度依赖于安全且高效的TLS证书管理。cert-manager作为行业领先的自动化证书管理工具，通过颁发和轮换证书保障通信安全，因而在Linkerd生态系统中占据了核心地位。2025年，随着cert-manager发布1.18版本，其默认RotationPolicy策略的调整引发了一系列潜在影响，特别是对于使用trust-manager进行信任锚管理的环境来说，升级风险不容忽视。本文将详细剖析这一版本变更的内涵及其对Linkerd证书管理的挑战，并分享有效的解决路径，帮助用户安全顺利完成升级。 cert-manager是云原生生态中自动化管理证书生命周期的关键工具。此前版本中，cert-manager的RotationPolicy默认为Never，即证书不会真正被“轮换”，而仅仅是更新其过期时间。
虽然这种方式简化了运维流程，但从安全角度讲，这意味着私钥长期保持不变，存在潜在风险。1.18版本大胆将这一默认策略改为Always，真正实现了定期生成新私钥和替换证书，极大提升了安全性。 TLS证书的轮换并非简单操作，它涉及生成新密钥、将新证书投入使用以及废弃旧证书三个步骤。在服务网格中，信任链的完整性尤为关键。Linkerd的信任锚作为信任体系的根基，必须妥善管理，确保证书更新不会带来通信中断。trust-manager作为Linkerd旁路的信任证书管理工具，将信任锚证书打包成一个信任链执行管理。
正常情况下，当cert-manager旋转信任锚时，trust-manager负责在信任链中同时保留新旧两个信任锚，确保活跃的Linkerd代理仍能通过旧信任锚校验流量，直至完成信任锚同步更新，从而避免通信断链。 但是，cert-manager 1.18版本的RotationPolicy改为Always后，对曾习惯只配置单个信任锚的环境造成了严重影响。因为cert-manager会真正生成新的私钥替换信任锚，而trust-manager如果只配置一个信任锚证书，会在新旧信任锚切换时立即删除旧信任锚，使得依赖旧信任锚的Linkerd代理面临认证失败，导致通信损坏直至代理重启完成更新。对比之前的Never策略，仅仅更新证书过期时间，不改变密钥的做法，这种行为升级确实带来了潜在的服务中断风险。 这一问题的根源，是多年来Linkerd部分文档和部署示例仅建议配置单一的信任锚，未充分预见到真正证书轮换带来的连续性问题。在cert-manager默认RotationPolicy更改前，单锚策略能“蒙混过关”，因为密钥不变，旧信任锚继续有效，通信不会受到破坏。
然而随着安全需求提升，这种隐患被显现无遗。为有效应对，用户必须确保trust-manager的Bundle资源配置中，sources数组包含至少两个信任锚证书。这样就能在新信任锚正式启用前保留旧信任锚，平滑过渡，消除通信中断风险。 检测配置是否合规的简便方法是检查trust-manager的Bundle资源是否只包含单个信任锚证书。若如此，强烈建议在升级cert-manager到1.18版本前，调整配置使其符合Linkerd最新文档要求。否则，建议暂缓升级，直到完成必要的调整。
Buoyant官方文档和社区支持也强调，用户在升级过程中应密切关注cert-manager、trust-manager以及Linkerd的证书管理部分更新和推荐实践。遇到配置疑问，可主动联系Buoyant技术支持或参与Linkerd Slack社区讨论，获取专业指导。 在未来的发展规划中，Linkerd团队承诺将持续优化证书管理机制，简化信任链配置，并引入更智能的校验工具，帮助用户规避类似升级故障。云原生安全始终是Linkerd发展核心，围绕证书自动化管理的体验也必将日益完善。 综上所述，cert-manager 1.18版本RotationPolicy的根本性调整是安全进步的重要标志，但同时对Linkerd与trust-manager的集成提出了更高要求。安全性和稳定性必须兼顾，升级策略需慎重执行，建议用户在升级前全面核查信任锚配置，做好充分准备以应对潜在风险。
作为服务网格领域的从业者，理解证书生命周期管理的细节，掌握工具之间的协作方式，对于构建可靠的零信任通信环境意义深远。面对升级带来的挑战，保持冷静、积极应对，是保障业务连续性和系统安全的关键。未来，随着云原生技术的不断演进，服务网格的安全能力将更加强大，证书管理也将更加智能高效。期待行业共同进步，拥抱更安全的服务网格新时代。
