最新：在Twitter 和 Mastodon

备份和恢复资源

如果需要卸载 cert-manager 或将安装转移到新集群，可以备份所有 cert-manager 的配置，以便稍后重新安装。

备份 cert-manager 资源配置

以下命令将备份 cert-manager 资源的配置。在升级 cert-manager 之前进行备份可能很有用。由于此备份不包括包含 X.509 证书的 Secrets，因此恢复到尚未拥有这些 Secret 对象的集群将导致证书重新颁发。

备份

要备份所有 cert-manager 配置资源，请运行

kubectl get --all-namespaces -oyaml issuer,clusterissuer,cert > backup.yaml

如果您将数据传输到新集群，您可能还需要复制配置的发行者引用的其他 Secret 资源，例如

CA 发行者

  • 由 issuer.spec.ca.secretName 引用的根 CA Secret

Vault 发行者

  • 由 issuer.spec.vault.auth.tokenSecretRef 引用的令牌身份验证 Secret
  • 由 issuer.spec.vault.auth.appRole.secretRef 引用的 AppRole 配置 Secret

ACME 发行者

  • 由 issuer.acme.privateKeySecretRef 引用的 ACME 帐户私钥 Secret
  • 在 issuer.acme.dns01.providers 和 issuer.acme.solvers.dns01 字段下配置的 DNS 提供程序引用的任何 Secret。

恢复

为了恢复您的配置，您可以在安装 cert-manager 后对上面创建的文件运行 kubectl apply，除了不需要恢复的 uid 和 resourceVersion 字段。

kubectl apply -f <(awk '!/^ *(resourceVersion|uid): [^ ]+$/' backup.yaml)

完整集群备份和恢复

本节介绍了备份和恢复集群中的“所有”Kubernetes 资源，包括一些 cert-manager 资源，适用于灾难恢复、集群迁移等场景。

注意：我们已经在具有有限 Kubernetes 版本集的简单 Kubernetes 测试集群上测试了此过程。为了避免数据丢失，请在将此过程用于生产环境之前，在您自己的集群上测试备份和恢复策略。如果您遇到任何错误，请打开 GitHub 问题或 PR 记录不同 Kubernetes 环境下此过程的变体。

避免不必要的证书重新颁发

恢复顺序

如果 cert-manager 在 Kubernetes 中找不到具有 X.509 证书的 Secret 用于 Certificate，将触发重新颁发。为了避免在恢复后不必要的重新颁发，请确保在 Certificate 之前恢复 Secret。类似地，如果您使用 ingress-shim，则应在 Ingress 之前恢复 Secret。

从备份中排除一些 cert-manager 资源

cert-manager 有一些自定义资源，旨在表示某个时间点的操作。一个例子是 CertificateRequest，它代表对 X.509 证书的一次性请求。这些资源的状态可能取决于其他短暂资源（例如，包含私钥的临时 Secret），因此 cert-manager 可能会无法在稍后正确地重新创建这些资源的状态。

在大多数情况下，备份和恢复工具不会恢复自定义资源的状态，因此在备份中包含此类一次性资源会导致在恢复后出现不必要的重新颁发，因为没有状态字段，cert-manager 无法判断例如 Order 已经完成。为了避免不必要的重新颁发，我们建议从备份中排除 Order 和 Challenge。我们也不建议备份 CertificateRequest，请参阅 备份 CertificateRequest

恢复 Ingress 证书

通过 ingress-shim 为 Ingress 创建的 Certificate 将具有指向 Ingress 资源的 所有者引用。 cert-manager 使用所有者引用来验证 Certificate“属于”该 Ingress，并且不会尝试为现有 Certificate 创建/更正它。在完整集群重建之后，恢复的所有者引用可能不正确（Ingress UUID 将发生变化）。不正确的所有者引用会导致对 Ingress 的更新（例如，新的 DNS 名称）不会应用于 Certificate 的情况。

为了避免这个问题，在大多数情况下，通过 ingress-shim 创建的 证书 应该从备份中排除。鉴于恢复操作按照正确的顺序进行（密钥 包含 X.509 证书，在 Ingress 之前恢复），cert-manager 将能够为 Ingress 创建一个新的 证书，并确定现有的 密钥 是用于该 证书 的。

