Overview

Helm helps you manage Kubernetes applications. Helm Charts help you define, install, and upgrade even the most complex Kubernetes applications.

Three Big Concepts

• Chart: A Helm package containing all the resource definitions necessary to run an application, tool, or service inside a Kubernetes cluster. It’s akin to the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.
• Repository: A place where charts can be collected and shared, similar to Perl’s CPAN archive or the Fedora Package Database but for Kubernetes packages.
• Release: An instance of a chart running in a Kubernetes cluster. One chart can often be installed multiple times into the same cluster, with each installation creating a new release. For example, if you want two MySQL databases running in your cluster, you can install the MySQL chart twice, resulting in two releases, each with its own release name.

With these concepts in mind, Helm can be summarized as:

Helm installs charts into Kubernetes, creating a new release for each installation. You can search Helm chart repositories to find new charts.

Charts

Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and more.

Charts are created as files laid out in a particular directory tree and can be packaged into versioned archives for deployment.

To download and inspect the files for a published chart without installing it, you can use:

helm pull chartrepo/chartname

The Chart File Structure

A chart is organized as a collection of files inside a directory named after the chart (without versioning information). For instance, a chart describing WordPress would be stored in a wordpress/ directory.

Inside of this directory, Helm will expect a structure that matches this:

  wordpress/
    Chart.yaml           # A YAML file containing information about the chart
    LICENSE              # OPTIONAL: A plain text file containing the license for the chart
    README.md            # OPTIONAL: A human-readable README file
    values.yaml          # The default configuration values for this chart
    values.schema.json   # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file
    charts/              # A directory containing any charts upon which this chart depends.
    crds/                # Custom Resource Definitions
    templates/           # A directory of templates that, when combined with values, will generate valid Kubernetes manifest files.
    templates/NOTES.txt  # OPTIONAL: A plain text file containing short usage notes.

Helm reserves use of the charts/, crds/, and templates/ directories, and of the listed file names. Other files will be left as they are.

Charts and Versioning

Every chart must have a version number. A version must follow the SemVer 2 standard. Unlike Helm Classic, Helm v2 and later uses version numbers as release markers. Packages in repositories are identified by name plus version.

For example, an nginx chart whose version field is set to version: 1.2.3 will be named: nginx-1.2.3.tgz

Understanding Helm Charts

A Helm Chart is a collection of files that describe a set of Kubernetes resources. Charts allow you to define an application’s structure and configuration in a way that is reusable and easy to manage.

Structure of a Helm Chart

Here’s an overview of the key files in a Helm Chart:

1. Chart.yaml: Contains metadata about the chart, including its name, version, and description.

    apiVersion: v2
    name: my-app
    version: 0.1.0
    description: A Helm chart for my Kubernetes application

2. values.yaml: Provides default configuration values for the chart. Users can override these values during installation.

    replicaCount: 3
    image:
      repository: nginx
      tag: latest
    service:
      type: ClusterIP
      port: 80

3. templates/: Contains Kubernetes manifest templates for the resources the chart will create, such as Deployments, Services, and ConfigMaps. Example deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: {{ .Chart.Name }}
    spec:
      replicas: {{ .Values.replicaCount }}
      template:
        spec:
          containers:
          - name: {{ .Chart.Name }}
            image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

NOTES.txt (optional): Displays helpful post-installation instructions.

Installing a Helm Chart

To install a Helm Chart, you can use the following command:

helm install <release-name> <chart-name> --values <custom-values-file.yaml>

Example:

helm install my-nginx stable/nginx --values custom-values.yaml

You can view the deployed resources using:

kubectl get all

Updating and Managing Charts

One of Helm’s strengths is its ability to update applications:

Upgrade an Existing Release

helm upgrade <release-name> <chart-name> --values <updated-values.yaml>

Rollback to a Previous Version

helm rollback <release-name> <revision-number>

To view release history:

helm history <release-name>

 

Alternatives to Helm Charts for Kubernetes Application Management

