如何使用 Cert-Manager 管理容器证书？

证书生命周期管理是Kubernetes生产环境绕不开的问题。集群内服务越来越多采用HTTPS通信，手动申请、部署并定期更换证书既不现实也不安全。Cert-Manager作为CNCF孵化的开源项目，将证书管理抽象为Kubernetes原生API，通过声明式配置自动完成证书的签发、续期和轮换。它支持多种证书颁发机构，包括Let's Encrypt、HashiCorp Vault以及内部自建CA，并能够与Ingress、Gateway API等入口控制器无缝集成。

在开始安装之前，需要先理解Cert-Manager的几个核心概念。Issuer代表命名空间级别的证书颁发者，只能在指定命名空间内使用；ClusterIssuer则是集群级别的，所有命名空间都可以引用。Certificate资源描述了一张证书的期望状态，包括要保护的域名、有效期、关联的Issuer以及私钥存储位置。控制器会持续比较实际状态与期望状态，当证书即将过期时自动发起续期流程。

Cert-Manager 的架构与关键资源

Cert-Manager 的架构由多个控制器组成，每个控制器负责一类自定义资源的协调工作。cert-manager-controller是核心组件，它监听Certificate、Issuer、ClusterIssuer等资源的变化，并根据类型调用对应的签发器。对于ACME协议，还会出现两个额外的资源：Order和Challenge。Order表示一次ACME证书申请流程，而Challenge则对应域名验证的具体步骤，例如HTTP-01或DNS-01验证。

一个完整的签发流程大致如下：用户创建Certificate资源，控制器发现新证书后创建CertificateRequest，其中包含证书签名请求以及指定的Issuer引用。Issuer控制器根据类型执行实际签发动作。以Let's Encrypt为例，Cert-Manager会向ACME服务器发起Order，获取需要验证的域名挑战，然后根据Issuer中配置的solver创建Ingress或修改DNS记录以完成验证。验证通过后，证书被下载并保存到secretName指定的Secret中，应用即可挂载使用。

下面是一个典型的Certificate资源配置，它申请一张包含两个域名的证书，并指定自动续期策略：

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: default
spec:
  secretName: example-com-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - ippipp.com
    - www.ippipp.com
  duration: 2160h
  renewBefore: 360h

这里的duration表示证书有效期，renewBefore表示在到期前多少小时开始续期。Cert-Manager会确保在过期前完成新证书的签发并更新Secret，整个过程无需人工干预。需要注意的是，Let's Encrypt颁发的证书实际有效期通常为90天，所以duration不能设置超过CA允许的最大值，否则签发会失败。

安装 Cert-Manager 并配置 ClusterIssuer

安装Cert-Manager最简单的方式是直接应用官方静态清单，也可以使用Helm Chart进行更细粒度的参数配置。如果使用静态清单，先执行以下命令：

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

这条命令会在cert-manager命名空间中部署控制器、Webhook以及相关的RBAC权限。部署完成后，可以通过kubectl get pods -n cert-manager确认所有Pod都处于Running状态。Webhook是证书签发过程中的重要组件，负责校验自定义资源的合法性，如果Webhook不可用，提交Certificate资源时会被拒绝。

接下来需要配置一个证书颁发者。对于生产环境，通常使用ClusterIssuer配合Let's Encrypt实现自动化HTTPS。下面是一个基于HTTP-01验证的ClusterIssuer示例，它依赖集群中已经部署的Ingress控制器：

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@ipipp.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

privateKeySecretRef指定了用于存储ACME账户私钥的Secret名称，该私钥用于后续与Let's Encrypt服务器进行签名通信，必须妥善保存。solvers数组中可以定义多种验证方式，HTTP-01适合通过Ingress暴露的服务，而DNS-01则适合没有公网入口或需要签发通配符证书的场景。如果使用DNS-01，需要配置对应的DNS服务商凭据，例如Cloudflare、Route53等，Cert-Manager通过API自动创建和删除TXT记录。

创建完成后，可以执行kubectl get clusterissuer查看状态，当READY列显示为True时，说明Issuer已经就绪，可以开始签发证书。

通过 Ingress 自动签发证书

生产环境中最常见的做法是让Ingress控制器自动触发证书签发。只需在Ingress资源上添加Cert-Manager的注解，并在TLS部分指定要使用的Secret名称，Cert-Manager就会自动创建并管理对应的Certificate资源。以下是一个完整的Ingress示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
    - hosts:
        - app.ipipp.com
      secretName: app-tls
  rules:
    - host: app.ipipp.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-app
                port:
                  number: 443

当Ingress被创建或更新时，Cert-Manager会检查TLS配置，如果发现对应的Secret不存在或即将过期，就会根据注解中的Issuer发起证书申请。证书签发成功后，Secret会以Kubernetes TLS格式保存，包含tls.crt和tls.key两个数据项。Ingress控制器会自动加载这些证书，为指定的域名提供HTTPS服务。

如果想手动管理证书而不依赖Ingress注解，也可以直接创建Certificate资源，然后在Deployment中将Secret挂载为卷。这种方式适合那些不是通过Ingress暴露的服务，例如gRPC服务或需要双向TLS认证的内部服务。无论哪种方式，最终都会生成包含证书和私钥的Secret，应用只需要以标准方式读取即可。

证书自动续期与故障排查

默认情况下，Cert-Manager会在证书到期前30天开始尝试续期，即使你配置了更长的renewBefore，也不能超过CA的限制。续期过程会创建新的CertificateRequest并重新执行域名验证。对于HTTP-01验证，这意味着需要再次通过Ingress暴露临时路径；对于DNS-01验证，则会再次修改DNS记录。因此，确保Issuer中的验证配置长期有效至关重要，否则证书虽然即将过期，续期仍然会失败。

为了及时发现证书问题，建议监控Cert-Manager暴露的Prometheus指标。例如certmanager_certificate_expiration_timestamp_seconds表示证书到期时间戳，certmanager_certificate_ready_status表示证书就绪状态。可以基于这些指标配置告警规则，比如当证书剩余有效期小于7天时发送通知。Cert-Manager还提供了kubectl cert-manager status certificate等命令来快速查看证书状态和续期历史。

kubectl get certificate
kubectl get order
kubectl get challenge
kubectl describe certificate example-com-tls

当证书一直处于False状态时，需要检查Order和Challenge的详细信息。常见失败原因包括域名解析不正确、Ingress class不匹配、ACME账户邮箱未验证、DNS记录未生效以及达到Let's Encrypt速率限制。通过kubectl describe challenge可以查看具体的验证错误，例如HTTP-01返回404或者DNS-01查询不到TXT记录。解决这些问题后，可以删除失败的Order和Challenge，Cert-Manager会自动重新发起签发流程。

掌握Cert-Manager的证书管理机制后，你可以把原本需要手动处理的证书申请、部署和续期工作完全交给Kubernetes原生控制器完成，显著降低运维成本并提高服务安全性。

Cert-ManagerKubernetesTLS证书修改时间：2026-08-27 04:35:17