Implementing GitOps with Kubernetes: A Guide to Configure on Argo CD

In our last article ‘Ask PALO: What is GitOps’, we covered a brief introduction of what it is, its benefits and its core principles. In this article, we will explain in more depth, the implementation technicalities involved in GitOps. 

GitOps & Kubernetes

GitOps and Kubernetes are used together because they are both designed to manage distributed systems in a declarative and automated way. 

In GitOps, Kubernetes is used as the platform for running and managing applications and services, while Git is used as the single source of truth for the configuration of the system. This allows for the use of Kubernetes' powerful orchestration capabilities to manage the deployment, scaling, and rolling updates of applications and services, while also providing the benefits of versioning, collaboration, and auditing of changes through Git.  

One of the key components in GitOps for Kubernetes is the use of a tool called a GitOps operator. This is a software component that runs in the cluster and watches for changes to the Git repository. When a change is detected, the operator will automatically update the cluster to match the desired state defined in the repository. This allows for a closed-loop deployment process where changes to the application and services are automatically deployed, tested and verified.  

GitOps and Kubernetes are related in that they can be used together to declaratively manage the configuration of a Kubernetes cluster. With GitOps, you store the desired state of your Kubernetes cluster in a Git repository, and use automation tools to ensure that the actual state of the cluster matches the desired state. 

When using GitOps with Kubernetes, you can use Kubernetes manifests (written in YAML) to define the desired state of your cluster, including the deployment of applications and services, the scaling of resources, and the configuration of network policies. These manifests are stored in a Git repository, and changes to them are tracked and versioned. 

An operator or a controller running in the cluster, watches for changes in the git repository, and when changes happen it will automatically update the cluster accordingly. This way, you can ensure that the cluster is always in the desired state, and can easily roll back changes if needed. 

GitOps Providers

GitOps providers are tools or platforms that can be used to implement GitOps practices in your organization. These providers can help automate the process of ensuring that the actual state of a system matches the desired state defined in a Git repository. Some popular examples of GitOps providers include: 

1. ArgoCD: An open-source GitOps tool for Kubernetes that can synchronize your application manifests with your Git repository, and automatically deploy changes to your cluster.
2. FluxCD: An open-source GitOps tool for Kubernetes that can automatically deploy changes to your cluster based on changes to your Git repository.

Argo CD is the most popular open-source Kubernetes GitOps tool on the market because it’s easy to set up and has a great GUI and dashboard, hence we will use it for the demo purpose. 

What is ArgoCD

ArgoCD is a Kubernetes-native continuous deployment (CD) tool. Unlike external CD tools that only enable push-based deployments, Argo CD can pull updated code from Git repositories and deploy it directly to Kubernetes resources. One of the key benefits of Argo CD is its ability to detect and correct configuration drift, which can occur when manual changes are made to the application or infrastructure. Argo CD continuously monitors the desired state of the system and automatically reconciles any differences between the desired and actual states. 

ArgoCD Architecture: 

How to configure ArgoCD 

Pre-Requisites

1. Kubernetes Cluster 
2. Git Repository 

Deploy ArgoCD to Kubernetes, and it will extend the Kubernetes API using custom resource definitions (CRDs). This allows us to configure ArgoCD using yaml files where we put the information of source, i.e., git repository, and destination, i.e., the k8s cluster, which can be any Kubernetes cluster, including the one that ArgoCD is running in, or external cluster which ArgoCD is managing. 

Even though we have many clusters in various areas, just one instance of ArgoCD needs to be set up in order for it to control the entire k8s cluster. 

If we have different cluster environments, such as deployment, staging, and production, we will deploy ArgoCD separately. However, there is only one git repository where all the code and configuration are stored, so whenever any changes are made, we will first test them on each environment before promoting them to the next one. 

Demo: 

1. Create an argocd namespace. 
   kubectl create namespace argocd
   
2. Install ArgoCD. 
   • Using manifest (declarative) 
     kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml 
     
     OR
     
     
   • Using helm. 
     helm repo add argo https://argoproj.github.io/argo-helm 
     helm install my-argo-cd argo/argo-cd --version 5.19.6 
   
   
3. The initial password for the admin account is auto-generated and stored as clear text in the field password in a secret named argocd-initial-admin-secret in your Argo CD installation namespace. You can simply retrieve this password using kubectl. 
   
   • kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo 
     
4. You can quickly access the UI by forwarding the port. 
   • kubectl port-forward svc/argocd-server -n argocd 8080:443 
     
5. Open browser and access the endpoint  
   http://localhost:8080 
   
   
6. You will see this UI after entering your username and password. 
   
   
7. A git repository is required to be configured.
   
   
8. Apps can be created using the UI and once it is created, it will show up like this.
   
   
9. The app is out of sync as can be seen in the screenshot above, to get it back in sync, use the sync button.
   
   
10. It will display the status after syncing whether the pods are healthy or degrading, for example as shown in above screenshot as healthy (green). 

In conclusion, Argo CD is a powerful tool that simplifies the deployment of applications and infrastructures in a variety of environments. Its declarative configuration model, robust API, and extensive set of features make it an ideal choice for teams that want to streamline their workflows and reduce the risk of human error. 

Overall, Argo CD is a valuable addition to any DevOps toolchain, and its benefits can be realized by teams of all sizes and experience levels. With Argo CD, teams can accelerate their application development and deployment processes, while maintaining a high level of control and visibility over their infrastructure. 

 I hope this tutorial was informative, if you have any questions, please feel free to email me.