Velero

我们已经测试了使用 velero v1.12.2 和 cert-manager 版本 v1.13.2 的备份和恢复。

一些潜在的边缘情况

  • 确保备份包含 cert-manager CRD。例如，我们发现，如果将 --exclude-namespaces 标志传递给 velero backup create，对于没有实际资源要包含在备份中的 CRD，也可能不会包含在备份中，除非将 --include-cluster-resources=true 标志也传递给备份命令。

  • Velero 不会恢复自定义资源的状态，因此您可能应该从备份中排除 Order、Challenge 和 CertificateRequest，请参阅 从备份中排除一些 cert-manager 资源。

  • Velero 的 默认恢复顺序（Secrets 在 Ingresses 之前，自定义资源最后恢复）应确保由于恢复操作的顺序而不会发生不必要的证书重新颁发，请参阅 恢复顺序。

  • 在恢复 cert-manager 本身的部署时，可能需要在恢复其他部署之前恢复 cert-manager 的 RBAC 资源。这是因为 cert-manager 的控制器需要能够为 cert-manager 的 Webhook 创建 证书，然后 Webhook 才能准备好。为了做到这一点，控制器需要正确的权限。由于 Velero 默认情况下在 RBAC 资源之前恢复 Pod，因此恢复可能会卡住，等待 Webhook Pod 准备好。

  • Velero 不会恢复所有者引用，因此即使不重新创建 Ingress 本身，也可能需要从备份中排除为 Ingress 创建的 证书。请参阅 恢复 Ingress 证书。

使用 Velero 的示例备份和恢复

以下命令将创建默认命名空间和 cert-manager 命名空间中所有 Kubernetes 资源的备份，排除 Order、Challenge 和 CertificateRequest（见上文）

velero backup create \
  full-backup \
  --include-namespaces cert-manager,default \
  --include-cluster-resources=true \
  --exclude-resources challenges.acme.cert-manager.io,orders.acme.cert-manager.io,certificaterequests.cert-manager.io

为了解决 Velero 不会恢复所有者引用的问题，您可以分两步恢复备份：第一步恢复 Secrets 和 Ingresses 以及 cert-manager 部署，第二步恢复 Certificate 资源。这将允许 cert-manager 的控制器为 Ingress 创建 证书 并设置所有者引用。然后，第二次恢复将恢复手动创建的 证书，并检测到为 Ingresses 生成的 证书 已经存在，并且不会尝试重新创建它们。

  1. 恢复除 Certificate 资源以外的所有内容
velero restore create \
  --from-backup full-backup \
  --exclude-resources certificates.cert-manager.io
  1. 等待 cert-manager 为 Ingresses 创建 证书（如果 cert-manager 存在 RBAC/Webhook 问题，您可能需要手动重启部署）。在自动生成的 证书 创建后，恢复手动创建的 证书
velero restore create \
  --from-backup full-backup

备份 CertificateRequests

对于大多数场景，我们不再建议在备份中包含 CertificateRequest 资源。 CertificateRequest 旨在表示对 X.509 证书的一次性请求。一旦请求得到满足，CertificateRequest 通常可以安全地删除1。在大多数情况下（例如，当为 证书 创建了 CertificateRequest 时），在需要时会创建一个新的 CertificateRequest（即在 证书 续订时）。在 v1.3.0 中，作为我们对 策略实施 工作的一部分，我们为 CertificateRequest 资源引入了身份字段，其中，在创建时，cert-mananager 的 Webhook 使用不可变身份字段更新 CertificateRequest 的规范，表示 CertificateRequest 创建者的身份。这给备份和恢复 CertificateRequest 带来了额外的复杂性，因为恢复者的身份可能与原始创建者的身份不同，并且在大多数情况下，恢复的 CertificateRequest 最终可能会处于不正确状态。

脚注

  1. 存在一种边缘情况，即对 证书 规范的某些更改可能不会触发重新颁发，如果该 证书 没有 CertificateRequest。请参阅 有关何时重新颁发证书的文档。 ↩