> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Helm
> Helm packaging and templating for Kubernetes applications, using charts and Go templates to render manifests, manage installs, upgrades and rollbacks, with benefits, limitations and Glasskube integration.
Helm is a popular CLI tool for packaging, templating, and deploying applications on Kubernetes. It packages Kubernetes manifests into charts (reusable bundles of resources) and lets you inject environment-specific values to generate the YAML manifests required for cluster deployment. This abstraction simplifies complex application lifecycle tasks such as install, upgrade, rollback, and dependency management. Many community-maintained charts are discoverable on [Artifact Hub](https://artifacthub.io).
## How Helm templating works
Helm’s templating engine uses the Go templating language to produce Kubernetes manifests from templates plus a set of values. Templates contain placeholders (e.g., `{{ .Values.name }}`) that are populated from a `values.yaml` file, additional files passed with `-f`, or inline overrides via `--set`. Template rendering is typically performed client-side by the Helm CLI, producing the YAML that is either displayed (with `helm template`) or submitted to the API server (with `helm install` / `helm upgrade`).
Helm templates are evaluated client-side by the Helm CLI (unless using a server-side rendering plugin). Values come from `values.yaml`, from `-f` files, or from `--set` on the command line.
If you are new to Helm and want a structured walkthrough, Mumshad Mannambeth’s course "Helm for Beginners" is a commonly recommended resource.
## Quick example — templating in Helm
Below is a minimal example showing:
* a template file in `templates/deployment.yaml`
* a `values.yaml` file
* commands to render and install the chart
This demonstrates how placeholders are resolved to create a Kubernetes Deployment.
```yaml theme={null}
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Values.name }}
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: {{ .Values.name }}
template:
metadata:
labels:
app: {{ .Values.name }}
spec:
containers:
- name: {{ .Values.name }}-container
image: my-app-image:1.0
```
```yaml theme={null}
# values.yaml
name: my-app
replicas: 3
```
```bash theme={null}
# Render the chart templates to stdout (does not install)
helm template my-chart
```
To install (render and submit) a chart into a cluster, give it a release name and optionally pass a values file:
```bash theme={null}
# Install the chart into the cluster using the values.yaml file
helm install my-release ./my-chart -f values.yaml
```
Be careful with templates that manipulate namespaces or CRDs. Helm does not automatically update CRDs, and dependency namespace handling can cause unexpected results unless charts are designed properly.
## Pros and cons of using Helm
| Pros | Cons |
| ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Reusable templating system promotes consistency and reduces duplication. | The Go templating language can be tricky to learn and debug for complex templates. |
| Simplifies management of many Kubernetes manifests — install, upgrade, and delete complex apps. | Namespace handling for dependencies can be problematic and lead to conflicts. |
| Large community and many pre-built charts available on Artifact Hub. | Helm doesn’t natively manage CRD upgrades — manual steps or hooks are often required. |
| Supports package dependencies and tracks release history for rollbacks. | Helm does not automatically upgrade releases; external tooling is needed for automated updates. |
| Integrates with CI/CD and GitOps workflows for repeatable deployments. | Helm does not continuously monitor application health after install — combine with controllers or observability tooling. |
All in all, Helm excels at packaging and templating for Kubernetes workloads, but you should plan for lifecycle gaps (CRDs, automated upgrades, runtime health checks) by integrating additional tooling or processes where needed.
Glasskube addresses some of these Helm limitations; this article series explores how it integrates with and extends Helm workflows.
## Links and references
* [Artifact Hub](https://artifacthub.io) — find community Helm charts
* [text/template (Go)](https://pkg.go.dev/text/template) — Go templating language reference
* [Helm documentation](https://helm.sh/docs/) — official Helm docs and guides
* [Kubernetes documentation](https://kubernetes.io/docs/) — core API and resource references
* Helm for Beginners course (Mumshad Mannambeth) — recommended beginner resource