Configuration drift is the divergence between an environment’s declared state in Git and the configuration actually running in its Kubernetes cluster. It appears when live changes are not represented in version-controlled configuration, making environments harder to reproduce, verify, and troubleshoot. section 4.1.3 section 4.2.2
Manage drift through an environment pipeline that treats the repository as the source of truth:
- Store every environment and application configuration needed to create and configure the environment successfully. section 4.1.3
- Use a controlled component with cluster credentials to apply changes, while preventing manual configuration changes on the cluster. section 4.1.3
- Continuously compare the running state with the desired state, retry failed reconciliation, and notify operators when problems persist. section 4.1.2
- Verify workloads after deployment and revert to an earlier Git commit when the applied state does not work as expected. section 4.1.3
Drift in a staging environment
A developer manually changes Helm-managed settings on a cluster, but the change is absent from Git. The environment now differs from its declaration and becomes difficult to replicate or troubleshoot. An Argo CD pipeline can render the versioned Helm configuration, apply the resulting Kubernetes resources, detect differences, and restore the declared state. section 4.2.2
Figure 4.5 Defining the state of the cluster using the configuration in Git (GitOps). Environment pipelines monitor configuration changes on a Git repository and apply those changes to the infrastructure (Kubernetes cluster) whenever a new change is detected. Following this approach allows us to roll back changes in the infrastructure by reverting commits on Git. We can also replicate the exact environment configuration by just running the same pipeline against another cluster.
Trace how Git configuration, environment pipelines, and Kubernetes clusters work together to detect and correct drift. section 4.1.2
