Understanding Helm Chart Structure

In this article, unravel the power of Helm Charts | Helm Chart Structure your Kubernetes package manager, simplifying deployment complexities and enhancing scalability in containerized environments.

Introduction to Helm

Helm is a tool that automates the creation, packaging, configuration, and deployment of Kubernetes applications by combining your configuration files into a single reusable package. In a microservice architecture, you create more microservices as the application grows, making it increasingly difficult to manage.

Managing Kubernetes applications across the development lifecycle brings its own set of challenges, including version management, resource allocation, updating, and rollbacks. Helm provides one of the most accessible solutions to this problem, making deployments more consistent, repeatable, and reliable.

What is a Helm Chart?

A Helm chart is a fundamental concept in Helm’s ecosystem, representing a packaged set of pre-configured Kubernetes resources. Essentially, it functions as a convenient and portable way to define, install, and manage applications on Kubernetes clusters.
Charts encapsulate all the necessary configuration files, dependencies, and deployment instructions needed for a particular application. This includes YAML configuration files for deployments, services, secrets, and config maps that define the desired state of your application.
They provide a standardized and efficient method for packaging, distributing, and versioning complex applications, contributing to Helm’s role as a powerful package manager for Kubernetes.
Additionally, each Helm chart can be versioned and managed independently, making it easy to maintain multiple versions of an application with different configurations.

Helm Chart Structure Directory

1. Chart.yaml

The Chart.yaml file is a metadata file that plays a central role in Helm charts.
Enables Helm to understand the chart, making it shareable, versioned, and easy to manage.
This is where other charts on which the helm chart that is being structured depends on are stored.

2. values.yaml

This is the file in which all the values that are to be injected into the templates are defined. Similar to terraform, Values.yaml is the same as helms variable.tf file.
The values.yaml file plays a pivotal role in Helm charts, serving as a configuration file that encapsulates default values for the various parameters used within the chart’s templates.
When installing a Helm chart, users have the flexibility to override these default values.

3. Charts/

This is where other charts on which the helm chart that is being structured depends on are stored. There might be a need to call another chart for letting the chart function properly.
The charts/ directory within a Helm chart serves as a container for subcharts—other charts upon which the primary Helm chart depends.

4. templates/

The templates/ directory is a core component within Helm charts, housing Kubernetes resource definitions.
This is the folder where the actual manifest that is being deployed with the chart is put.
For instance,for deploying an nginx deployment that needs a service, configmap and secrets, there would be a deployment.yaml, service.yaml, config.yaml and secrets.yaml all in the template dir.
They will all get their values from values.yaml from these.

/templates files:-

deployment.yaml: Contains the configuration for a Kubernetes Deployment, specifying how the application should run and scale.
service.yaml: Defines a Kubernetes Service, exposing the application to other services within the cluster.
config.yaml: Represents a ConfigMap, a mechanism to inject configuration data into the application.
secrets.yaml: Describes Kubernetes Secrets, which are used to store sensitive information securely.

These files in the templates/ directory collectively define the Kubernetes resources necessary for deploying and configuring the application encapsulated by the Helm chart.

4.1 deployment.yaml

This file defines a Kubernetes Deployment, which is a resource object in Kubernetes that provides declarative updates to applications. A Deployment allows you to describe an application’s life cycle, such as which images to use for the app, the number of pod replicas, and the way to update them.

‘apiVersion’ and ‘kind’ specify the Kubernetes API version and resource kind, respectively.
‘metadata’ contains the name of the Deployment, which is generated based on the Helm release name.
‘spec’ defines the desired state of the Deployment.
‘replicas’ specifies the number of replicas (pods) to run.
u‘selector’ is used to match the pods controlled by this Deployment.
‘template’ is the pod template for the Deployment.
‘metadata’ contains labels that match the selector.
‘containers’ defines the container(s) running in the pod, including the image and ports.

4.2 service.yaml

This file defines a Kubernetes Service, which enables external access to the application and routes traffic to the pods managed by a Deployment.

‘apiVersion’ and ‘kind’ specify the Kubernetes API version and resource kind, respectively.
‘metadata’ contains the name of the Service, which is generated based on the Helm release name.
‘spec’ defines the desired state of the Service.
‘selector’ is used to match the pods controlled by the corresponding Deployment.
‘ports’ specifies the ports on which the Service will listen.
‘type’ indicates the type of Service, such as ClusterIP, NodePort, or LoadBalancer. The type is sourced from the Helm values file.

4.3 config.yaml

The config.yaml file is often used to manage configuration settings for an application. It allows you to separate configuration from code, makin it easier to customize the behavior of your application without modifying the application itself.

‘.Values.config.database.host’, ‘.Values.config.database.port’,‘.Values.config.database.username’, and ‘.Values.config.database.password’ are placeholders for configuration values.
The ‘|’ default filter is used to provide default values if the corresponding values are not specified in the Helm values file.

4.4 secrets.yaml

The ‘secrets.yaml’ file is typically used to manage sensitive information securely. Secrets can be mounted as files or used as environment variables within your application, and Helm helps manage these secrets during deployment.

