Back to Blog
    DevOps

    Mastering Helm Charts: From Basics to Umbrella Charts

    September 28, 2025
    7 min read
    By Saanj Vij

    Building Helm Charts

    Overview

    This guide provides an introduction to Helm charts, their structure, key concepts, and commands. Helm charts are a way to package Kubernetes applications and make them reusable, customizable, and easy to deploy. We'll cover how to build, manage, and install Helm charts, along with important concepts like releases and revisions.

    Helm Chart Structure

    A Helm chart is essentially a directory that contains all the files necessary to define and deploy a Kubernetes application. Here's an overview of the key components of a Helm chart:

    Chart Structure

    • Chart.yaml: Contains metadata about the chart (name, version, description, and dependencies).
    • values.yaml: Default values for the chart templates.
    • templates/: Contains Kubernetes YAML files, often as customizable templates with placeholders and helper functions.
    • charts/: Contains subcharts or external chart dependencies (as archives or referenced in Chart.yaml).
    • LICENSE (optional): Specifies the license for the chart.
    • README.md: Provides documentation for the chart.
    • NOTES.txt: Displays post-installation instructions or useful information for users.
    • values.schema.json: Defines the structure of the values.yaml file for validation.
    • tests/: Contains pod definitions for testing.
    • crds/: Stores Custom Resource Definitions (CRDs), which are installed before other Kubernetes objects.

    Key Files and Properties

    Chart.yaml

    This file is the entry point for a Helm chart and contains:

    • name: Name of the chart.
    • description (optional): Brief description of the chart.
    • apiVersion: Version of the Helm API (v2 for Helm 3).
    • type: Type of the chart (application for deployable charts, library for reusable functions).
    • version: Version of the chart following semantic versioning (e.g., 1.0.0).
    • appVersion: Version of the application being packaged (can differ from version).
    • dependencies: List of chart dependencies (preferred over requirements.yaml in Helm 3).

    values.yaml

    Contains default configuration values for templates. Users can override these values when installing the chart.

    templates/

    This directory includes Kubernetes YAML templates that are dynamically rendered using values from values.yaml.

    Helm Concepts

    Charts and Releases

    • Chart: The definition of an application.
    • Release: An instance of a chart running in a Kubernetes cluster.
    • Release Revision: Updates to an existing release, creating a new revision without changing the release name.

    Chart vs. Release Version

    • Chart Version: Refers to the structure and templates in the chart (tracked in Chart.yaml).
    • Release Revision: Refers to updates or changes to a running instance of the chart.

    Helm Commands

    Common Commands

    • helm install <release-name> <chart>: Installs a chart as a release.
    • helm upgrade <release-name> <chart>: Updates an existing release.
    • helm rollback <release-name> <revision>: Rolls back a release to a previous revision.
    • helm history <release-name>: Lists the revision history of a release.
    • helm status <release-name>: Displays the status of a release.
    • helm get all <release-name>: Retrieves details about a release.
    • helm uninstall <release-name>: Removes a release from the cluster.
    • helm list: Lists all releases with basic information.

    Key Differences Between Helm 2 and Helm 3

    • Release Name: Helm 2 auto-generates names by default; Helm 3 requires --generate-name for auto-generation.
    • Command Updates:
      • helm delete in Helm 2 is renamed to helm uninstall in Helm 3.
      • Helm 3 purges history by default; use --keep-history to retain it.
      • helm get in Helm 3 requires subcommands like all to specify what to retrieve.

    Example: Building and Installing a Chart

    Steps to Build a Chart

    1. Create a directory for the chart (e.g., guestbook/).
    2. Add a Chart.yaml file:
      apiVersion: v2
      name: guestbook
      version: 1.0.0
      appVersion: 1.0
      description: Guestbook application chart
      
    3. Create a templates/ directory and add Kubernetes YAML files (e.g., pod.yaml, service.yaml, ingress.yaml).
    4. Optional: Add documentation (README.md, NOTES.txt) and dependencies (charts/ or Chart.yaml).

    Installing the Chart

    helm install demo-guestbook guestbook
    

    Checking the Release

    • View installed releases: helm list
    • Get release details: helm get all demo-guestbook

    Updating the Release

    helm upgrade demo-guestbook guestbook
    

    Rolling Back a Release

    helm rollback demo-guestbook <revision>
    

    Helm Chart Deployment Guide


    Umbrella Helm Charts

    An umbrella Helm chart is a higher-level chart that aggregates multiple sub-charts (dependencies) into a single deployment. Think of it as a "master chart" that serves as a parent to smaller, reusable charts. It provides a way to manage multiple components of a complex application as a single entity.

    Key Features

    1. Dependency Management:

      • Umbrella charts can list multiple sub-charts as dependencies in the Chart.yaml file under the dependencies section.
      • Dependencies are typically fetched and stored in the charts/ directory.
    2. Centralized Values:

      • An umbrella chart allows you to override values of the sub-charts centrally using a single values.yaml file.
      • This central configuration reduces the need to manage multiple value files for individual charts.
    3. Logical Grouping:

      • Ideal for deploying applications with multiple microservices or components (e.g., frontend, backend, databases, etc.).
      • Each component is represented as a sub-chart and can be individually maintained.
    4. Simplified Installation:

      • By using an umbrella chart, you only need a single helm install or helm upgrade command to deploy all dependencies together.

    Example: Umbrella Chart Structure

    Imagine you have a web application with three components:

    1. Frontend: React/Angular UI.
    2. Backend: Spring Boot API.
    3. Database: PostgreSQL.

    You could create an umbrella chart with the following structure:

    umbrella-chart/
    ├── charts/
    │   ├── frontend/ (sub-chart for frontend)
    │   ├── backend/ (sub-chart for backend)
    │   ├── database/ (sub-chart for PostgreSQL)
    ├── templates/
    │   └── (templates for overall orchestration, if needed)
    ├── Chart.yaml
    ├── values.yaml
    

    Chart.yaml for Umbrella Chart

    The Chart.yaml file for the umbrella chart might look like this:

    apiVersion: v2
    name: umbrella-chart
    version: 1.0.0
    dependencies:
      - name: frontend
        version: 2.0.0
        repository: https://charts.example.com
      - name: backend
        version: 1.3.1
        repository: https://charts.example.com
      - name: postgresql
        version: 10.12.0
        repository: https://charts.bitnami.com/bitnami
    

    values.yaml for Umbrella Chart

    The values.yaml file can override values for the sub-charts:

    frontend:
      image:
        tag: v1.0.1
      replicas: 3
    
    backend:
      environment:
        DATABASE_URL: postgresql://db-service:5432/app
    
    postgresql:
      auth:
        username: admin
        password: password123
        database: app
    

    Advantages of Umbrella Charts

    1. Centralized Management:
      • Simplifies the deployment process by bundling everything under one chart.
    2. Reuse:
      • Sub-charts can be reused across multiple umbrella charts for different environments.
    3. Flexibility:
      • Enables overrides and fine-tuning of sub-chart values.

    Considerations for Umbrella Charts

    1. Complexity:
      • While umbrella charts simplify deployment, managing multiple sub-charts and their interdependencies can become challenging.
    2. Dependency Updates:
      • Keeping sub-charts updated requires careful version management in the Chart.yaml file.
    3. Overrides:
      • Overriding deeply nested sub-chart values can get tricky in the values.yaml file.

    Basic Helm Commands

    Here are some useful Helm commands:

    • Install a chart:

      helm install <release-name> <chart-name>
      
    • Upgrade a release:

      helm upgrade <release-name> <chart-name>
      
    • Uninstall a release:

      helm uninstall <release-name>
      
    • Check release history:

      helm history <release-name>
      
    • Rollback a release:

      helm rollback <release-name> <revision>
      

    Best Practices

    1. Use versioned charts to ensure reproducibility.
    2. Maintain a separate values.yaml file for each environment (e.g., dev, staging, prod).
    3. Regularly update dependencies using helm dependency update.
    4. Validate charts with helm lint before deploying.
    5. Use Helm secrets to manage sensitive data securely.

    This guide provides a foundational understanding of Helm charts and the benefits of using umbrella charts for managing complex deployments. For further customization and advanced features, refer to the Helm Documentation.


    Summary

    • Helm charts package Kubernetes applications for easy deployment and management.
    • Charts are highly customizable through templates and values.yaml.
    • Key Helm concepts include charts, releases, and revisions.
    • Helm commands enable installing, upgrading, rolling back, and managing releases.
    • Helm 3 introduces several improvements and differences compared to Helm 2.

    This guide serves as a reference for building and managing Helm charts efficiently.


    Want to discuss cloud architecture? Find me on LinkedIn.

    Found this useful? Let's go deeper.

    Book a free 15-minute call to discuss your cloud, DevOps, or AI strategy challenges.

    Book a Free Call