企业官网建设流程全解析

cert-manager 完整指南：在 Kubernetes 中自动签发、续签 TLS 证书

【免费下载链接】cert-managerAutomatically provision and manage TLS certificates in Kubernetes项目地址: https://gitcode.com/gh_mirrors/ce/cert-manager

cert-manager 是一个运行在 Kubernetes 集群里的开源证书管理控制器，把「证书」和「证书颁发者」变成和Deployment一样可以声明、可以版本管理的资源。它负责自动获取、自动续签、自动使用证书，支持从 Let's Encrypt（ACME）、HashiCorp Vault、Venafi / CyberArk Certificate Manager 等来源签发，也能在集群内部本地签发。对于运维、SRE 和平台工程师来说，它能把「证书快过期了」这种最容易踩坑、也最费工的事情变成一条自动流水线，显著降低服务中断风险。

cert-manager 解决什么问题：告别手工换证书

在传统做法里，运维人员常常要手动申请证书、把 PEM 文件塞进Secret、到期前再手工续一次，忘了就出事。cert-manager 的核心价值，是把这条链路彻底声明化、自动化：

• 过期前自动续签：控制器持续观察每个证书，根据duration和renewBefore在到期前主动触发重新签发，而不是等它真的失效。
• 来源可插拔：同一个Certificate资源，背后可以指向公网的 ACME 颁发机构，也可以指向企业内部的 CA、Vault 或 Venafi，业务侧不需要改配置。
• 与集群资源联动：能自动为 Ingress、Gateway API 的Gateway等流量入口生成证书，让「域名 → 证书」的对应关系跟着资源走。

简单说，cert-manager 把「证书生命周期」从一个靠人记日期的脏活，变成了一个控制器持续对账（reconcile）的声明式过程。它是 CNCF 项目，采用 Apache-2.0 许可，社区活跃、长期维护。

快速理解 cert-manager 的工作原理

cert-manager 的本质是一组 Kubernetes 控制器：你提交声明式的资源对象，它负责让集群的真实状态「追平」你的声明。要理解它，抓住三类核心资源就够了。

三类核心资源：Certificate、Issuer 与其余 CRD

• Certificate：描述「我想要一张覆盖哪些域名、有效期多长、私钥用什么算法」的证书。证书和私钥会被写进一个指定名字的Secret，并在到期前自动更新。
• Issuer/ClusterIssuer：描述「证书从哪里来」。Issuer是命名空间级别的，ClusterIssuer是跨命名空间的。它承载了 ACME 账号、CA 凭据、Vault 路径等签发细节。
• 其余 CRD：Order、Challenge（ACME 挑战流程）、CertificateRequest（更底层的签发请求）等，是控制器与签发源之间协作的中间产物，用户通常无需直接关心。

这些资源的 API 定义可以在仓库的 deploy/crds/ 目录找到，类型声明见 internal/apis/。

从证书请求到自动续签的闭环

控制器的工作可以拆成一条清晰的流水线：

1. 观测：watch 集群里的Certificate，算出它的续签时间点（renewalTime）。
2. 请求：临近续签时，向对应Issuer发起一次签发请求，内部会生成CertificateRequest。
3. 挑战与签发（以 ACME 为例）：完成 HTTP-01 或 DNS-01 挑战以证明域名归属，然后由颁发机构签发。
4. 落盘：把新的证书和私钥写回Secret，并更新Certificate的状态（Ready等条件）。
5. 循环：回到第 1 步，持续对账，直到下一个续签点。

整个过程由控制器、准入 Webhook（校验资源合法性）、cainjector（把集群 CA 证书注入到需要它的资源里）等组件协作完成，源码入口在 cmd/controller/ 与 cmd/cainjector/。

如何选择合适的证书签发来源

cert-manager 的设计里，「从哪里拿证书」被抽象成可注册的 Issuer。仓库内置了几类，源码见 pkg/issuer/：acme、ca、selfsigned、vault、venafi。选哪个取决于你的域名归属和网络环境。

ACME 与 Let's Encrypt：免费的公网证书

对接任意符合 RFC 8555 的 ACME 服务器，最常用的就是 Let's Encrypt。你在Issuer里指定 ACME 的server、email和solvers，它就能自动注册账号、完成挑战、持续续签。

• HTTP-01：适合普通域名，控制器会动态创建 Ingress（或 Gateway API 的HTTPRoute）把验证请求引到专门的 solver Pod。
• DNS-01：适合通配符域名。内置了 AWS Route53、Google Cloud DNS、Cloudflare、Azure DNS、DigitalOcean、Akamai、ACME-DNS、RFC 2136，还支持自定义 webhook，选择见 pkg/issuer/acme/dns/。

企业内部 CA、Vault 与 Venafi

如果证书应该由内部体系签发，cert-manager 同样支持：

• ca：指向集群内的一个 CASecret，做本地签发，私钥由 cert-manager 管理。
• selfsigned：自签名，适合测试或内部不受外部信任的场景。
• vault/venafi：对接 HashiCorp Vault 或 Venafi TPP / TLS Protect Cloud 等企业级证书系统。

