ARGOCD

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. It enables developers to manage both infrastructure configuration and application updates
in one system.

There are many features of ArgoCD :

1. Whole Kubernetes configuration defined as code in GIT Repository.

2. Web user interface and command-line interface (CLI).

3. It has easy rollback mechanism through which we can rollback our changes to any previous state.

4. It has cluster disaster recovery feature which helps to create the exact cluster if cluster dies because all codes
are present in GIT.

5. It contains Kubernetes access control with GIT.

6. Single sign-on (SSO) with providers such as GitLab, GitHub, Microsoft, OAuth2, OIDC, LinkedIn, LDAP,
and SAML 2.0

7. Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

8. Ability to visualize deployment issues, detect and remediate configuration drift.

What are the challenges which Jenkins have and ArgoCD solves ?

Challenges with this Approach ??

1. We need to install tools like kubectl on Jenkins.

2. Give access of Kubernetes cluster in Jenkins.

3. Configure access to cloud platform in Jenkins.

4. There is no visibility of deployment status in Jenkins.

CD Workflow using ArgoCD

1. A developer makes changes to an application, pushing a new version of Kubernetes resource definitions to a
Git repo.

2. Continuous integration is triggered, resulting in a new container image saved to a registry.

3. A developer issues a pull request, changing Kubernetes manifests, which are created either manually or
automatically.

4. The pull request is reviewed and changes are merged to the main branch. This triggers a webhook which tells
Argo CD a change was made.

5. Argo CD clones the repo and compares the application state with the current state of the Kubernetes cluster. It
applies the required changes to cluster configuration.

6. Kubernetes uses its controllers to reconcile the changes required to cluster resources, until it achieves the
desired configuration.

7. Argo CD monitors progress and when the Kubernetes cluster is ready, reports that the application is in sync.

8. ArgoCD also works in the other direction, monitoring changes in the Kubernetes cluster and discarding them
if they don’t match the current configuration in Git.

STEP 1: SETUP KOPS OR MINIKUBE CLUSTER.

• In my case I set-up kops cluster

STEP 2: INSTALL ARGOCD

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

STEP 3: EXPOSE ARGO CD SERVER

By default, Argo CD is not accessible outside the cluster. To expose it, you can use a LoadBalancer service
(since your kOps cluster should be configured to support it).

1. Edit the Argo CD service to change the argocd-server service type:

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

(or)

you can expose the Argo CD server externally by editing the Argo CD server service type.

kubectl edit svc argocd-server -n argocd

Change the type from ClusterIP to LoadBalancer to get an external IP address.

STEP 4: ACCESS ARGO CD

Once you have the LoadBalancer IP or DNS, you can access the Argo CD UI at http://<LoadBalancer-I.

STEP 5: RETRIEVE THE INITIAL ADMIN PASSWORD

To log in, use the default admin credentials. Get the password with:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

Use admin as the username and the retrieved password.

(or)

Username: admin

To get password:

Get secrets :

kubectl get secrets -n argocd

• Copy the password and decode the it.

STEP 6: CONNECT A GIT REPOSITORY

1. Go to the Argo CD UI and log in.

2. Set up a new project with your Git repository details.

3. Configure the repository settings, sync policies, and deployment specifications.

• Click on Create application.

• Application Name: Choose a unique name for the application.

• Project: Select a project (default project is available by default).

• Sync Policy: This defines whether Argo CD should automatically sync the application to match the Git
repository or wait for manual approval.

o Automatic: Argo CD will automatically apply changes detected in the Git repo.

o Manual: You need to trigger deployments manually from the UI or CLI.

• Repository URL: URL of your Git repository containing the manifests.

• Revision: Specify a branch (e.g., main), tag, or commit SHA for the desired state version.

• Path: Path within the Git repo where Kubernetes manifests or Helm charts are located.
2. Specify the Target Cluster and Namespace

Define where you want the application to be deployed:

• Cluster URL: Usually, this is set to the same cluster where Argo CD is running
(https://kubernetes.default.svc), but it can be a different cluster if you’ve configured multi-cluster
support.

• Namespace: The Kubernetes namespace in which to deploy the application. Make sure the namespace
exists in the cluster or create it manually.

• The app is synced successfully.

• Even when You see the k8s cluster we get running pods.

• Click on service

• Copy the LoadBalancer DNS

• Access the application using LoadBalancer DNS.

If you make manual changes to resources in your Kubernetes cluster, Argo CD will notice these changes and
mark the application as "Out of Sync" with what’s in the Git repository.

Here’s how to handle it:

1. Automatic Sync: If auto-sync is enabled, Argo CD will automatically revert the changes in the cluster
to match the Git state.

2. Manual Sync: If using manual sync, you’ll see an "Out of Sync" status in the Argo CD UI. You can
click Sync in the UI or run argocd app sync <app-name> in the CLI to manually reapply the Git
configuration to the cluster.

3. Keeping Manual Changes: If you want to keep the manual changes, update the same changes in your
Git repository, then commit and push. Argo CD will detect this update and sync accordingly.

• Now, let’s manually change the deployment yaml file from the cluster configuration → Changed
replica count from 3 to 5.

It will discard the changes which we have done manually because ArgoCD follows Git as the single source of
truth. So, what happens at the background is it checks the cluster desired with the actual state of Git and revert
the changes.

When you make changes directly in your Kubernetes cluster (e.g., updating a deployment or modifying
resources without using Argo CD), Argo CD detects that the cluster’s actual state no longer matches the desired
state defined in the Git repository. This state mismatch causes Argo CD to label the application as “Out of
Sync.”