Planning for disaster recovery
Argo CD doesn’t use any database directly (Redis is used as a cache), so it looks like it doesn’t have any state. Earlier, we saw how we can have a high availability installation, done mostly by increasing the number of replicas for each deployment. But we also have application definitions (such as the Git source and destination cluster) and details on how to access a Kubernetes cluster or how to connect to a private Git repo or a private Helm one. These things, which make up the state of Argo CD, are kept in Kubernetes resources – either native ones, such as secrets for connection details, or custom ones for applications and application constraints.
A disaster may occur due to human intervention, such as the Kubernetes cluster or the Argo CD namespace being deleted, or maybe some cloud provider issues. We may also have scenarios where we want to move the Argo CD installation from one cluster to another. For example, maybe the...