多数团队第一次接触 cert-manager，都从一个很窄的入口开始：Ingress 需要 TLS，Gateway 需要证书，或者内部 service mesh 需要更规整的 issuer。这个入口没有问题，却会把项目真正的形状压扁。cert-manager 并非一个以 ACME 便利层为主体的工具。它更像一个 Kubernetes 里的证书控制平面，把期望状态对象持续翻译成签发、审批、校验、续期与 Secret 更新这些工作流。[1][2][3]

截至 2026-03-30 UTC，cert-manager/cert-manager 在 GitHub API 中显示 13,725 stars、2,352 forks、229 个 open issues，最近一次 push 时间为 2026-03-29T20:47:38Z。最新 GitHub release 是 v1.20.1，发布时间为 2026-03-27T19:13:14Z。[7][8] 这组信息的意义不在“它能不能签出一张证书”，而在另一个层面：项目已经成熟到值得问清它从哪里开始接管，在哪里有意停下。

配图说明：封面使用一张真实的机房摄影，而并非锁头图标或示意图，因为 cert-manager 的工作位置本来就在运维层。它处理的是已经带有 namespace、controller、队列与故障域的活体基础设施状态。[9]

这套契约从期望状态开始，不从 ACME 开始

真正的重心在 Certificate 资源上。[1] 它定义目标 Secret、请求的 subject 与 SAN 形态、issuer 引用、续期时间，以及私钥轮换策略。[1] 这个架构决定，比那句常见的“给 Kubernetes 用的 Let's Encrypt 工具”更关键，因为它让整个系统始终锚定在集群里的意图声明上，而并非绑定在某一种外部 CA 流程上。

顺着 Certificate 往外看，设计会变得很清楚：

• 面向应用的契约是“把这份证书材料持续维持在这个 Secret 里”
• 面向 issuer 的契约是“把这个 CSR 形状的请求变成签名结果，或者拒绝它”
• 面向平台的契约是“把续期与密钥轮换从工单式动作变成可预期的控制流”[1][3]

这也解释了 cert-manager 为什么能支持不止一种 issuer，不止一种输出格式。证书文档里不仅写了 target Secret、续期触发器与 rotationPolicy，还写了 CombinedPEM、DER 等额外输出格式。[1] 这些并非点缀式功能增长。它们说明项目从一开始就把证书签发当成 Kubernetes 内部的制品管理问题，而并非只把它当作一个 HTTP-01 自动化脚本。

分开的二进制组件，正是这套架构能工作的原因

如果不再把 cert-manager 想成一个单体程序，它会更容易读。项目把 controller、webhook 与 cainjector 拆成独立组件，各自有自己的运行参数和运维表面。[4][5] 较早的概念文档写得很直白：webhook 负责 cert-manager API 类型的 admission 校验、mutation 与 conversion；cainjector 负责把 CA bundle 注入需要信任根的资源里，例如 webhook configuration、CRD 与 APIService。[4][5]

这并非实现细节，而是系统边界本身。所以很多第一次值班时让人困惑的故障，实际上都来自这个拆分：controller 很健康，webhook 不可用，问题就会先以 API 拒绝的形式出现，根本走不到 issuer 那一步。[4] cainjector 落后时，证书签发本身仍然可以继续，集群里别的信任束却会滞后或者漂移。[5] cert-manager 从来都并非单一 loop，而是几条在 Kubernetes API 不同位置交汇的 loop。

因此，“证书自动化”这件事覆盖的范围，本来就不只包含签名。它同样包含 admission 与 trust bundle 的维护。只盯着 issuance event 的团队，往往会在事故里才看见这一层。

ACME 只是第二阶段流水线，并非产品本体

ACME 是 cert-manager 最显眼的部分，却只是更大架构中的一个分支。ACME 文档说明，系统会先创建 Order 资源，用来表示在外部 CA 上发起的证书订单，再把这个订单展开成一个或多个 Challenge 资源，分别进入不同 solver 的验证路径。[2]

这些细节之所以重要，在于它们准确说明了痛点通常落在哪里：

1. 失败点经常在 solver 配置、DNS 传播或 HTTP 可达性，不在顶层 Certificate manifest。[2]
2. cert-manager 会先做 self-check，再通知 ACME server 验证；self-check 失败时按固定 10 秒间隔重试。[2]
3. Challenge 调度并非无限并发；文档写明最多同时处理 60 个 challenge，并且会阻止某些相同 DNS 名称、相同 solver 类型的 challenge 一起运行。[2]

这已经是一套真正的控制平面，而并非外面套了一层 YAML 的脚本。它意味着，在外部 CA 做最终判断之前，cert-manager 已经先在集群内部完成了队列调度与状态机协调。

