The Ultimate Guide to Helm Charts

12 min readJun 27

Simplifying Application Deployment and Management

Introduction

In today’s complex software landscape, efficient application deployment and management have become paramount. One powerful tool that has gained significant traction is Helm, an open-source package manager for Kubernetes. In this comprehensive guide, we will explore the ins and outs of Helm Charts, the building blocks of Helm, and how they can streamline your deployment processes.

Understanding Helm and its Benefits

We begin by delving into the fundamentals of Helm and its significance in the Kubernetes ecosystem. Discover how Helm simplifies the packaging, deployment, and management of applications, offering version control, reproducibility, and scalability.

Helm is an open-source package manager for Kubernetes, designed to simplify application deployment and management in Kubernetes clusters. Its primary benefits include:

1. Streamlined Deployment: Helm enables developers to package their applications into reusable units called Charts. These Charts encapsulate all the required Kubernetes resources, making it easy to deploy complex applications with a single command.

2. Version Control and Reproducibility: Helm allows developers to version their Charts, ensuring that deployments can be reproduced consistently over time. This versioning capability enhances collaboration, rollback, and troubleshooting processes.

3. Simplified Configuration Management: Helm Charts utilise templating to dynamically configure application deployments. This feature enables developers to customise deployments based on different environments, making it easier to manage configuration values and handle dependencies.

4. Extensibility and Reusability: The Helm community maintains a vast repository of pre-built Charts, covering a wide range of applications and services. Developers can leverage these existing Charts or create their own, fostering code reuse and accelerating application development.

5. Scalability and Consistency: Helm simplifies the process of deploying and managing applications across multiple Kubernetes clusters. It ensures consistent application configurations, making it easier to scale deployments and maintain consistency across different environments.

6. Ecosystem and Community Support: Helm benefits from an active and growing community, with a wealth of plugins, extensions, and resources available. This support ecosystem contributes to the ongoing development, improvement, and documentation of Helm and its related tools.

Overall, Helm significantly reduces the complexity of deploying and managing applications in Kubernetes, providing a standardised approach and enhancing developer productivity.

Exploring Helm Charts

Unveil the true power of Helm Charts, the heart and soul of Helm. We dive into the anatomy of Charts, exploring their structure, components, and templating capabilities. Learn how Charts can define, configure, and deploy complex applications with ease.

Have a look at the Docs for a comprehensive explanation of all the benefits.

Chart Structure

As discussed earlier Helm packages compenents toegether into something called a Chart. An example structure of a chart could look something like the following:

my-chart/
├── Chart.yaml
├── values.yaml
├── charts/
│   ├── dependency-chart1/
│   │   ├── Chart.yaml
│   │   ├── ...
│   │
│   └── dependency-chart2/
│       ├── Chart.yaml
│       ├── ...
│
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── ingress.yaml
    ├── ...

Let’s break down the structure:

my-chart/ is the root directory of your Helm Chart.
Chart.yaml contains metadata about the Chart, such as its name, version, and other details.
values.yaml is where you define customisable variables and configuration options for the Chart.
The charts/ directory is optional but allows you to include any dependent Charts your Chart relies on.
dependency-chart1/ and dependency-chart2/ represent directories for each dependent Chart.
Each dependent Chart has its own Chart.yaml file and additional files specific to that Chart.
The templates/ directory contains the heart of the Chart, where you define Kubernetes resources using YAML templates.
deployment.yaml, service.yaml, ingress.yaml, and other YAML files represent the templates for different Kubernetes resources.

This hierarchical structure allows for modular and reusable Chart development, with the ability to include dependencies and organise templates for different resources.

Templating and Customisation

Delve into the powerful templating engine of Helm, enabling dynamic configuration and customisation of Charts. We explore Helm’s capabilities to parameterise deployments, handle dependencies, and manage configuration values across different environments.

Helm Charts leverage powerful templating capabilities to provide flexibility and customisation:

1. Values Substitution: Templates can access values defined in the Values.yaml file, allowing you to parameterise your deployments.

Assume you have a `values.yaml` file with the following contents:

replicaCount: 3
image:
  repository: myapp
  tag: v1.0.0

And you have a `deployment.yaml` template file with the following contents:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: myapp-container
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

In this example, the `.Values.replicaCount` and `.Values.image.repository` are placeholders that will be replaced during the rendering process.

When you install the Helm Chart, Helm will substitute the values defined in the `values.yaml` file into the template. So, if you set `replicaCount` to 3 and `image.repository` to `myapp` with the tag `v1.0.0`, the resulting rendered `deployment.yaml` will be:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp-container
          image: myapp:v1.0.0

Helm performs this substitution based on the values provided in the `values.yaml` file, allowing you to dynamically configure your templates based on specific values or user-defined configurations.

2. Conditionals and Loops: Conditional statements and loops enable you to define dynamic behavior within your Chart’s templates, adapting to different scenarios.

Assume you have a `values.yaml` file with the following contents:

env: development
replicaCount: 3