‘.Release.Name’ is used to generate a unique name for the secret based on the Helm release name.
‘type: Opaque’ indicates a generic secret type.
‘data’ contains the actual secret information. Here, it loads the contents of two files (‘username.txt’ and ‘password.txt’) from the ‘secrets/’ directory, encodes them in base64, and includes them in the secret.

5. Other helm chart files

_helpers.tpl: A Helm template file that contains reusable template snippets and functions. These can be shared across multiple charts for consistency.
requirements.yaml: Specifies dependencies for the Helm chart, allowing you to declare other charts that must be present for the primary chart to function properly.
NOTES.txt: A file containing post-installation and post-upgrade notes that are displayed to the user after the Helm chart is deployed.
LICENSE: This file includes the license information for the Helm chart.
README.md: This file provides documentation and information about the Helm chart.
.helmignore: Similar to .gitignore, this file specifies files or directories that should be ignored when packaging the chart.
tests/: This directory may contain test files and scripts to validate the Helm chart.

5.1 _helpers.tpl

The _helpers.tpl file in a Helm chart is a template helper file that contains reusable template snippets or functions. It allows you to define reusable pieces of code that can be included in other template files in your Helm chart.
The filename typically starts with an underscore (_) to indicate that it’s a helper file and not meant to be rendered as a standalone Kubernetes resource.

5.2 requirements.yaml

The ‘requirements.yaml’ file is used to declare dependencies for your Helm chart. It specifies other charts that your chart depends on, including the chart name, version constraints, and any additional settings.

dependencies is a list of dependencies that your chart relies on.
name is the name of the dependency chart.
version is the version constraint for the dependency. Helm will attempt to use a version that satisfies this constraint.
repository is the URL of the Helm chart repository where the dependency can be found.

5.3 NOTES.txt

The NOTES.txt file in a Helm chart is used to provide post-installation notes or information that is displayed to the user after a Helm chart is deployed. These notes can include instructions, tips, or any other relevant information that users should be aware of after the deployment process.
When users install your Helm chart, Helm will automatically display the content of the NOTES.txt file in the command line. Users can follow the provided instructions and notes to access and interact with the deployed application.

5.4 LICENSE

In a Helm chart, the LICENSE file typically contains information about the licensing terms and conditions for the Helm chart. It provides users and developers with details about how they can use, modify, and distribute the chart.

MIT License: Specifies the type of license (in this case, the MIT License).
Copyright: States the copyright holder or holders.
Permission is hereby granted…: Outlines the permissions granted to users under the license.
The above copyright notice and this permission notice…: Specifies that the license terms must be included in all copies or substantial portions of the software.
THE SOFTWARE IS PROVIDED “AS IS”…: Includes a disclaimer of warranty.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS…: Includes a limitation of liability.

5.5 README.md

The README.md file in a Helm chart serves as documentation to provide users with information about the chart, its purpose, how to use it, and any other relevant details.
Replace my-release with the desired release name.

5.6 .helmignore

It specifies patterns of files and directories that Helm should ignore when packaging the chart. Helm uses the ‘.helmignore’ file to determine which files to exclude when creating a chart package (tar.gz file) using the helm package command.

node_modules/, dist/, and build/ are directories that might be generated during development or build processes and are typically not needed in the packaged Helm chart.
.vscode/ and .idea/ are directories specific to Visual Studio Code and IntelliJ IDEA, respectively, and are not necessary in the packaged Helm chart.
*.swp and *~ are examples of temporary files created by certain editorsand are generally not needed in the packaged Helm chart.

5.7 tests/

In a Helm chart, the tests/ directory is commonly used to store test files and scripts that can be run to verify the correctness and functionality of the Helm chart. These tests are often automated and can be executed as part of a continuous integration (CI) pipeline or manually by users.

tests/ is a directory containing test scripts.
‘test-connection.sh’, ‘test-deployment.sh’ and ‘test-service.sh’are examples of test scripts that can verify aspects of the chart, such as connectivity, deployment, and service accessibility.

Best practices

Modularization for Scalability: Utilize the charts/ directory to modularize Helm charts, promoting component reuse and enhancing scalability.
Centralized Configuration with values.yaml: Maintain a centralized values.yaml file for clear configuration management, ensuring default values and user overrides are easily accessible.
Organized Resource Definitions:Organize Kubernetes resource definitions in the templates/ directory for clarity and easy reference. Consider using subdirectories for better organization.
Harness Helm Templating: Leverage Helm templating in the templates/ directory for dynamic and customizable resource creation.Inject values from values.yaml for flexibility during deployment.

Conclusion

Helm is a very useful package manager for Kubernetes. When you have different environments with custom deployment requirements, helm provides a great way to templatize kubernetes manifests as per our needs.
Helm-specific functionalities like chart dependencies and chart reusability make it one of the good kubernetes tools.
Kubernetes deployment is a complex process that brings along its own challenges. Using Helm can help enterprises handle these complexities and ease the process of Kubernetes deployment.

HashiCorp- DevOps Infrastructure Provisioning and Management Products