In v1.3.0, as part of our work towards policy In most cases (such as whenĪ CertificateRequest has been created for a Certificate) a newĬertificateRequest will be created when needed (i.e at a time of a renewal Once the request has been fulfilled,ĬertificateRequest can usually be safely deleted. We no longer recommend including CertificateRequest resources in a backupĬertificateRequests are designed to represent a one-time Velero does not restore owner references, so it may be necessary to excludeĬertificates created for Ingresses from the backup even when not
Stuck waiting for the webhook pod to become ready. Velero by default restores pods before RBAC resources, the restore might get In order to do this, the controller needs the right permissions. This is because cert-manager's controller needs to be able to createĬertificate's for the cert-manager's webhook before the webhook can become Restore cert-manager's RBAC resources before the rest of the deployment. When restoring the deployment of cert-manager itself, it may be necessary to Restored last), should ensure that there is no unnecessary certificate reissuanceĭue to the order of restore operation, see Order of restore. Velero's default restore order( Secrets before Ingresses, Custom Resources Velero does not restore statuses of custom resources, so you should probablyĮxclude Orders, Challenges and CertificateRequests from the backup, seeĮxcluding some cert-manager resources from backup. include-cluster-resources=true flag is also passed to the backup command. Included in the backup might also not be included in backup unless Velero backup create, CRDs for which there are no actual resources to be We have briefly tested backup and restore with velero v1.5.3 andĬert-manager versions v1.3.1 and v1.3.0 as well as velero v1.3.1Įnsure that the backups include cert-manager CRDs.įor example, we have seen that if -exclude-namespaces flag is passed to The Ingress) cert-manager will be able to create a new Certificateįor the Ingress and determine that the existing Secret is for that Certificate. In the correct order ( Secret with the X.509 certificate restored before To avoid this issue, in most cases Certificates created via ingress-shimĬan be excluded from the backup. To a situation where updates to the Ingress (i.e a new DNS name) are not After a fullĬluster recreation, a restored owner reference would probably be incorrect Verify that the Certificate 'belongs' to that Ingress and will not attempt toĬreate/correct it for an existing Certificate. We also don't recommend backing up CertificateRequests, see Backing up CertificateRequests Restoring Ingress CertificatesĪ Certificate created for an Ingress via ingress-shim will have an owner To avoid unnecessary reissuance, we recommend that Orders and Challenges are excludedįrom the backup. So including such one-time resources in a backup can result in an unnecessary reissuanceĪfter a restore as without the status fields cert-manager will not be able to tell that,įor example, an Order has already been fulfilled. In most cases backup and restore tools will not restore the statuses of custom resources, The state of these resources at a later point. Holding a private key) so cert-manager might not be able to correctly recreate Resources can depend on other ephemeral resources (such as a temporary Secret Represents a one-time request for an X.509 certificate. An example would be a CertificateRequest that Excluding some cert-manager resources from backupĬert-manager has a number of custom resources that are designed to represent a Similarly, Secrets should be restored before Ingresses if youĪre using ingress-shim. Reissuance after a restore, ensure that Secrets are restored beforeĬertificates. If cert-manager does not find a Kubernetes Secret with an X.509 certificateįor a Certificate, reissuance will be triggered. Avoiding unnecessary certificate reissuance Order of restore If you encounter any errors, please open a GitHub issue or a PR to document variations on this process for different Kubernetes environments.
To avoid data loss, please test both the backup and the restore strategy on your own cluster before depending upon it in production. Note: We have tested this process on simple Kubernetes test clusters with a limited set of Kubernetes releases. This section refers to backing up and restoring 'all' Kubernetes resources in aĬluster - including some cert-manager ones - for scenarios such as disaster
BACKUP MANAGER PS3 TUTORIAL FULL
Kubectl apply -f < ( awk '!/^ *(resourceVersion|uid): +$/' backup.yaml ) Full cluster backup and restore
0 kommentar(er)
