Skip to main content
Back to Library
mastering ckad certified kubernetes application developer

Charts, Releases, and Values

9 min read Chapter 65 of 87
Summary

Deep dive into Helm concepts: chart directory structure...

Deep dive into Helm concepts: chart directory structure and key files, repository management with helm repo add and helm repo update, chart discovery with helm search repo and Artifact Hub, and value inspection and override mechanics using helm show values, --set flags, and custom values files.

Charts, Releases, and Values

Before running helm install, you need to know what you’re installing and how to configure it. This section covers the mechanics of finding, inspecting, and parameterizing Helm charts — the skills that let you work with charts authored by others without needing to understand their template internals.

Chart Structure

A Helm chart is a directory with a defined layout. When you download or inspect a chart, you encounter these key files:

nginx/
├── Chart.yaml          # Metadata: name, version, description, dependencies
├── values.yaml         # Default configuration values
├── charts/             # Dependency charts (sub-charts)
├── templates/          # Kubernetes manifest templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── _helpers.tpl    # Template helper functions
│   └── NOTES.txt       # Post-install instructions displayed to user
└── README.md           # Human-readable documentation

Chart.yaml

The Chart.yaml file contains metadata about the chart:

apiVersion: v2
name: nginx
description: A Helm chart for deploying nginx
type: application
version: 1.2.3          # Chart version (packaging version)
appVersion: "1.25.4"    # Version of the application being deployed
dependencies:
  - name: common
    version: 2.x.x
    repository: https://charts.bitnami.com/bitnami

Two version fields matter here. The version field tracks the chart packaging — it increments when the chart templates, defaults, or structure change. The appVersion field indicates which version of the underlying software (nginx 1.25.4 in this case) the chart deploys. These versions are independent: a chart author can release chart version 1.2.4 that still deploys nginx 1.25.4 but fixes a template bug.

values.yaml

The values.yaml file defines every configurable parameter and its default value:

replicaCount: 1

image:
  repository: nginx
  tag: "1.25.4"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

ingress:
  enabled: false
  hostname: ""

Every value in this file becomes a variable in the chart’s templates. When you override a value at install time, Helm substitutes your value into the template, producing a customized Kubernetes manifest. You don’t need to know Go template syntax to use charts — you only need to know which values to set.

templates/

The templates/ directory contains Kubernetes manifest files with Go template directives. These files are not valid YAML on their own — they contain placeholders like {{ .Values.replicaCount }} that Helm resolves before applying to the cluster. As a chart consumer, you never edit these files directly. You configure the chart through values.

Repository Management

Charts are distributed through repositories. A repository is an HTTP server hosting an index.yaml file that lists available charts and their versions. Helm maintains a local cache of repository metadata.

Adding a Repository

helm repo add bitnami https://charts.bitnami.com/bitnami

This registers the Bitnami repository under the local alias bitnami. The alias is your choice — you could use any name — but bitnami is conventional for the Bitnami catalog.

Verify registered repositories:

helm repo list
NAME    URL
bitnami https://charts.bitnami.com/bitnami

Updating Repository Metadata

Repository metadata is cached locally and becomes stale over time. Before searching for or installing charts, refresh the cache:

helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈Happy Helming!⎈

This command fetches the latest index.yaml from every registered repository, ensuring your local Helm client knows about newly published chart versions.

Removing a Repository

helm repo remove bitnami

This removes the local alias and clears the cached metadata. It does not affect anything installed from that repository — releases are independent of their source repository.

Searching for Charts

helm search repo

Search your locally registered repositories:

helm search repo nginx
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
bitnami/nginx           15.14.0         1.25.4          NGINX Open Source for Kubernetes
bitnami/nginx-ingress   10.4.0          1.10.1          NGINX Ingress Controller deployment

The output shows the chart name (including repository alias), the chart version, the application version, and a description. Multiple charts may match a search term — nginx matches both the nginx web server chart and the nginx ingress controller chart.

Filter by version:

helm search repo bitnami/nginx --version ">=15.0.0"

Show all available versions of a chart, not only the latest:

helm search repo bitnami/nginx --versions
NAME            CHART VERSION   APP VERSION     DESCRIPTION
bitnami/nginx   15.14.0         1.25.4          NGINX Open Source...
bitnami/nginx   15.13.2         1.25.4          NGINX Open Source...
bitnami/nginx   15.12.1         1.25.3          NGINX Open Source...
...

Artifact Hub

For charts outside your registered repositories, Artifact Hub (artifacthub.io) aggregates charts from hundreds of publishers. You can also search it from the command line:

helm search hub nginx

This queries the Artifact Hub API directly — no repository registration required. The output includes the chart URL, which you can use to find the repository to add.

Inspecting Charts

Before installing a chart, inspect what it ships and what it configures.

helm show chart

Display the chart’s metadata (contents of Chart.yaml):

helm show chart bitnami/nginx
annotations:
  category: Infrastructure
apiVersion: v2
appVersion: 1.25.4
description: NGINX Open Source is a web server...
name: nginx
type: application
version: 15.14.0