这里也正好露出产品边界。cert-manager 能协调 Order 与 Challenge 状态，却不能让外部 DNS 提供商更快收敛，也不能替你修好 ingress 或 gateway 的路由配置。自动化在这里停下，外围基础设施合同从这里开始。

审批与续期，才是生产环境真正的分界线

审批文档最能说明 cert-manager 对开发便利和生产纪律的不同态度。[3] 默认安装中，built-in issuer 会被自动批准，这是为了让第一次上手更自然滑。同一页也明确写着，这并非生产环境推荐姿态，生产里应当用更严格的 approval policy，限制“谁能申请什么证书”。[3]

这条界线关键。玩具集群里的问题是“这个 namespace 能不能拿到证书”；真实平台里的问题会马上变尖：

• 谁可以申请哪些 SAN 和用途
• 哪些请求应当在送到 issuer 之前就被拒掉
• 续期节奏与密钥轮换，是否和应用 reload 行为对得上
• PKI policy 究竟放在 cert-manager 对象里，还是放在 issuer 里，或者两边同时承担[1][3]

文档也写得很清楚：CSR 交给 issuer 之后，issuer 仍然保有自主权。它可以拒绝请求，可以修改最终证书属性，也可以按自己的 policy 去映射 CSR 与最终 X.509 证书之间的关系。[3] 从另一层看，cert-manager 并非全部的 trust policy，它是 Kubernetes 意图与 issuer 判断之间的编排层。

最近一轮 release，正好暴露出项目现在真正攻克的难点

1.20 的 release notes 很有价值，因为它让人看见 cert-manager 现在把工程时间花在哪里。[6] 这些修复，已经并非“第一次怎样签出一张证书”，而是围绕续期触发、ACME DNS-01 清理、challenge 诊断、public key mismatch 死循环，以及与 DNS 缓存有关的 controller 拒绝服务风险这些边缘正确性问题展开。[6]

这类修复本身就说明项目已进入基础设施成熟期。成熟项目不再主要证明 happy path，而是不断加固重试、清理、漂移与异常输入周围的状态机。cert-manager 现在处在这个阶段。

1.20 线里的几个例子很能说明问题：

• ingress 与 Gateway API 上 Duration、RenewBefore 注解发生变化后，现在会触发预期中的证书更新[6]
• ACME solver 行为持续被收紧，尤其是清理逻辑和 DNS-01 重试正确性[6]
• issuing controller 现在会拦住 issuer 返回公钥与 CSR 不匹配时形成的无限重签循环[6]

也就是说，项目当前复杂度的中心，已经不在入门安装，而在长期运行时面对不完美输入还能不能保持收敛。

适配边界与失配边界

当团队已经接受 Kubernetes 这套 CRD、controller、reconciliation 的世界观，并且希望证书生命周期也服从这套世界观时，cert-manager 会非常合适。[1][2][3] 尤其当证书已经并非零散的边缘资产，而是反复出现的平台状态时，例如 ingress TLS、gateway listener、内部服务身份，以及需要自动续期而不想回到手工 CSR 流程的 namespace 工作负载。

当真正困难的问题落在 Kubernetes 托管边界之外时，它就没有那么合适了。组织级 trust policy、向集群外系统分发 secret、应用在 Secret 更新后的热重载行为、以及由别的团队持有的 DNS 与网络控制权，这些都并非 cert-manager 一次安装能替你接管的层。它只解决其中一层，而且这恰好是它正确的边界。

因此，评估这个项目时，更干净的问题并非“它能不能自动化 TLS”，而是“我们是否希望证书生命周期像其他 Kubernetes 状态机那样运转，并且愿不愿意自己承担 cert-manager 有意停下之后的那一圈基础设施”。

来源

1. cert-manager 文档，《Certificate resource》：目标 Secret、签发触发器、续期、轮换策略与额外输出格式。
2. cert-manager 文档，《ACME Orders and Challenges》：Order 与 Challenge 资源、自检行为、调度与 ACME 校验流程。
3. cert-manager 文档，《Approval Policy》：built-in issuer 自动审批默认值、生产环境建议与 CSR 交接后的 issuer 自主权。
4. cert-manager 文档 v1.8，《Webhook》：webhook 在 cert-manager 控制平面中的 admission 校验、mutation 与 API conversion 角色。
5. cert-manager 文档 v1.8，《CA Injector》：向 webhook configuration、CRD 与 APIService 注入 CA bundle 的机制。
6. cert-manager 文档，《Release 1.20》：当前版本线上与续期触发、solver 行为、密钥不匹配处理和 controller 安全加固相关的修复。
7. GitHub API，cert-manager/cert-manager 仓库快照：本文使用的项目活跃度指标来源。
8. GitHub，cert-manager 的 v1.20.1 release：本文引用的最新 release 时间来源。
9. Wikimedia Commons，《File:Inside Data Center.jpg》：本文使用的真实机房照片来源。