The term DevOps refers to the culture and set of practices aimed at shortening the software development lifecycle by bringing development and operations teams closer together—teams that traditionally worked in isolation. DevOps originates from agile methodologies and is mainly based on automating tasks and constantly monitoring them. As it has been applied in various fields, other related concepts have emerged, such as MLOps, DevSecOps, DataOps, etc. So it is reasonable to ask: Is it possible to apply these principles to infrastructure management?
The answer is yes. GitOps is an evolution of DevOps that involves using Git repositories as the single source of truth for infrastructure state. Through practices and tools such as Infrastructure as Code (IaC) and CI/CD pipelines, the goal is to ensure that the system’s state, as described by the repository files, exactly matches its actual state. Some of the most notable advantages include:
- Automation: The code and configurations that lead to the current state are stored in a repository accessible to the team. In case of failure, it is possible to automatically reproduce the infrastructure’s state.
- Transparency and visibility: The Git repository itself serves as documentation of the system’s state. Anyone with access can know exactly what configurations are being applied, as Git acts as the single source of truth.
- Version control: Since Git is a version control system, it allows tracking every change made to the infrastructure, making it easy to perform rollbacks in case of errors or to review its history.
GitOps and Kubernetes
One of Kubernetes’ key features is its declarative nature. Cluster resources such as Pods, Deployments, Ingress, Service, etc., can be created declaratively using yaml files, called manifests. What happens if an Ingress is deleted? If we keep its definition, it’s enough to reapply it, and Kubernetes will handle the necessary changes. But what if this process could be automated to the point that the system itself detects missing resources and recreates them?
The term GitOps originated in this context, but one component is still missing: “the controller.” The controller is the software responsible for reconciling the state of the repository with the state of the cluster. To do this, the controller must be able to connect to the cluster, monitor existing resource definitions, and compare them to those in the repository. If it detects a difference, it will synchronize them and take the necessary actions to fix it, including creating, deleting, and updating resources.
What is ArgoCD?
ArgoCD is a declarative continuous deployment (CD) tool that enables GitOps in Kubernetes. ArgoCD is a Kubernetes controller that continuously monitors the applications currently running (actual state) and compares them with the desired state. If these two states differ, ArgoCD will mark the application as OutOfSync and offer the option to synchronize it either automatically or manually through a web interface or CLI.
Practical example: Modifying a Deployment
Suppose we want to manage a set of Kubernetes resources using GitOps, and we want to use ArgoCD to do so. Initially, you need to have a Git repository and a Kubernetes cluster with ArgoCD installed. There are several ways to install it (e.g., via Helm). In this case, we assume ArgoCD has been installed in the same Kubernetes cluster, although this is not always necessary.
For this example, the following Deployment will be deployed:
RArgoCD determines which resources to manage through Applications. An Application is a Custom resource (CR) specific to ArgoCD that contains information about where to find the manifests and where to apply them.
With this application, ArgoCD will be configured as follows:
- Desired state: The manifests directory from the main branch of the gitops-workshop Git repository.
- Actual state: The contents of the nginx namespace in the Kubernetes cluster where ArgoCD is running.
Note: Applications can also be created from the Web UI or the CLI. Both methods end up generating the same resource.
By accessing ArgoCD’s web interface, you will see that the nginx application has been created. It will appear as OutOfSync since the deployment in the repository does not yet exist in the cluster. To fix this, click the Sync button.
If everything went well, a few moments later the application will change to Synced, and you can verify that ArgoCD has created the resource.
To illustrate how ArgoCD works, we can modify a parameter in the resource. The following command reduces the number of replicas in the deployment to 1:
$ kubectl scale deploy nginx-deployment –replicas=1 -n nginx
After running it, we will see that the application becomes OutOfSync again. By clicking on the diff section, we can view the differences between the current state (left) and the desired state (right).
After synchronizing again, ArgoCD will restore the original number of replicas, thus reconciling the cluster with the Git repository’s information. As a result, any changes intended to be made must be registered in the Git repository.
ArgoCD offers a wide range of configuration options, such as ignoring changes in specific resource fields, selecting different creation methods, enabling automatic application synchronization, and more. Its documentation is detailed and covers all its features.
Conclusion
We have seen what the GitOps paradigm consists of and how it can be applied to manage Kubernetes clusters using ArgoCD. However, its application is not limited to this field: due to the benefits GitOps offers, in recent years other solutions have emerged to apply these practices in different contexts, such as cloud infrastructure deployment with Terraform. Today, GitOps is an established reality in many IT systems and is a recommended paradigm when starting a project of this nature.