GitOps & Argo CD: Understanding the Fundamentals
Hello everyone! Welcome to this deep dive into GitOps. While it’s easy to grab a controller like Argo CD or Flux CD and deploy an application to Kubernetes, true GitOps is much more than that. It involves understanding the fundamental concepts that revolutionize how we manage applications and infrastructure.
In this post, we will break down the essential concepts of GitOps, why it emerged, and its foundational principles.
1. Why GitOps? The Problem with Traditional CD
Before GitOps, the Continuous Delivery (CD) part of the pipeline often lacked the rigor applied to Continuous Integration (CI).
Consider updating a Kubernetes cluster resource, like modifying a node configuration (e.g., adding a taint or increasing resources). Without GitOps, if a person (say, person X) makes this change using shell or Python scripts and commands like kubectl or helm, there is no proper mechanism for tracking that modification.
This lack of tracking leads to critical issues:
- No Versioning: There is no history or version tracking for changes made to the Kubernetes cluster itself.
- No Auditing: You cannot easily determine exactly who made which change at a specific time.
- Lack of Tracking: Unlike source code, which is always properly tracked in a Git repository (requiring PRs, verification, and merges), infrastructure changes often bypass proper version control.
The fundamental idea that birthed GitOps was simple: If your source code has an integrated Git approach for tracking (CI), why shouldn't your deployment process (CD) have one too?.
2. What is GitOps? Defining the Single Source of Truth
GitOps is a methodology that uses Git as a single source of truth (SSOT) to deliver applications and infrastructure.
While the name suggests a tight coupling with Git, the core concept is actually tightly coupled with the versioning concept. Although Git is often used, declarative manifests stored in platforms like versioned S3 buckets could theoretically be used too, as long as they are versioned and immutable.
Scope: Application and Infrastructure Delivery
It is essential not to get confused: GitOps is not just about application delivery. GitOps is also about infrastructure delivery.
For organizations managing hundreds of Kubernetes clusters and thousands of resources, infrastructure management becomes highly critical. GitOps adds immense value in managing this infrastructure in a consistent, standardized way.
3. The GitOps Workflow
The GitOps approach standardizes the deployment process. Here is the standard flow, taking the example of updating a node configuration via GitOps:
- Declarative Manifests: The desired state (e.g., the node configuration, a deployment YAML, or a pod YAML) is expressed in a declarative YAML manifest.
- Actor Submits Change: A DevOps engineer (the actor) submits a Pull Request (PR) to the Git repository containing the declarative manifest (e.g.,
node.yaml). - Review and Merge: The PR goes through a standard Git verification mechanism, is reviewed by another team member, and then merged into the repository.
- GitOps Controller Acts: A GitOps controller (like Argo CD or Flux CD) actively watches the Git repository for changes.
- Deployment: The controller picks up the new, merged change and deploys it onto the Kubernetes cluster.
This process ensures that whatever configuration is seen in the Git repository is the same configuration deployed on the Kubernetes cluster ("What you see is what you have").
4. The Four Pillars of GitOps Principles
For any tool or process to adhere to GitOps, it must follow these principles:
| Principle | Description |
|---|---|
| 1. Declarative | The system managed by GitOps must have its desired state expressed declaratively (e.g., YAML manifests for Kubernetes). |
| 2. Versioned & Immutable | All resources tracked must be versioned, usually by being stored in a Git repository, ensuring immutability of historical states. |
| 3. Pulled Automatically | Changes must be deployed automatically when they appear in the repository. This can be achieved via a pull mechanism (controller actively watching Git) or a push mechanism (using webhooks to trigger the controller). |
| 4. Continuously Reconciled | The GitOps controller constantly compares the live state of the Kubernetes cluster with the declared state in Git (the SSOT). If discrepancies are found, the GitOps controller overrides the cluster state to match the Git state. |
The principle of continuous reconciliation is a major advantage of GitOps. It prevents unauthorized access or direct changes to managed resources. The controller maintains a cache of the cluster state and the Git state, and if they differ, it enforces the Git repository's configuration.
5. Major Advantages of Using GitOps
Implementing GitOps provides significant operational benefits:
- Security: GitOps provides significant security advantages. By continuously reconciling the cluster state, any unwanted change or modification attempted by a hacker is automatically overridden and removed because the controller only trusts Git. Only the GitOps controller should have access to manage the cluster resources.
- Auto Healing Behavior: The continuous reconciliation provides an auto-healing behavior. If a resource is modified directly on the cluster, the controller acts to restore it to the declared state defined in Git.
- Versioning and Auditing: Because all changes must go through Git via PRs and merges, you inherently gain robust versioning and a clear audit trail of who made what change and when.
- Standardized Process: It standardizes the entire deployment and infrastructure management workflow, making processes predictable.
Note on Kubernetes: While GitOps principles are broad, most popular modern controllers like Argo CD and Flux CD currently target Kubernetes clusters only. By definition, GitOps is not strictly limited to Kubernetes, but in practice today, it is predominantly used within the Kubernetes ecosystem.
Conclusion
By adopting GitOps, you elevate your CD platform to the same level of accountability, tracking, and process control that is expected of your CI platform.
Tools like Argo CD serve as powerful GitOps platforms, focusing on the CD aspect by integrating seamlessly with Kubernetes. They help you build an end-to-end CI/CD platform, often working alongside CI tools like Jenkins.
Understanding these fundamentals is the crucial first step toward leveraging the full power of tools like Argo CD to manage complex applications and large-scale infrastructure.
Top comments (0)