Kubernetes Continuous Deployment With Helm Chart And ArgoCD

Senthilkumar.P

5 min readMar 31, 2021

Prerequisites

A running Kubernetes Cluster
The Kubernetes Cluster API endpoint should be reachable from the machine you are running helm.
Authenticate the cluster using kubectl and it should have cluster-admin permissions.

What is Helm?

When deploying an application on Kubernetes, it is required to define and manage several Kubernetes resources such as pods, services, deployments, and replicasets.
Each of these require to write a group of manifest files in YAML format.
In the context of a complex application deployment it becomes a difficult task to maintain several manifest files for each of these resources. Furthermore, templating the manifest files and providing configuration parameters externally, can become crucial which will allow to customize the deployments.
Dependency management and version control are some other important factors to consider as well. This is where Helm plays a vital role in automating the process of installing, configuring and upgrading complex Kubernetes applications.
Helm is a package manager for Kubernetes. It allows developers and operators to easily package, configure, and deploy applications and services on Kubernetes clusters. Helm packages contain Kubernetes object definitions. With Helm, configuration settings are isolated from manifest files. This allows to template and customize settings without changing the entire manifest file.

Helm Architecture

In helm 3 there is no tiller component. Helm client directly interacts with the kubernetes API for the helm chart deployment.

Creating a Chart

Helm CLI, is quite handy in creating a chart

helm create hello-world

Please note that the name of the chart provided here will be the name of the directory where the chart is created and stored.

Let’s quickly see the directory structure created for us:

hello-world /
  Chart.yaml
  values.yaml
  templates /
  charts /
  .helmignore

Let’s understand the relevance of these files and folders created for us:

Chart.yaml: This is the main file that contains the description of our chart
values.yaml: this is the file that contains the default values for our chart
templates: This is the directory where Kubernetes resources are defined as templates
charts: This is an optional directory that may contain sub-charts
.helmignore: This is where we can define patterns to ignore when packaging (similar in concept to .gitignore)

Note: Refer this URL for Helm Installation — https://helm.sh/docs/intro/install/

What is ArgoCD?

ArgoCD is a declarative, GitOps Continuous Delivery tool for Kubernetes. This is considered as CONTAINER TOOL

Advantages Of ArgoCD

Very simple installation process
Declarative and version controlled application deployments
Automation and traceability via GitOps workflow
Support for helm, kustomize and jsonnet application declarations
A web UI for visualizing Kubernetes resources
A command line interface application
A Grafana metrics dashboard
Parameter overrides of helm/ksonnet declarations (simplifies development deployments)
Audit trails for application events and API calls

Why ArgoCD?

The biggest drawback in our CI/CD pipeline was that configuration management of applications across environments and clusters. Whenever there was a change or new feature for our applications, we had to apply these changes manually or maintain jobs with specific kubeconfigs for each cluster to automatically make deployments.

We wanted to automate all of these processes and become closer to Continuous Deployment. And that’s how we discovered ArgoCD.

We are able to make deployments to different environments and clusters from a single source of truth.
Deployment, ConfigMap or Istio config changes are reflected to all production clusters dynamically and instantly.
It provides us the two sided syncing feature. ArgoCD recognizes the changes on our configurations and start syncing Kubernetes and also, it notices any deviation on the Kubernetes side and sync it back to the desired state. Without ArgoCD, Kubernetes resources would be unsync until the next deployment.
If we want to relocate an application from a cluster to another cluster (maintenance work might happen by DevOps team), just one line change in the target clusters works.
We are able to follow sync situation of our desired and current status of applications and be aware instantly of any undesired event on Kubernetes resources with ArgoCD UI and it’s notifications.
When we want to increase the number of replicas, we had to wait for Gitlab jobs in the pipeline to schedule and run. Now it’s just a change in the Git repository and we are able to scale up instantly.

Note: Refer this url for ArgoCD Installation — https://argoproj.github.io/argo-cd/getting_started/

Application Deployment

We have this Sample Spring Boot application in below GitHub repository,

https://github.com/senthilkumar-ps/HelloKubernetes-App.git

Step1: Dockerize the application using this DockerFile and push the image to DockerHub

Step2: Create a Helm Project — “Refer above topic Creating a Chart”

Step3: Copy Chart files and paste those files in project root directory.

Step4: Open values.yaml file, replace the default values of replicaCount, repository, tag and serviceType with appropriate values of our application

Helm Chart values.yaml file

Step5: Configure Project in ArgoCD

ArgoCD Create a New Application Configuration

Step6: Once the ArgoCD application is created, it will deploy the Spring Boot application in Kubernetes Cluster

Step7: Once our application deployed successfully, get the External-IP to access the application

kubectl get svc

Step8: Navigate the URL http://External-IP:Port

Clean Up

Delete the Project

Note: While Deleting the application it will delete corresponding Deployment, Service and PODS from Kubernetes Cluster for deployed application

Conclusion

We have successfully created a Kubernetes Continuous Deployment With Helm Chart and ArgoCD, deployed a sample Spring Boot application in Kubernetes Cluster. Hope you find this article useful.