This tells you the chart and application versions, the description, and any dependencies.

helm show values

Display the chart’s default values (contents of values.yaml):

helm show values bitnami/nginx

This prints the full values.yaml file, which can be hundreds of lines for complex charts. Pipe it through grep or redirect to a file for easier reading:

helm show values bitnami/nginx > nginx-defaults.yaml

Now you can search for specific parameters:

grep -A 5 "replicaCount" nginx-defaults.yaml

helm show all

Display everything — chart metadata, values, and the README:

helm show all bitnami/nginx

This is useful for a comprehensive overview but produces substantial output. For exam scenarios, helm show values is the most practical command.

helm show readme

Display only the chart’s README documentation:

helm show readme bitnami/nginx

Inspecting a Specific Version

All helm show subcommands accept a --version flag to inspect a particular chart version instead of the latest:

helm show values bitnami/nginx --version 15.12.1

This is critical when you need to install a specific version and want to verify what values it supports before committing. Chart values can change between versions — a parameter that exists in 15.14.0 may not exist in 15.12.1, or its default may differ.

Comparing Values Between Versions

A practical technique for understanding what changed between chart versions: dump the values for two versions and diff them:

helm show values bitnami/nginx --version 15.12.1 > values-old.yaml
helm show values bitnami/nginx --version 15.14.0 > values-new.yaml
diff values-old.yaml values-new.yaml

This reveals new parameters, renamed fields, and changed defaults — information the chart’s CHANGELOG may not fully document.

Overriding Values

Charts ship with sensible defaults, but real deployments require customization. Helm provides two mechanisms for overriding default values. Understanding when to use each — and how they interact — is essential for both production deployments and exam efficiency.

The —set Flag

Override individual values inline:

helm install my-nginx bitnami/nginx --set replicaCount=3

For nested values, use dot notation:

helm install my-nginx bitnami/nginx \
  --set service.type=NodePort \
  --set service.nodePorts.http=30080

For array values, use curly braces:

helm install my-nginx bitnami/nginx \
  --set "ingress.extraHosts[0].name=app.example.com"

The --set flag is convenient for one or two overrides, but it becomes unwieldy for complex configurations and is hard to track in version control.

The -f (—values) Flag

Provide a YAML file with your overrides:

# custom-values.yaml
replicaCount: 3

service:
  type: NodePort
  nodePorts:
    http: 30080

resources:
  limits:
    cpu: 200m
    memory: 256Mi
  requests:
    cpu: 100m
    memory: 128Mi

Install with the custom values file:

helm install my-nginx bitnami/nginx -f custom-values.yaml

Values files are the preferred approach for any non-trivial configuration. They are readable, diffable, and committable to version control.

Precedence Rules

When multiple value sources overlap, Helm applies a strict precedence order (highest wins):

  1. --set flags (highest priority)
  2. -f values files (in order — later files override earlier ones)
  3. Chart’s default values.yaml (lowest priority)

This means --set always overrides file-based values, and file-based values always override defaults. If you pass multiple -f flags, later files take precedence:

helm install my-nginx bitnami/nginx \
  -f base-values.yaml \
  -f production-overrides.yaml \
  --set image.tag=1.25.5

In this command, production-overrides.yaml overrides anything in base-values.yaml, and --set image.tag=1.25.5 overrides the tag value regardless of what either file specifies.

Verifying Applied Values

After installation, check which values were used for a release:

helm get values my-nginx

This shows only the user-supplied overrides (values that differ from the chart defaults). To see all values including defaults:

helm get values my-nginx --all

Dry Run and Template Rendering

Before applying anything to the cluster, you can preview what Helm would generate:

helm install my-nginx bitnami/nginx --dry-run

This renders the templates with your values and prints the resulting Kubernetes manifests without applying them. Use this to verify that your value overrides produce the expected YAML.

For template rendering without connecting to the cluster:

helm template my-nginx bitnami/nginx -f custom-values.yaml

The helm template command renders the chart locally and outputs the resulting manifests to stdout. This is useful for piping into kubectl apply --dry-run=client or for inspecting manifests in CI pipelines.

Validating Rendered Output

Combine helm template with kubectl dry-run for server-side validation:

helm template my-nginx bitnami/nginx -f custom-values.yaml | kubectl apply --dry-run=server -f -

This renders the templates locally, then sends the resulting manifests to the API server for validation without applying them. The server checks that resource names are valid, required fields are present, and referenced resources (like StorageClasses) exist. This catches errors that client-side validation misses.

Connecting the Concepts

Charts define what gets deployed. Values customize how it’s deployed. Repositories distribute charts to consumers. Releases track deployed instances. These four concepts form a complete lifecycle:

  1. Add a repository — helm repo add registers a chart source
  2. Search for charts — helm search repo discovers available packages
  3. Inspect values — helm show values reveals configurable parameters
  4. Override values — --set or -f customizes the deployment
  5. Install as a release — the next section covers this step

With the chart found and the values prepared, the next section walks through the full release lifecycle: installation, upgrade, rollback, and removal.