Helm charts Package Management and Application Deployment Best Practices for Kubernetes

Hello DevOps Engineers, DevSecOps Professionals, SREs, Platform Engineers, and Kubernetes Enthusiasts!

As Kubernetes adoption grows, managing large numbers of YAML manifests becomes increasingly difficult. A typical application deployment may require multiple Kubernetes objects such as:

• Deployments
• Services
• ConfigMaps
• Secrets
• Ingress Resources
• Horizontal Pod Autoscalers (HPA)
• Service Accounts

Managing all these resources individually can quickly become complex and error-prone.

This is where Helm comes into the picture.

Helm is the most widely used package manager for Kubernetes and is often referred to as the "apt" or "yum" of Kubernetes."

In this blog post, we'll learn & explore:

• What Helm is
• Why Helm is important
• How Helm Charts work
• Installing Helm on Linux
• Creating and validating Helm Charts
• Deploying applications using Helm
• Customizing deployments with values files
• Best practices for production environments

What is a helm chart? 

Helm is a package manager for Kubernetes that simplifies the deployment and lifecycle management of applications.

Using Helm, you can:

• ✅ Install applications
• ✅ Upgrade existing deployments
• ✅ Roll back failed releases
• ✅ Manage configuration changes
• ✅ Uninstall applications cleanly
• ✅ Reuse deployment templates across environments

Instead of maintaining dozens of YAML files manually, Helm allows you to package everything into a reusable Chart.

Helm Charts Kubernetes Deployment

Why Helm Charts Matter?

Without Helm, deploying an application typically involves managing multiple YAML manifests:

deployment.yaml
service.yaml
ingress.yaml
configmap.yaml
secret.yaml
hpa.yaml

As applications grow, maintaining these files becomes challenging.

Helm solves this problem by packaging all Kubernetes resources into a single deployable unit called a Chart. A Helm Chart typically contains:

• Application Name
• Description
• Version Information
• Kubernetes Resource Templates
• Default Configuration Values

This enables teams to deploy applications consistently across: Development, QA, Staging, Production environments with minimal changes.

Understanding Helm Chart Components

A Helm Chart consists of three important components:

1. Chart.yaml

Contains metadata about the application.

Example:

apiVersion: v2
name: myapp
description: Sample Helm Chart
version: 1.0.0

---

2. values.yaml

Contains configurable parameters.

Example:

replicaCount: 2

image:
  repository: nginx
  tag: latest

service:
  type: ClusterIP
  port: 80

---

3. Templates Directory

Contains Kubernetes YAML templates.

Example:

spec:
  replicas: {{ .Values.replicaCount }}

At deployment time, Helm replaces placeholders with actual values from values.yaml.

This approach provides flexibility and reusability.

Prerequisites 

Before starting with Helm, ensure the following:

• Kubernetes cluster up and running.
• kubectl confiugured
• Basic understanding on Kubernetes deployment, ReplicaSet, and pods
• Familiarity with YAML syntax

Installing Helm on Linux

There are multiple installation methods available:

1. Package Manager
2. Installation Script
3. Binary Download (recommended for learning)

To install Helm on Ubuntu using binary: 

Step 1: Download Helm

Always check the latest release from the official Helm website before downloading.

wget https://get.helm.sh/helm-v3.6.1-linux-amd64.tar.gz

helm Charts download on Linux box

check the latest version on the official website for the "helm charts"

Step 2: Extract the Package

Next, untar the Helm binary installer file using the tar command:

tar xvf helm-v3.6.1-linux-amd64.tar.gz

Step 3: Move Binary to PATH

Move the linux-amd64/helm file to the /usr/local/bin directory:

sudo mv linux-amd64/helm /usr/local/bin

There will be no output if the command was executed correctly.

 

Step 4 Verify helm installation

Confirmation of helm installation by checking the version 

helm version

The execution output as follows:

helm version check in Linux

Expected output:

version.BuildInfo{Version:"v3.x.x"}

If you see version information, Helm is successfully installed.

Creating our First Helm Chart

To create "charts" using helm package manager as the following command:

helm create mytest

Helm can automatically generate a starter chart structure. Helm creates 'mytest' folder in the current directory, you see the directory structure as :

# tree  mytest/
mytest/
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

The generated chart follows Kubernetes best practices and provides a reusable starting point.

