Introduction
In the previous article, we explored what Helm is, why it is widely used in Kubernetes, and how Helm Charts simplify application deployments. We also learned about Helm architecture, chart structure, and the advantages of using Helm for managing Kubernetes resources.
Understanding Helm concepts is only the beginning. To truly benefit from Helm, you need to know how to create your own Helm Charts, customize application configurations, and manage deployments throughout an application's lifecycle.
Helm provides a collection of powerful commands that simplify deploying, updating, and maintaining Kubernetes applications. Instead of manually editing multiple YAML files whenever changes are required, Helm allows you to package application resources into reusable charts and deploy them consistently across different environments.
Whether you're deploying a small web application or a large microservices-based platform, Helm helps ensure deployments remain repeatable, organized, and easy to maintain.
In this article, you'll learn how to create your first Helm Chart, understand the files generated by Helm, customize application settings using values.yaml, and prepare your applications for deployment.
Figure 1: Helm Chart deployment workflow.
Creating Your First Helm Chart
One of Helm's greatest advantages is that it automatically generates a well-organized project structure for you.
Instead of creating every Kubernetes manifest manually, Helm provides a command that builds a complete chart template containing all the files commonly required to deploy an application.
Run the following command:
helm create my-first-chart
After executing the command, Helm creates a directory named my-first-chart with the following structure:
my-first-chart/
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
└── .helmignore
This generated structure follows Helm's recommended project layout and provides everything needed to package and deploy an application.
Rather than starting from an empty folder, developers receive production-ready templates that can be customized according to their application's requirements. This approach saves time, reduces manual effort, and promotes consistency across different projects.
For beginners, this default structure is also an excellent learning resource because it demonstrates how Kubernetes resources are organized inside a Helm Chart.
Figure 2: Creating a Helm Chart using the helm create command.
Understanding the Generated Files
When Helm creates a new chart, it includes several important files and directories. Each serves a specific purpose during application deployment.
Understanding these files helps developers customize Helm Charts more effectively.
Chart.yaml
The Chart.yaml file contains metadata about the Helm Chart.
Typical information includes:
- Chart name
- Description
- Chart version
- Application version
- Maintainer information
Helm reads this file whenever the chart is installed, upgraded, or packaged.
values.yaml
The values.yaml file contains the default configuration values used throughout the Helm Chart.
Instead of hardcoding values inside Kubernetes templates, Helm stores configurable settings in this file.
Common configuration values include:
- Replica count
- Docker image
- Image tag
- Service type
- Container ports
- CPU requests
- Memory limits
- Environment variables
This separation between templates and configuration allows developers to reuse the same chart across multiple environments without modifying the deployment templates.
For example, changing the replica count from 1 in development to 5 in production only requires updating a single value.
templates/
The templates directory is the most important part of a Helm Chart.
It contains Kubernetes resource templates such as:
- Deployment
- Service
- ConfigMap
- Secret
- Ingress
- ServiceAccount
Unlike regular Kubernetes manifests, these files contain template variables enclosed within double curly braces ({{ }}).
During deployment, Helm automatically replaces these variables with values from values.yaml, generating the final Kubernetes manifests sent to the cluster.
This templating system makes deployments highly flexible while eliminating duplicated YAML files.
charts/
The charts directory stores dependency charts.
If your application depends on another Helm Chart, it can be included inside this folder.
This enables developers to package complex applications consisting of multiple services into a single deployable unit.
.helmignore
The .helmignore file works similarly to Git's .gitignore.
It specifies files and directories that should not be included when packaging the Helm Chart.
Ignoring unnecessary files helps keep chart packages lightweight and organized.
Customizing Applications with values.yaml
One of Helm's most powerful features is the ability to customize application deployments without editing Kubernetes templates directly.
Instead of modifying multiple YAML files, developers simply update values stored in the values.yaml configuration file.
For example:
replicaCount: 2
image:
repository: nginx
tag: latest
service:
type: ClusterIP
port: 80
Changing these values automatically updates the generated Kubernetes manifests during deployment.
For example, different environments can use different configurations:
| Environment | Replica Count |
|---|---|
| Development | 1 |
| Testing | 2 |
| Production | 5 |
Similarly, updating an application to a newer container image only requires changing the image tag in values.yaml.
This separation between configuration and templates makes Helm Charts reusable, easier to maintain, and significantly reduces the chances of deployment errors.
As applications grow larger and deployments become more frequent, this flexibility becomes one of Helm's greatest strengths.
Figure 3: Customizing Kubernetes deployments using values.yaml.
Installing a Helm Chart
After creating and customizing your Helm Chart, the next step is to deploy it to a Kubernetes cluster. Helm simplifies this process with a single command, eliminating the need to manually apply multiple Kubernetes manifest files.
Use the following command to install the chart:
helm install my-app ./my-first-chart
Here:
- my-app is the name of the Helm release.
- ./my-first-chart specifies the path to the Helm Chart.
When this command is executed, Helm performs several tasks automatically:
- Packages the chart.
- Reads configuration values from
values.yaml. - Generates Kubernetes manifests from the templates.
- Deploys all required resources to the Kubernetes cluster.
If the installation is successful, Helm displays information such as the release name, namespace, deployment status, and additional notes for accessing the application.
To view all installed releases, run:
helm list
This command displays useful information including:
- Release name
- Namespace
- Revision number
- Deployment status
- Chart version
Monitoring releases becomes especially useful when managing multiple applications across different Kubernetes environments.
Figure 4: Managing a Helm release throughout its lifecycle.
Upgrading an Existing Application
Applications continuously evolve as new features, bug fixes, and security updates are introduced. Helm makes updating applications simple by allowing developers to upgrade existing releases without manually editing Kubernetes resources.
To upgrade a deployed application, use:
helm upgrade my-app ./my-first-chart
Helm compares the updated chart with the currently deployed release and applies only the necessary changes.
Common upgrade scenarios include:
- Deploying a new container image
- Increasing replica count
- Updating environment variables
- Modifying resource requests and limits
- Changing service configurations
This incremental update process minimizes downtime and keeps deployments consistent across environments.
Rolling Back a Release
Despite careful planning, deployments can occasionally introduce unexpected issues. A configuration error or incompatible application version may cause the deployment to fail or behave unexpectedly.
One of Helm's most valuable features is its built-in release history.
To view previous revisions, run:
helm history my-app
If an upgrade causes problems, you can restore an earlier version using:
helm rollback my-app 1
In this example, 1 represents the revision number to restore.
Rollback enables teams to recover quickly from deployment failures without manually restoring Kubernetes manifests or rebuilding previous configurations.
This feature significantly reduces downtime and improves deployment reliability.
Uninstalling a Helm Release
When an application is no longer required, Helm makes cleanup quick and straightforward.
Run:
helm uninstall my-app
This command removes the Helm release along with all Kubernetes resources that were created during installation.
Instead of manually deleting Deployments, Services, ConfigMaps, Secrets, and other resources one by one, Helm performs the cleanup automatically, saving time and reducing the chance of leaving unused resources in the cluster.
Packaging and Sharing Helm Charts
One of Helm's greatest strengths is portability.
After creating and testing a Helm Chart, it can be packaged and shared with other developers or teams.
Organizations commonly maintain private Helm repositories containing deployment templates for internal applications. This ensures every team follows consistent deployment practices while reducing duplicated effort.
Helm also supports public repositories where developers can publish reusable charts for popular applications. This allows teams to deploy software quickly without building Kubernetes configurations from scratch.
Packaging applications into reusable Helm Charts improves collaboration, simplifies onboarding, and promotes standardized deployments across projects.
Helm Best Practices
Following best practices helps keep Helm Charts clean, reusable, and easy to maintain.
Keep Charts Simple
Avoid adding unnecessary complexity. Well-structured charts are easier to understand, troubleshoot, and maintain.
Store Configurations in values.yaml
Keep configurable values separate from Kubernetes templates. This makes deployments more flexible and reusable across environments.
Reuse Template Logic
Use helper templates whenever possible instead of repeating labels or configuration blocks throughout the chart.
Version Your Charts
Increment the chart version whenever meaningful changes are made. Proper versioning simplifies release management and deployment tracking.
Test Before Production
Always validate chart changes in development or staging environments before deploying to production.
Document Your Chart
Provide clear documentation describing installation steps, configurable parameters, dependencies, and supported Kubernetes versions.
Following these practices helps teams build reliable, maintainable Helm Charts suitable for long-term use.
Common Mistakes to Avoid
Beginners often make mistakes while working with Helm. Being aware of these issues can help avoid deployment problems.
Some common mistakes include:
- Editing generated templates without understanding their purpose.
- Hardcoding configuration values instead of using
values.yaml. - Forgetting to increment chart versions after making updates.
- Deploying changes directly to production without testing.
- Ignoring release history and rollback capabilities.
- Creating overly complex charts for simple applications.
Avoiding these mistakes improves deployment reliability and makes charts easier to maintain.
Conclusion
Helm has transformed the way Kubernetes applications are deployed and managed. Instead of manually maintaining numerous YAML files, developers can package applications into reusable Helm Charts and deploy them using a small set of intuitive commands.
Throughout this article, we've learned how to create a Helm Chart, understand its structure, customize deployments using values.yaml, install applications, perform upgrades, roll back failed releases, and follow best practices for long-term maintainability.
By adopting Helm in your Kubernetes workflow, you can reduce manual effort, improve deployment consistency, and simplify application lifecycle management. Whether you're working on personal projects or enterprise-scale Kubernetes environments, Helm provides a reliable and efficient approach to managing deployments.
Mastering Helm is an important milestone in your Kubernetes journey and lays the foundation for more advanced topics such as GitOps, CI/CD automation, and Kubernetes application packaging.
Frequently Asked Questions (FAQ)
1. What does helm install do?
It deploys a Helm Chart to a Kubernetes cluster and creates a new release.
2. How do I update an existing Helm deployment?
Use the helm upgrade command to apply updated chart templates or configuration values.
3. Why is values.yaml important?
It stores configurable settings separately from templates, allowing the same Helm Chart to be reused across multiple environments.
4. What is the purpose of helm rollback?
It restores a previous release if a deployment introduces errors or unexpected behavior.
5. Can Helm Charts be shared with other developers?
Yes. Helm Charts can be packaged and distributed through public or private Helm repositories, making deployments reusable and standardized across teams.
Ready to Optimize Your Kubernetes Environment?
Helm simplifies Kubernetes deployments by making applications easier to package, configure, and manage. Once your workloads are running, EcScale helps you go even further by automatically optimizing Kubernetes resource utilization, eliminating idle capacity, and reducing cloud costs without compromising application performance.
Book a free EcScale demo today and discover how intelligent Kubernetes optimization complements your Helm-powered deployments.
Top comments (0)