关键能力一览

下面是 cert-manager 在「把证书管好」这件事上最值得了解的几个能力点。

ACME DNS-01 与 HTTP-01 两种验证路径

ACME 的核心是「证明你拥有这个域名」。cert-manager 把两种主流验证方式都做成了声明式配置：HTTP-01 走入口流量验证，DNS-01 直接在权威 DNS 写入 TXT 记录。你可以用selector（按域名、按标签）为不同域名指定不同的 solver，让一个Issuer灵活覆盖多个 DNS 区。

Ingress 与 Gateway API 的自动接管

除了手动写Certificate，cert-manager 的「shim」还能自动为Ingress和 Gateway API 的Gateway派生证书，域名跟随入口资源变化。对 Gateway API，它甚至会从关联的路由资源里推断 TLS 主机名，减少重复配置；相关源码在 pkg/controller/certificate-shim/。

自动续签、续签窗口与过期前刷新

续签默认按renewBefore提前触发。项目还在演进更细的续签控制：支持定义允许续签的时间窗口（cron + 时长 + 时区）、可选择性禁用自动续签，以及通过 ACME ARI（RFC 9773）让颁发机构建议续签时间，兼顾「CA 的建议」和「运维的窗口」。相关设计见 design/20250920.certificate-renewal-control.md 与 design/20260304.certificate-acme-ari.md。

私钥轮换、算法与输出格式

Certificate支持 RSA、ECDSA、Ed25519 等私钥算法，PKCS1 / PKCS8 两种编码，并支持把私钥轮换策略默认设为「每次续签都换私钥」，避免密钥长期不变带来的风险。此外可输出多种附加格式，方便对接不同中间件。

集群内 CA 注入（cainjector）

很多内部服务需要把集群 CA 的公钥注入到 ConfigMap、CRD 等对象里。cainjector组件负责这件事，源码见 pkg/controller/cainjector/，让「谁需要信任哪个 CA」也能声明化管理。

典型使用场景与实践

• 为 Ingress / Gateway 自动配 HTTPS：最常见也最受欢迎的用法。声明一个 ACMEClusterIssuer，再让入口资源引用证书，域名加进来就自动出证书、到期自动续。
• 通配符与多域名：用 DNS-01 配一个*.example.com的证书，覆盖所有子域名，省去逐个申请。
• 内部服务间 mTLS：用ca或selfsigned在集群内本地签发，配合cainjector把 CA 注入到需要的客户端，打通服务网格或内部 RPC 的互信。
• 对接企业证书体系：已有 Vault 或 Venafi 的团队，用对应Issuer把 cert-manager 接到现有签发流程，统一用 K8s 资源管理。
• 续签窗口治理：生产环境把续签限制在低峰期，避免在业务高峰集中触发 ACME 请求，缓解限流和网络压力。

安装部署与日常维护

用 Helm 快速部署

cert-manager 官方维护了一个 Helm chart（见 deploy/charts/cert-manager/），也是推荐的部署方式。它会带上 CRD、控制器、Webhook、cainjector等所需的全部组件，并要求 Kubernetes ≥ 1.22。基本流程是helm repo add后helm install，再按需覆盖values.yaml（默认值在 deploy/charts/cert-manager/values.yaml）。完整的多种安装方法都在官方文档中给出。

文档、社区与提问渠道

• 官方文档：入门指南、ACME 配置、Ingress 快速上手等都在 cert-manager 官网，仓库内 docs/ 指向同一处。
• 社区：项目有公开的 Google Group 用于公告和开发协调，也有面向 Kubernetes 社区的 Slack 频道，是提问最快的地方；定期还有公开的公开会议，任何人都可以旁听。
• 参与贡献：开发环境支持 Linux 与 macOS（macOS 有额外依赖要求），贡献指南和编码规范见 CONTRIBUTING.md。如需本地拉取源码参与开发，可使用镜像仓库地址https://gitcode.com/gh_mirrors/ce/cert-manager进行 clone。

版本更新、变更日志与安全报告

• 发布节奏与变更日志：每次发布都附带 changelog，发布说明也在官网发布。产物包括各组件的容器镜像、Helm chart 与二进制。
• 安全报告：安全是项目第一优先级，发现漏洞请按 SECURITY.md 的指引提交。
• 特性开关（feature gate）：部分新能力（如 Gateway API、ARI、私钥轮换默认策略等）通过 feature gate 灰度，默认状态可在 internal/controller/feature/features.go 查看，便于按版本逐步启用。

总的来说，cert-manager 用「声明式资源 + 控制器对账」这套 Kubernetes 原生的思路，把证书的申请、续签、分发和注入都自动化了。无论你要的是 Let's Encrypt 的免费公网证书，还是企业内部 CA 的统一管理，它都能用同一套资源模型串起来，让证书始终处于有效状态，把最容易被遗忘的「换证书」从运维日常里彻底移除。

【免费下载链接】cert-managerAutomatically provision and manage TLS certificates in Kubernetes项目地址: https://gitcode.com/gh_mirrors/ce/cert-manager