Using Helm Charts with ArgoCD: Streamlining Kubernetes Deployments

@Harsh
5 min readDec 3, 2024

--

In this blog, we will explore the integration of Helm and ArgoCD, a powerful combination for managing Kubernetes applications. Helm simplifies Kubernetes deployment with reusable, parameterized templates, while ArgoCD automates and reconciles those deployments with GitOps principles. Here’s a breakdown of the concepts, practical steps, and examples we covered.

Introduction to Helm

Helm is a Kubernetes package manager that enables you to define, install, and manage applications through charts. A Helm chart is a collection of files that describe Kubernetes resources and their configurations.

Benefits of Helm

  • Reusability: Write a chart once and use it across multiple projects or environments.
  • Parameterization: Customize deployments using values files or CLI parameters.
  • Simplified Updates: Upgrade or rollback applications with minimal effort.
  • Versioning: Charts are versioned, providing traceability and easier troubleshooting.

Basic Helm Operations

To understand Helm better, we performed several basic operations:

1. Creating a Helm Chart

Helm makes it simple to scaffold a new chart:

helm create <demo-chart>

This command generates a directory structure like this:

demo-chart/  
├── Chart.yaml # Metadata about the chart
├── values.yaml # Default values for the chart
├── charts/ # Dependencies
├── templates/ # YAML templates for Kubernetes resources
└── README.md # Chart documentation
  • A parametrized deployment and service files.

2. Installing a Helm Chart

After customizing the values.yaml file or providing overrides, you can deploy the chart to your Kubernetes cluster:

helm install demo-release demo-chart/
  • demo-release: Name of the Helm release.
  • demo-chart/: Path to the chart.

Helm translates the chart into Kubernetes manifests and applies them to the cluster.

3. Uninstalling a Helm Chart

Removing the deployed chart is equally simple:

helm uninstall demo-release

This cleans up all resources created by the chart.

Using Helm with ArgoCD

Once we understood Helm basics, we integrated it with ArgoCD. This allows Helm to handle the application configuration while ArgoCD manages deployment automation and synchronization with Git.

1. Preparing the Chart

We committed and pushed the Helm chart (demo-chart/) to a GitHub repository:

git add demo-chart/  
git commit -m "helm chart"
git push

2. Creating an ArgoCD Application with a Helm Chart

Next, we created an ArgoCD application using a manifest file. ArgoCD automatically detects that the path points to a Helm chart and manages it accordingly.

Example Application Manifest:

apiVersion: argoproj.io/v1alpha1  
kind: Application
metadata:
name: web-helm
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/harsh2478/GitOps-Training.git'
targetRevision: HEAD
path: chart1
helm:
releaseName: chart1
destination:
server: 'https://kubernetes.default.svc'
namespace: default
syncPolicy:
automated:
prune: true

Key Components Explained

  • source.repoURL: The GitHub repository containing the Helm chart.
  • path: The directory where the chart is located.
  • destination: Kubernetes cluster and namespace where the application will be deployed.
  • syncPolicy: Automates deployment and ensures the application state matches Git. prune here means that argocd will remove the resource from the cluster that no longer defined in git repository.
  • We can also add the parameters in this manifest which we want to override from the value.yaml using parameters keyword.
apiVersion: argoproj.io/v1alpha1  
kind: Application
metadata:
name: web-helm
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/harsh2478/GitOps-Training.git'
targetRevision: HEAD
path: chart1
helm:
releaseName: chart1
parameters:
- name: "replicaCount"
value: "5"
destination:
server: 'https://kubernetes.default.svc'
namespace: default
syncPolicy:
automated:
prune: true
  • Or we can also put these parameters in separate file and then mention that file name here using the keyword valueFiles

3. Deploying the Application

  1. Apply the Manifest:

ArgoCD pulls the Helm chart from GitHub, applies the specified values and parameters, and deploys the application to Kubernetes.

4. Using valueFiles keyword.

Helm charts are highly customizable using values.yaml files and parameter overrides. You can specify different files for different environments (e.g., dev-values.yaml, prod-values.yaml).

  • Here we can create a file named myvalues.yaml and put all the parameters there that we want to override.
  • Commit and push the changes to github.
  • Configure the manifest and apply it.
apiVersion: argoproj.io/v1alpha1  
kind: Application
metadata:
name: web-helm
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/harsh2478/GitOps-Training.git'
targetRevision: HEAD
path: chart1
helm:
releaseName: chart1
valueFiles:
- myvalues.yaml
destination:
server: 'https://kubernetes.default.svc'
namespace: default
syncPolicy:
automated:
prune: true
  • We can see that it is automatically adjusted and scaled down to 2 replicas as mentioned in myvalues.yaml

Key Takeaways from the Blog

  1. Helm Simplifies Kubernetes Configurations: By using templates and parameterized values, Helm makes application deployment efficient and reusable.
  2. Helm + ArgoCD = Perfect Synergy: ArgoCD manages Helm deployments with GitOps principles, ensuring consistent and automated workflows.
  3. Value Files and Parameters: Enable environment-specific configurations without modifying the chart itself.
  4. ArgoCD Handles Everything: With Helm providing the structure and ArgoCD managing the flow, Kubernetes deployments become seamless.

Conclusion

Integrating Helm with ArgoCD is a game-changer for managing Kubernetes deployments. Helm’s templating capabilities combined with ArgoCD’s GitOps automation provide a robust and scalable solution for modern DevOps workflows. This blog solidified my understanding of how these tools complement each other, and the practical steps highlighted their real-world applicability.

--

--

@Harsh
@Harsh

Written by @Harsh

A devOps engineer from India

No responses yet