And you have a `deployment.yaml` template file with the following contents:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: myapp-container
          image: myapp:latest
{{- if eq .Values.env "production" }}
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
{{- else }}
          command: ["echo", "Running in development mode"]
{{- end }}

In this example, we use the `if` conditional to check the value of `.Values.env`. If it equals “production,” Helm will render the readinessProbe section with the corresponding configuration. Otherwise, if the value is not “production,” Helm will render the command section.

During the rendering process, if the `env` value in `values.yaml` is set to “production,” the resulting rendered `deployment.yaml` will be:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp-container
          image: myapp:latest
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5

However, if the `env` value is set to anything other than “production,” the resulting rendered `deployment.yaml` will be:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: myapp-container
          image: myapp:latest
          command: ["echo", "Running in development mode"]

This example demonstrates how conditionals can be used to include or exclude specific sections of the template based on the provided values.

3. Helpers: Helm provides a set of built-in functions and helpers that extend the templating capabilities, making complex deployments more manageable. Take a look at the The Common Helm Helper Chart for examples. Although this is deprecated another good place to start might be the Bitnami Common Helper Chart.

Some examples of helpers are:

1. include: The `include` helper allows you to include and render content from external files within your chart. It can be useful for reusing common configuration snippets or templates. Here’s an example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-config
data:
  {{ include "myapp-config-values.yaml" . | indent 4 }}

In this example, the `include` helper is used to include the contents of the `myapp-config-values.yaml` file as the value for the `data` field in the ConfigMap.

2. tpl: The `tpl` helper allows you to render a template string with the provided values. It’s useful for dynamically generating values based on the provided data. Here’s an example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  template:
    spec:
      containers:
        - name: myapp-container
          image: {{ tpl .Values.image.repository . }}

In this example, the `tpl` helper is used to render the `image` field by substituting the value of `.Values.image.repository` into the template string.

