10.05 Helm Charts

Abstract

Helm Charts are the instruction manuals Helm uses to deploy Kubernetes applications.

A chart packages Kubernetes manifests, templates, default values, metadata, documentation, and dependencies into one reusable application package.

What Is a Helm Chart?

A Helm Chart is a collection of files that tells Helm how to install, upgrade, rollback, and uninstall an application in Kubernetes.

Instead of applying many YAML files manually, Helm reads the chart and performs the required Kubernetes actions.

Note

Helm is the tool.
A chart is the package.
A release is the installed instance of that chart.

Why Helm Charts Are Used

Without Helm, deploying an application may require many separate YAML files:

Deployment
Service
ConfigMap
Secret
PersistentVolumeClaim
Ingress
ServiceAccount
RBAC resources

With Helm, these objects are grouped into one chart and installed using one command:

helm install hello-world ./hello-world-chart

Success

Helm charts make Kubernetes applications easier to install, customize, upgrade, and manage.

Helm Chart Example

A simple hello-world chart may deploy:

Kubernetes Object	Purpose
Deployment	Runs application pods
Service	Exposes application pods
values.yaml	Stores configurable values
Chart.yaml	Stores chart metadata

Example:

hello-world-chart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    └── service.yaml

Templates

The templates/ directory contains Kubernetes YAML files with dynamic placeholders.

Example deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: "{{ .Values.image.repository }}"
        ports:
        - name: http
          containerPort: 80
          protocol: TCP

The placeholders are replaced using values from values.yaml.

Example

{{ .Values.replicaCount }} is replaced with the replica count defined in values.yaml.

values.yaml

The values.yaml file stores configurable values for the chart.

Example:

replicaCount: 3

image:
  repository: nginx

When Helm renders the chart:

replicas: {{ .Values.replicaCount }}

becomes:

replicas: 3

and:

image: "{{ .Values.image.repository }}"

becomes:

image: "nginx"

Tip

Most chart customization is done through values.yaml, not by editing templates directly.

Service Template Example

Example service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: hello-world

This creates a Service that exposes the application pods.

Note

Helm templates are still Kubernetes YAML files. Helm only adds templating support on top of them.

Chart.yaml

Every chart has a Chart.yaml file.

It contains metadata about the chart.

Example:

apiVersion: v2
appVersion: 5.8.1
version: 12.1.27
name: wordpress
description: Web publishing platform for building blogs and websites.
type: application

dependencies:
  - condition: mariadb.enabled
    name: mariadb
    repository: https://charts.bitnami.com/bitnami
    version: 9.x.x

keywords:
  - application
  - blog
  - wordpress

maintainers:
  - email: containers@bitnami.com
    name: Bitnami

home: https://github.com/bitnami/charts/tree/master/bitnami/wordpress
icon: https://bitnami.com/assets/stacks/wordpress/img/wordpress-stack-220x234.png

Chart.yaml Fields

Field	Description
`apiVersion`	Helm chart API version
`appVersion`	Version of the application inside the chart
`version`	Version of the chart itself
`name`	Chart name
`description`	Short chart description
`type`	Chart type: `application` or `library`
`dependencies`	Other charts required by this chart
`keywords`	Search keywords
`maintainers`	Chart owner or maintainer details
`home`	Project homepage
`icon`	Chart or application icon URL

Warning

appVersion and version are different.

appVersion = application version
version = chart package version

Chart API Version

Helm charts support different chart API versions.

Helm Version	Chart API Version
Helm 2	`v1`
Helm 3	`v2`

For Helm 3 charts, use:

apiVersion: v2

Tip

For new charts, use apiVersion: v2 because modern production environments use Helm 3.

Chart Types

Helm supports two chart types:

Type	Purpose
`application`	Deploys an application
`library`	Provides reusable chart helpers/templates

Example:

type: application

Note

Most charts you install in Kubernetes are application charts.

Chart Dependencies

Some applications need other applications.

Example: WordPress needs a database like MariaDB.

Instead of copying MariaDB manifests into the WordPress chart, Helm allows dependencies.

Example:

dependencies:
  - condition: mariadb.enabled
    name: mariadb
    repository: https://charts.bitnami.com/bitnami
    version: 9.x.x

Success

Dependencies help reuse existing charts instead of duplicating YAML files.

Update dependencies:

helm dependency update

Helm Chart Directory Structure

A chart commonly has this structure:

hello-world-chart/
├── templates/       # Kubernetes templates
├── values.yaml      # Configurable values
├── Chart.yaml       # Chart information
├── LICENSE          # Chart license
├── README.md        # Human-readable documentation
└── charts/          # Dependency charts

Path	Purpose
`templates/`	Contains template YAML files
`values.yaml`	Default configuration values
`Chart.yaml`	Chart metadata
`LICENSE`	License information
`README.md`	Documentation and usage guide
`charts/`	Subcharts/dependencies

Tip

Always read the chart README.md before installing production charts.

How Helm Installs a Chart

helm install hello-world ./hello-world-chart
        |
        v
Helm reads Chart.yaml
        |
        v
Helm loads values.yaml
        |
        v
Helm renders templates/
        |
        v
Helm sends final YAML to Kubernetes API
        |
        v
Kubernetes creates resources

Abstract

Helm does not directly run the application.
Helm generates Kubernetes resources, and Kubernetes runs them.

Render Chart Without Installing

Use helm template to see the final Kubernetes YAML.

helm template hello-world ./hello-world-chart

Use dry-run before install:

helm install hello-world ./hello-world-chart --dry-run --debug

Tip

In production, always review rendered manifests before applying charts.

Install a Chart

Install from a local chart directory:

helm install hello-world ./hello-world-chart

Install into a namespace:

helm install hello-world ./hello-world-chart   --namespace demo   --create-namespace

Install with custom values:

helm install hello-world ./hello-world-chart   -f values-prod.yaml

Override Values from CLI

You can override values using --set.

helm install hello-world ./hello-world-chart   --set replicaCount=5   --set image.repository=nginx

Warning

--set is useful for quick testing, but production values should usually be stored in version-controlled values files.

Production values.yaml Strategy

Use separate values files per environment:

values-dev.yaml
values-stage.yaml
values-prod.yaml

Example:

values-dev.yamlvalues-prod.yaml

replicaCount: 1

image:
  repository: nginx
  tag: "1.25"

service:
  type: ClusterIP

replicaCount: 3

image:
  repository: nginx
  tag: "1.25"

service:
  type: LoadBalancer

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Success

Environment-specific values files make Helm deployments repeatable and GitOps-friendly.

Production Best Practices

Recommended

Use Helm 3 charts with apiVersion: v2
Keep values.yaml simple and documented
Use separate values files for dev, staging, and production
Pin chart versions and image tags
Review rendered templates before deployment
Keep secrets out of plain values files
Use chart dependencies instead of duplicating manifests
Add resource requests and limits
Use namespaces for isolation
Store charts and values in Git

Security Best Practices

Danger

Helm charts can create powerful Kubernetes resources.

Before using a chart, inspect:

helm template <release-name> <chart-name>

Check for:

privileged containers
hostPath volumes
excessive RBAC permissions
exposed LoadBalancer services
hardcoded credentials
outdated images
missing resource limits

Warning

Do not install public charts blindly in production.

Do's

Use official or verified charts when available
Read the chart documentation
Review values.yaml
Review rendered manifests
Use meaningful release names
Version-control custom values files
Test chart upgrades in staging first
Use helm dependency update when dependencies exist

Don'ts

Don't edit generated Kubernetes resources manually
Don't store passwords directly in values.yaml
Don't use floating image tags like latest in production
Don't skip chart version pinning
Don't deploy charts without checking RBAC permissions
Don't ignore chart dependencies
Don't install charts into the wrong namespace or cluster

Common Commands

Task	Command
Create chart	`helm create my-chart`
Render chart	`helm template my-release ./my-chart`
Install chart	`helm install my-release ./my-chart`
Install with values	`helm install my-release ./my-chart -f values-prod.yaml`
Upgrade chart	`helm upgrade my-release ./my-chart -f values-prod.yaml`
Check release	`helm list`
Show values	`helm show values <chart>`
Update dependencies	`helm dependency update`
Lint chart	`helm lint ./my-chart`

Helm Chart vs Kubernetes YAML

Kubernetes YAML	Helm Chart
Static manifests	Templated manifests
Manual changes per environment	Values-driven configuration
Harder to reuse	Reusable package
No release tracking	Release and revision tracking
Manual dependency handling	Supports chart dependencies

Example

Helm charts are useful when the same application must be deployed repeatedly with different configurations.

Summary

Quote

Helm Charts are packages for Kubernetes applications
Templates define Kubernetes resources
values.yaml provides configurable inputs
Chart.yaml stores chart metadata
Dependencies allow charts to reuse other charts
Use helm template and --dry-run before production deployment
In production, use version-controlled values files and pinned versions