備份與還原資源

如果您需要解除安裝 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

如果您要將資料轉移到新的叢集，您可能還需要複製您的已設定 Issuer 所參考的其他 Secret 資源，例如

CA Issuer

• 由 issuer.spec.ca.secretName 參考的根 CA Secret

Vault Issuer

• 由 issuer.spec.vault.auth.tokenSecretRef 參考的權杖驗證 Secret
• 由 issuer.spec.vault.auth.appRole.secretRef 參考的 AppRole 設定 Secret

ACME Issuer

• 由 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 issue 或 PR，以記錄不同 Kubernetes 環境中此流程的變更。

避免不必要的憑證重新簽發

還原順序

如果 cert-manager 沒有找到具有 Certificate 的 X.509 憑證的 Kubernetes Secret，將觸發重新簽發。為了避免還原後不必要的重新簽發，請確保先還原 Secret，再還原 Certificate。同樣地，如果您正在使用 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 建立的 Certificate 應從備份中排除。假設還原以正確的順序進行（在 Ingress 之前還原具有 X.509 憑證的 Secret），cert-manager 將能夠為 Ingress 建立新的 Certificate，並判斷現有的 Secret 是用於該 Certificate 的。

Velero

我們已經使用 velero v1.12.2 和 cert-manager 版本 v1.13.2 測試了備份和還原。

一些潛在的邊緣案例

• 請確保備份包含 cert-manager CRD。例如，我們發現如果將 --exclude-namespaces 標誌傳遞給 velero backup create，則除非也將 --include-cluster-resources=true 標誌傳遞給備份命令，否則備份中可能也不會包含沒有實際資源要包含在備份中的 CRD。

• Velero 不會還原自訂資源的狀態，因此您可能應該從備份中排除 Order、Challenge 和 CertificateRequest，請參閱從備份中排除一些 cert-manager 資源。

• Velero 的預設還原順序（Secret 在 Ingress 之前，自訂資源最後還原）應確保不會由於還原操作的順序而導致不必要的憑證重新發行，請參閱還原順序。

• 當還原 cert-manager 本身的部署時，可能需要在其餘部署之前還原 cert-manager 的 RBAC 資源。這是因為 cert-manager 的控制器需要能夠為 cert-manager 的 webhook 建立 Certificate，然後 webhook 才能準備就緒。為了做到這一點，控制器需要正確的權限。由於 Velero 預設會在 RBAC 資源之前還原 pod，因此還原可能會卡住等待 webhook pod 準備就緒。

• Velero 不會還原擁有者參照，因此即使不重新建立 Ingress 本身，也可能需要從備份中排除為 Ingress 建立的 Certificate。請參閱還原 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 不還原擁有者參照的問題，您可以分兩個步驟還原備份：首先還原 Secret 和 Ingress 以及 cert-manager 部署，其次還原 Certificate 資源。這將允許 cert-manager 的控制器為 ingress 建立 Certificate 並設定擁有者參照。然後，第二次還原將還原手動建立的 Certificate，並檢測到已存在為 Ingress 生成的 Certificate，並且不會嘗試重新建立它們。

1. 還原除 Certificate 資源之外的所有內容

velero restore create \
  --from-backup full-backup \
  --exclude-resources certificates.cert-manager.io

2. 等待 cert-manager 為 Ingress 建立 Certificate（如果 cert-manager 出現 RBAC/webhook 問題，您可能必須手動重新啟動部署）。在自動生成的 Certificate 建立之後，還原手動建立的 Certificate

velero restore create \
  --from-backup full-backup

備份 CertificateRequests

我們不再建議在大多數情況下將 CertificateRequest 資源包含在備份中。CertificateRequest 的設計目的是表示對 X.509 憑證的一次性請求。一旦請求被滿足，CertificateRequest 通常可以安全地刪除¹。在大多數情況下（例如，當為 Certificate 建立 CertificateRequest 時），會在需要時（即在 Certificate 更新時）建立新的 CertificateRequest。在 v1.3.0 中，作為我們實現 政策實施 工作的一部分，我們為 CertificateRequest 資源引入了身分識別欄位，在建立時，cert-mananager 的 webhook 會使用不可變的身分識別欄位更新 CertificateRequest 的規格，這些欄位代表 CertificateRequest 的建立者的身分。這為備份和還原 CertificateRequest 帶來了一些額外的複雜性，因為還原者的身分可能與原始建立者的身分不同，而且在大多數情況下，還原的 CertificateRequest 最終可能會處於不正確的狀態。