Understanding Generated Resources

The default chart includes templates for:

Resource	Purpose
Deployment	Application Pods
Service	Internal Networking
Ingress	External Access
HPA	Auto Scaling
Service Account	Authentication
Tests	Deployment Validation

This makes Helm an excellent choice for deploying microservices.

Helm will be a ready-made tool for huge application pods running environments. In the example charts it will be nginx image-based deployment. Most of the common strategies used for Kubernetes deployment and scaling in a declarative way is completely templatized which can be reusable by rending the charts with custom values. As more images used in the project then values.yaml file will grow. 

Validate Helm Chart Syntax

Before deployment, validate the chart. Make lint checking as habit when you do the changes:

helm lint ./mytest 

The lint command execution output

The helm lint example

This command checks:

• YAML syntax
• Template issues
• Chart configuration problems

A successful lint operation indicates the chart is ready for rendering.

Rendering templates with Dry-run Validate 

Before deploying to Kubernetes, it's a good practice to preview the generated manifests.

helm install --dry-run \
--debug ./mytest/ \
--generate-name

Benefits:

• Detect template errors
• Verify values rendering
• Prevent failed deployments

This is one of the most important Helm troubleshooting technique

Deploy Application Using Helm

Deploy the chart:

helm install web-test  ./mytest/

But if you want to change any specific change you can use the --set option to override the value at the time of installing it will be considered. Example if you see service.YAML file type will be rendered from values.yaml file as type: ClusterIP, that can be overridden when you use --set service.type=NodePort

helm install web-test  ./mytest/  --set service.type=NodePort 

Helm creates a release named:

web-test

and deploys all Kubernetes resources. Same thing you can do by changing inside the values.yaml file as well.

Override Values During Deployment

One of Helm's most powerful features is runtime configuration.

Suppose your service is configured as:

service:
  type: ClusterIP

You can override it without modifying values.yaml:

helm install web-test ./mytest \
--set service.type=NodePort

This makes environment-specific deployments much easier.  

Verify Deployment

Check installed releases:

helm list

Example output:

NAME       NAMESPACE STATUS
web-test   default   deployed

You can also verify Kubernetes resources:

kubectl get all

Upgrade Existing Releases

To apply changes:

helm upgrade web-test ./mytest

Helm updates only the modified resources.

Roll Back Failed Releases

If an upgrade causes issues:

helm rollback web-test 1

This restores the previous working version.

This feature is one of the biggest reasons enterprises adopt Helm.

Check the application URL that is running with notes instruction tells the URL creation commands. 

Screen 1 Nginx app accessed

Verify the helm installed deployment successful using list command as:

helm list

How to uninstall the release package? 

Using the uninstall followed by the name of the application release will delete that.

helm uninstall web-test

This removes all Kubernetes resources associated with the release.

---

  Enable Auto-Completion for Helm CLI

To use the auto-completion on for helm commands you can do the following:

source <(helm completion bash)

test this functionality by typing the 'helm cr<tab key>' it should complete with 'helm create'.

Helm chats Best Practices

When using Helm chats in enterprise environments:

1. Use Separate Values Files for each environment

values-dev.yaml
values-qa.yaml
values-prod.yaml

Deploy prod environment by specifying -f option with the dedicated values file values-prod.yaml:

helm install \
-f values-prod.yaml

2. Store Charts in Git

Version-control all charts and values files.

Benefits:

• Auditing
• Rollbacks
• Collaboration
• CI/CD Integration

3. Validate Before Deployment

Always run:

helm lint
helm template
helm install --dry-run

before production deployments.

4. Use Secrets Management

Avoid storing sensitive values directly in: values.yaml

Better to use:

• External Secrets
• HashiCorp Vault
• Kubernetes Secrets
• Sealed Secrets

Reader Challenge

Ready to practice Helm?

Challenge 1

Create a Helm Chart for:

• NGINX
• Apache HTTPD
• Tomcat

Deploy all three using separate values files.

---

Challenge 2

Modify the generated chart to:

• Change replicas from 1 to 3
• Enable NodePort service
• Configure resource limits

Verify the rendered output using:

helm template

---

Challenge 3

Simulate an application upgrade and perform a rollback.

Commands to use:

helm upgrade
helm history
helm rollback

Observe how Helm tracks release revisions.