DevOps & Automation
Configuration Drift and the Limits of Traditional CI/CD
As companies migrate their applications to Kubernetes, they are faced with a new management challenge. Traditional CI/CD pipelines (such as Jenkins or GitLab CI) employ a ‘push’ model: once the code is compiled, the pipeline executes a kubectl apply Execute a command to force the new application version into the Kubernetes cluster. Although this works initially, ‘Configuration Drift’ occurs over time. A system administrator might manually adjust a parameter in the cluster to resolve an issue. Suddenly, the actual state of the production environment no longer matches the configuration stored in Git. During the next deployment via the pipeline, the system overwrites the manual fix, potentially resulting in downtime.
The solution to this problem is GitOps, an operational framework in which Git acts as the absolute ‘Single Source of Truth’. Tools such as ArgoCD and Flux change the deployment process from an imperative push model to a declarative ‘pull’ model.
GitOps: Version control for your entire infrastructure
In GitOps, the complete desired state of your Kubernetes cluster (including applications, network rules, and configurations) is described in YAML files and stored in a Git repository. If a developer or operator wants to modify something in the production environment, this should never be done via the command line or a dashboard. Every change must be submitted via a Pull Request. The change only becomes active once this PR is approved and merged into the main branch.
This provides an unprecedented audit trail: you can see exactly *who* modified a firewall rule, *why*, and *when* in the Git history. Should a new version fail, a rollback is as simple as reverting the last Git commit.
ArgoCD: The Tireless Reconciliator
Tools like ArgoCD run as a service within your Kubernetes cluster. They have a ‘pull’ architecture. ArgoCD continuously monitors two things: the desired state in your Git repository and the actual live state of the Kubernetes cluster. When these two diverge — for example, because someone has manually deleted a deployment or because new code has been merged into Git — ArgoCD detects that the status is ‘Out of Sync’.
Next, the ‘Reconciliation Loop’ process kicks in. ArgoCD automatically pulls the new configuration from Git and applies it to the cluster to bring the state back into sync with the truth (Git). Manual changes in production are thereby immediately and mercilessly overwritten by ArgoCD, effectively eliminating Configuration Drift.
Security and Multi-Cluster Management
An additional benefit of the pull model is security. In a traditional push pipeline, your external CI/CD servers (such as GitHub Actions) must have administrator privileges (credentials) to penetrate your production Kubernetes cluster. This is a huge security risk if your CI/CD environment is hacked. With ArgoCD, the cluster itself pulls the changes in. The cluster only requires read permissions for the Git repository, and you do not need to open ports from the outside to your production environment. Learn more about cloud strategies at Computable.
Next: Clean Architecture and Hexagonal Design: Decoupling Your Business Logic
