Hands-on Lab·Kubernetes and Cloud Native Associate
Helm Charts and Release State
helm create scaffolds a working chart, helm template renders it without a cluster, and --dry-run creates nothing at all - not even the namespace. Then two Secrets in the release namespace turn out to be the whole of Helm's memory.
Delivery and GitOps Guide 45 of 46 Beginner
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 17 min
Chart scaffolding differs slightly between Helm minor versions. Release storage as Secrets has been the default since Helm 3.
- Helmv3.18.5
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when an application has to be packaged with Helm and you need to know where a release actually lives. This matters because Helm keeps no database - the release history is Secrets in the namespace - and that changes how you back it up and how you debug it.
- scaffolding a working chart with
helm createand linting it - rendering templates locally with
helm template, no cluster required - confirming
--dry-runcreates nothing at all, including the namespace - installing for real, upgrading with
--reuse-values, and readinghelm history - finding release state stored as
sh.helm.release.v1Secrets rather than in a database
Before you start
helminstalled and a working kubeconfig.helm versionshould answer.- Familiarity with the two Helm nouns: a chart is a package of templates, and a release is one installed instance of a chart, with its own name and its own values.
-
Scaffold one, and lint it
-
Render it without a cluster
-
Dry-run creates nothing - check it
-
Install it for real
-
Upgrade, and read the history
-
Helm has no database