Helm is one of the most popular package managers for Kubernetes, providing a templated approach to deploying and managing applications. However, it is not the only tool available. Depending on your requirements, other solutions may be a better fit. This article explores the top alternatives to Helm charts and their use cases.

1. Kustomize

Overview

Kustomize is a Kubernetes-native configuration management tool that allows users to manage YAML configurations without requiring templating. It is built into kubectl and provides a powerful way to customize Kubernetes objects.

Key Features

• Uses overlays to modify configurations without modifying base manifests.
• Natively integrated into kubectl (kubectl apply -k).
• No templating, making it simple and declarative.

Best Use Cases

• When you need to modify existing Kubernetes manifests without introducing templating complexity.
• When working with GitOps workflows.

Website

https://kustomize.io/

2. Jsonnet

Overview

Jsonnet is a data templating language designed to simplify JSON and YAML configuration management.

Key Features

• Supports programming constructs like loops, conditionals, and functions.
• Generates Kubernetes manifests dynamically.
• Used in Grafana Tanka for managing Kubernetes resources.

Best Use Cases

• When dealing with complex, dynamic configurations requiring advanced logic.
• When generating Kubernetes manifests programmatically.

Website

https://jsonnet.org/

3. Carvel (kapp + ytt)

Overview

Carvel is a suite of tools designed to simplify Kubernetes application deployment, focusing on transparency and consistency.

Key Features

• kapp: A tool for deploying and managing Kubernetes applications.
• ytt: A YAML templating tool for configuration management.
• Supports sophisticated templating and patching capabilities.

Best Use Cases

• When you need fine-grained control over Kubernetes resource management.
• When you want a declarative approach with better visibility over changes.

Website

https://carvel.dev/

4. CDK for Kubernetes (CDK8s)

Overview

CDK8s allows users to define Kubernetes applications using general-purpose programming languages like TypeScript, Python, or Java instead of YAML.

Key Features

• Enables programmatic configuration management.
• Uses constructs (reusable components) to simplify Kubernetes object definitions.
• Ideal for teams comfortable with infrastructure-as-code approaches.

Best Use Cases

• When teams prefer to define Kubernetes resources using TypeScript, Python, or Java.
• When managing complex infrastructure with reusable constructs.

Website

https://cdk8s.io/

5. Operator Framework

Overview

The Operator Framework allows Kubernetes users to build operators, which are controllers that manage the full lifecycle of applications.

Key Features

• Automates operational tasks such as scaling, upgrades, and backups.
• Uses Custom Resource Definitions (CRDs) and controllers to manage workloads.
• Great for stateful applications like databases.

Best Use Cases

• When managing databases or stateful applications.
• When requiring automated operational intelligence beyond basic templating.

Website

https://operatorframework.io/

 

While Helm is a powerful tool for managing Kubernetes applications, alternatives like Kustomize, Jsonnet, Carvel, CDK8s, and the Operator Framework provide different approaches tailored to specific needs. Whether you prefer declarative configuration, programmatic infrastructure, or automated management, choosing the right tool depends on your workflow and complexity requirements.

Summary Table

Alternative	Best For	Key Feature
Kustomize	Declarative YAML management	No templating, overlays
Jsonnet	Advanced configuration	Logic-based YAML generation
Carvel	Granular deployment control	kapp and ytt tools
CDK8s	Infrastructure-as-code teams	Define resources using Python/TypeScript
Operator Framework	Stateful applications	Automates Kubernetes management

Do you need help selecting the best tool for your use case? Let us know!

While Helm is a popular choice, many DevOps teams prefer Kustomize for its simplicity and Kubernetes-native approach. At OpsBridge, we help businesses adopt the best Kubernetes tools tailored to their infrastructure needs.

 

Conclusion

Helm Charts are a powerful way to simplify and standardize Kubernetes deployments. By mastering Helm, you can reduce complexity, improve efficiency, and better manage your Kubernetes applications. Start small by creating simple charts and gradually explore advanced features like hooks and testing.

Are you already using Helm in your workflows? Share your experiences or tips in the comments below!