cert-manager 是 Kubernetes 中最流行的证书管理工具，它将 X.509 证书的签发、续期和生命周期管理自动化。它通过自定义资源定义来扩展 Kubernetes API，使得用户可以像管理 Pod、Service 一样管理证书。
以下是关于 cert-manager 的组件、功能详解以及工作流程图。
一、 cert-manager 的核心组件
cert-manager 部署在 Kubernetes 集群中，通常安装在 cert-manager 命名空间下。它主要由以下三个核心组件（Pods）组成：
1. cert-manager-controller (核心控制器)
这是 cert-manager 的“大脑”。它是一个典型的 Kubernetes 控制器，负责：
- 监控资源：监听
Certificate,Issuer,Challenge等 CRD 资源的变化。 - 协调状态：根据用户定义的期望状态（YAML 文件），执行逻辑以确保证书被签发、更新或修复。
- 密钥对生成：生成私钥和 CSR（证书签名请求）。
- 与 Issuer 交互：调用具体的签发者（如 Let's Encrypt、Vault 或 CA）进行证书签发。
2. cert-manager-webhook (Webhook 组件)
这是一个动态准入控制组件，主要功能包括：
- 验证：在用户创建或更新
Issuer、Certificate等资源时，校验 YAML 内容的合法性（例如检查域名格式、必填字段）。 - 注入 CA：在某些特定场景下（如
CAInjector功能），将 CA 证书注入到 Kubernetes 资源中（例如将 CA 注入到ValidatingWebhookConfiguration中，实现自签名证书的闭环）。
3. cert-manager-cainjector (CA 注入器)
- 功能：主要负责将 CA 证书自动注入到 Kubernetes 的 Webhook 配置或 APIService 资源中。这使得 cert-manager 自身以及其他依赖 Webhook 的组件能够正常通过 TLS 通信。
二、 cert-manager 的核心功能
1. 自动化证书签发
这是最核心的功能。支持多种签发来源：
- ACME 协议：支持 Let's Encrypt 等公开 CA，自动签发免费的可信证书。
- 私有 CA：使用企业内部的自建 CA 签发证书。
- Vault：集成 HashiCorp Vault 进行证书管理。
- 自签名：生成自签名证书，常用于开发测试。
2. 证书自动续期
- cert-manager 会监控证书的有效期。在证书即将过期前（默认过期前 30 天），它会自动触发续期流程，重新签发新证书并更新对应的 Kubernetes Secret，实现“永不过期”的体验。
3. DNS/HTTP 域名验证
对于 Let's Encrypt 等公开 CA，需要证明你对域名的所有权。cert-manager 支持两种验证方式：
- HTTP01：通过自动创建 Ingress 路由，让 CA 服务器访问
http://your-domain/.well-known/acme-challenge/...来验证。 - DNS01：通过调用云厂商 API（如阿里云 DNS、AWS Route53、Cloudflare）自动添加 TXT 解析记录来验证。支持通配符证书。
4. 信任管理
管理集群内的信任根，将 CA 证书分发到不同的命名空间，供应用程序挂载使用。
三、 核心概念（CRD 资源）
为了理解流程，必须了解几个关键概念：
- Issuer / ClusterIssuer: 签发者。定义了证书从哪里来（例如 Let's Encrypt 的账号信息）。
Issuer是命名空间级别的，ClusterIssuer是集群级别的。 - Certificate: 证书定义。用户创建的资源，描述了我要什么域名、用什么 Issuer 签发、证书存放在哪个 Secret 中。
- Secret: Kubernetes 原生资源。最终生成的证书文件和私钥会存放在这里。Ingress 或 Pod 会挂载这个 Secret。
- Order & Challenge: 在 ACME 流程中自动生成的中间资源，用于处理签发请求和域名验证挑战。
四、 cert-manager 工作流程图
以下是一个典型的 ACME (Let's Encrypt) DNS01 验证流程。
流程说明：
- 用户创建一个
Certificate资源。 - Controller 检测到资源，生成私钥和 CSR，并创建一个
Order（订单）。 - CA 返回挑战内容，Controller 创建
Challenge资源。 - Controller 调用 DNS 提供商 API 设置 TXT 记录。
- CA 服务器验证 DNS 解析。
- 验证通过，CA 签发证书。
- Controller 获取证书，存入 K8s Secret。
- Ingress 或应用挂载 Secret，HTTPS 生效。
Mermaid 流程图：
graph TD
%% 参与者定义
User[用户]
API_Server[K8s API Server]
CM_Controller[cert-manager Controller]
DNS_Provider[DNS 服务商<br>e.g. Cloudflare/阿里云]
ACME_Server[ACME CA 服务<br>e.g. Let's Encrypt]
K8s_Secret[K8s Secret]
Ingress[Ingress 控制器]
%% 步骤流程
User -->|1. 创建 Certificate CRD| API_Server
API_Server -->|2. 通知事件| CM_Controller
subgraph cert-manager 内部逻辑
CM_Controller -->|3. 检查并生成私钥/CSR| CM_Controller
CM_Controller -->|4. 创建 Order & Challenge 资源| API_Server
end
CM_Controller -->|5. 调用 API 设置 TXT 记录| DNS_Provider
DNS_Provider -.->|6. DNS 记录生效| DNS_Provider
ACME_Server -->|7. 轮询 DNS 验证所有权| DNS_Provider
ACME_Server -- DNS验证成功 --> ACME_Server
CM_Controller -->|8. 请求签发证书| ACME_Server
ACME_Server -->|9. 返回签发证书| CM_Controller
CM_Controller -->|10. 将证书和私钥存入 Secret| API_Server
API_Server -->|11. 更新 Secret| K8s_Secret
K8s_Secret -.->|12. 挂载/引用| Ingress
Ingress -->|13. HTTPS 服务就绪| User
五、 详细工作步骤解析（结合上图）
- 资源创建：用户编写 YAML 文件，定义一个
Certificate对象，指定域名（如example.com）、引用的Issuer（如 Let's Encrypt 生产环境）以及存储 Secret 的名称。 - 控制器感知：
cert-manager-controller通过 Informer 机制监听到新的Certificate对象创建。 - 生成请求：Controller 检查是否已有对应的 Secret。如果没有，它会生成私钥，并据此创建 CSR（证书签名请求）。同时，它会创建一个
Order资源。 - 处理挑战：如果是首次签发或配置变更，
Order会触发Challenge资源的创建。Controller 读取Issuer中配置的 DNS 凭证，调用云厂商 API 在域名解析中添加一条_acme-challenge.example.com的 TXT 记录。 - 等待验证：Let's Encrypt 服务器会尝试查询该 TXT 记录。Controller 会轮询状态，一旦检测到 DNS 记录传播成功，它会通知 ACME 服务器进行验证。
- 签发证书：验证通过后，ACME 服务器签发证书并返回给 Controller。
- 存储结果：Controller 将获得的证书公钥和之前生成的私钥打包，存入 Kubernetes 的
Secret资源中。 - 应用生效：用户的 Ingress 控制器（如 Nginx Ingress）配置了引用该 Secret 的 TLS 规则，检测到 Secret 更新后，自动加载新证书，HTTPS 服务正式对外提供访问。
总结
cert-manager 通过将复杂的 PKI（公钥基础设施）操作转化为 Kubernetes 原生资源管理，极大地降低了 HTTPS 部署的门槛。它的核心价值在于自动化和声明式配置，让开发者无需关心证书过期和手动更新证书的繁琐流程。