3. default: The `default` helper allows you to set a default value for a variable if it’s not provided. It can be useful for handling optional values or fallback scenarios. Here’s an example:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: {{ default "ClusterIP" .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}

In this example, the `default` helper is used to set the `type` field of the Service resource to “ClusterIP” if the `.Values.service.type` value is not provided.

These are just a few examples of the helpers available in Helm Charts. Helpers provide additional flexibility and functionality to customise and manipulate values during the rendering process, making it easier to create dynamic and reusable templates.

Helm Charts are the secret sauce behind Helm’s success, enabling developers to define, configure, and deploy complex applications with ease. By understanding the anatomy of Charts and exploring their templating capabilities, you can unlock the true potential of Helm and revolutionise your Kubernetes deployments. Embrace the power of Charts and witness the transformation in your application management journey.

Harnessing Helm’s Package Management

Discover how Helm Charts simplify the process of packaging and distributing applications. We explore the Helm Chart repository, sharing best practices for managing and sharing Charts, as well as leveraging existing Charts from the Helm community.

1. Creating a Package: To create a Helm package, you can use the `helm package` command. This command packages your chart into a versioned archive file (`.tgz`). Here’s an example:

helm package myapp-chart/

This command creates a package file for the `myapp-chart` chart in the current directory.

2. Installing a Package: To install a Helm package and deploy your application, you can use the `helm install` command. This command installs a packaged chart onto your Kubernetes cluster. Here’s an example:

helm install myapp myapp-chart-0.1.0.tgz

This command installs the `myapp-chart` with the release name `myapp` from the package file `myapp-chart-0.1.0.tgz`.

3. Listing Installed Releases: To view the list of releases installed on your cluster, you can use the `helm list` command. This command provides information about the deployed releases, such as the release name, chart name, version, and status. Here’s an example:

helm list

This command displays the list of installed releases along with their details.

4. Upgrading a Release: If you want to upgrade an existing release with a new version of your chart, you can use the `helm upgrade` command. This command updates the deployed resources to match the new chart version. Here’s an example:

helm upgrade myapp myapp-chart-0.2.0.tgz

This command upgrades the release named `myapp` to the new version of the chart provided in the package file `myapp-chart-0.2.0.tgz`.

5. Uninstalling a Release: To remove a deployed release and delete all associated resources from your cluster, you can use the `helm uninstall` command. Here’s an example:

helm uninstall myapp

This command uninstalls the release named `myapp` and deletes all the resources deployed by that release.

These examples demonstrate the basic usage of Helm’s package management commands. Helm simplifies the process of managing and deploying applications by providing a consistent and reproducible way to package, install, upgrade, and uninstall your charts.

Advanced Helm Features and Use Cases

Take your Helm skills to the next level with advanced features. Explore strategies for managing secrets, performing rolling updates, and implementing Continuous Integration/Continuous Deployment (CI/CD) pipelines using Helm. Real-world use cases highlight the versatility and scalability of Helm Charts.

When it comes to managing secrets in Helm, there are a few approaches you can take to ensure the security and confidentiality of sensitive information. Here are some examples:

1. Using Values Files: One common approach is to store secret values in separate values files and reference them in your Helm charts. Here’s an example:

# values.yaml
database:
  username: myuser
  password: {{ .Values.database.password }}

# secrets.yaml
database:
  password: secretpassword

In this example, the `secrets.yaml` file contains the actual secret value (`secretpassword`), which is referenced in the `values.yaml` file using Helm templating (`{{ .Values.database.password }}`).

2. Using Kubernetes Secrets: Helm integrates with Kubernetes Secrets to manage sensitive information. You can create a Kubernetes Secret and reference it in your Helm chart. Here’s an example:

# values.yaml
database:
  username: myuser
  password:
    secretKeyRef:
      name: myapp-secrets
      key: db-password

In this example, the `password` field is referencing a Kubernetes Secret named `myapp-secrets` and the specific key `db-password` within that Secret.

3. Using External Secret Management Tools: You can leverage external secret management tools like HashiCorp Vault or Azure Key Vault to store and retrieve secrets. Helm provides plugins and integrations to work with these tools, allowing you to securely manage secrets outside of your Helm charts.

These examples illustrate different approaches to managing secrets in Helm. By adopting these practices, you can keep sensitive information separate from your chart templates, ensuring better security and facilitating easier management of secret values.

Performing rolling updates

Performing rolling updates in Helm allows you to update your deployed applications seamlessly without causing downtime. Here’s an example of how rolling updates can be achieved in Helm:

1. Chart Configuration: Assume you have a Helm chart named `myapp` that deploys a web application with multiple replicas.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: myapp
          image: myapp:1.0
          # ... other container configurations

2. Updating the Chart: To perform a rolling update, you can update the chart by changing the version of the image or any other configuration. For example, updating the image version to `myapp:1.1`:

helm upgrade myapp ./myapp - set image.tag=1.1

This command instructs Helm to upgrade the `myapp` release, providing a new value for the `image.tag` parameter.

3. Rolling Update Strategy: By default, Helm uses a rolling update strategy to update the application. This means that Helm will gradually update the replicas one by one, ensuring the availability of the application during the update process. The old replicas are replaced with the new ones in a controlled manner.

4. Monitoring the Update: You can monitor the rolling update progress using Kubernetes commands like `kubectl get pods` or Helm commands like `helm status myapp`. These commands will provide information about the status of the updated pods and ensure that the rolling update is progressing as expected.

By using Helm’s rolling update strategy, you can smoothly update your deployed applications while maintaining high availability and minimizing disruption to your users.

Tips for Helm Chart Development and Maintenance

Gain practical insights into Helm Chart development and maintenance. Learn best practices for creating reusable and modular Charts, testing and debugging, and ensuring version control and traceability.

Here are some tips for Helm chart development and maintenance:

Modularize your chart: Break down your chart into smaller, reusable components such as subcharts or chart templates. This promotes code reusability and makes it easier to manage and maintain your chart as it grows.
Use chart dependencies: Leverage Helm’s dependency management feature to include external charts as dependencies in your chart. This allows you to easily incorporate and manage complex applications or services within your chart.
Leverage chart hooks: Helm hooks provide a way to perform actions during the release lifecycle, such as pre-install, post-install, pre-upgrade, or post-upgrade. Utilize hooks to execute necessary operations, such as database migrations or configuration updates, before or after a chart is installed or upgraded.
Version control your chart: Maintain a version control system (e.g., Git) for your chart repository. This enables you to track changes, collaborate with others, and easily roll back to previous versions if needed.
Provide clear documentation: Document your chart thoroughly, including the purpose, usage, configuration options, and any dependencies or prerequisites. Clear and comprehensive documentation helps users understand and use your chart effectively.
Test your chart: Implement a robust testing strategy for your chart, including unit tests and integration tests. Helm provides testing frameworks like Helm Test to automate the validation of your chart’s functionality and ensure its correctness.
Validate chart values: Validate the values passed to your chart during installation or upgrade. Implement checks and validations to ensure that the provided values meet the expected requirements and prevent issues during deployment.
Monitor chart releases: Continuously monitor the health and performance of your deployed chart releases. Utilise monitoring tools like Prometheus and Grafana to collect metrics and gain insights into the behavior of your applications.
Stay up to date: Keep track of the latest Helm releases, updates, and best practices. Regularly update your Helm version and dependencies to leverage new features, security patches, and bug fixes.
Engage with the Helm community: Engage with the vibrant Helm community through forums, GitHub repositories, and other channels. Seek help, share knowledge, and contribute back to the community to improve the Helm ecosystem.

By following these tips, you can develop and maintain Helm charts effectively, ensuring the smooth deployment and management of your applications in Kubernetes environments.

Conclusion

Helm Charts provide a robust framework for simplifying application deployment and management in Kubernetes. By mastering the art of Helm Charts, you can unlock the full potential of Helm, empowering your teams to achieve seamless, scalable, and reproducible deployments. With this ultimate guide, you have the knowledge and tools to embark on your Helm Chart journey with confidence.