GitOps CD for Kubernetes: ARGOCD

Hello Readers!! We are again back with an exciting topic i.e. GitOps CD for kubernetes which is ArgoCD. We will get to know all about ArgoCD, what it is and how can we use it. It is a gitops tool that is gaining popularity in the devops world which is called ArgoCD. It is a continuous delivery tool uses git as single source of truth.

CD Workflow without ArgoCD:

1. Install and setup tools, like kubectl or helm etc to access kubernetes cluster and execute changes on those build automation tools.
2. Configure access to K8s, configure credentials for kubernetes cluster in jenkins.
3. Configure access to cloud platforms.
4. Security challenge.
5. No visibilty of deployment status.

CD Workflow with ArgoCD:

1. CD part can be improved with ArgoCD for Kubernetes. It makes it more effiicient with github’s principles.
2. When deploying using ArgoCD, ArgoCD is part of K8s cluster. ArgoCd agent pulls K8s manifest changes and applies them. Agent in the cluster which is argocd and pull those changes and applies them there.
3. Deploy ArgoCD in K8s cluster.
4. Configure ArgoCD to track git repository.
5. ArgoCD monitors for any changes and applies automatically. Pulls those changes and applies them in the cluster.

For this we must follow best practice for Git Repository:

1. Separate git repository for application source code and application configuration(k*s manifest files).
2. Manage even separate git repository for system configurations if possible.

ArgoCD supports:

1. Kubernetes YAML files
2. Helm charts
3. Kustomize
4. Template files that generates K8s manifests.

What happens if someone updates the cluster manually?

ArgoCD watches the changes in the git repository, as well it also watches the changes in the cluster as well. ArgoCD compares desired configuration in the git repo with the actual state in the k8s cluster. Here it finds that the desired state in the git repository is not the actual life state in the cluster. It always sync whatever is defined in the git repository with the cluster.

So, in that case if someone goes and makes manual changes in the cluster, ArgoCD will detect that. It will sync the changes, overwrites the manual change. It guarantees that K8s manifests in git remains single source of truth for your cluster state and it also gives us full cluster transparency. ArgoCD makes sure that whatever is defined in that git repository as a configuration code is exactly the state which you have in the cluster.

We can use git as a single interface for making changes in the cluster instead of untrackable kubectl apply commands. We have each changes documented in the version controlled system, keeps history of changes and audit of who changed what in the cluster. Its best for team collaboration. It gives teams a way to collaborate on any changes in the cluster like proposing a change in kubernetes which other can discuss and work on and when done just merge those changes in the main branch.

Another benefit is easy rollback. ArgoCD sync the changes with the git repository in the cluster. If something breaks with these changes or let’s say a new application version fails to start, we can revert to the previous working state in the git history. Basically, by moving back to the last working version. For example, we have thousands of cluster deployed using this, here we don’t need to manually revert each and every component doing kubectl or helm. We can simply declare previous working state and clusters will be synced to that state.

Another most important advantage is cluster disaster recovery. With this setup ArgoCD makes it super easy in this scenerio. Let’s say we have an eks cluster in a region 1-a and that cluster completely crashes. We can easily create a new cluster point it to the git repository where the complete cluster configuration is defined and it will recreate the same exact cluster state as the previous one without any manual intervention.

These are basically gitops principles. ArgoCD is based on gitops and helps implement those gitops principles.

K8s Acces Control with Git:

1. We should take care that not everyone should have acess to k8s cluster especially in a production environment.
2. Here we can configure access rules easily with git repositories. If any team wants to make changes, they can make pull request. And after approval those changes are merged for the deployment. It gives us a clean way of managing cluster permissions indirectly via git. Here we don’t need to create any ClusterRole and user resources in kubernetes.
3. Also, here we don’t need to give external cluster access to non human users, lets say jenkins or any other tool. This doesn’t expose cluster credentials outside of k8s because here the agent is running inside the cluster. This is how we can take benefit of easy cluster access management using ArgoCD.

That’s all for now. In my next blog we will see implementation of it. Thanks for being with me till here.

Conclusion:

Thanks for being with me till end. In this blog we have learnt all about ArgoCD. How we can use it as a gitops CD tool for kubernetes. Its quite really interesting and easy to explore. If this blog helped you somewhere do like and share this blog with the needful. 
HAPPY READING!!!