Chart templates and values.yaml in Kubernetes - Deep Dive

Overview - Chart templates and values.yaml

What is it?

Chart templates and values.yaml are key parts of Helm, a tool that helps manage Kubernetes applications. Chart templates are files that define Kubernetes resources using placeholders. The values.yaml file provides the actual data to fill those placeholders, making the templates flexible and reusable. Together, they let you customize deployments without changing the core templates.

Why it matters

Without chart templates and values.yaml, deploying apps on Kubernetes would mean writing full configuration files every time you want to change something. This is slow, error-prone, and hard to maintain. Using templates with values.yaml lets you reuse the same setup for different environments or versions easily, saving time and reducing mistakes.

Where it fits

Before learning this, you should understand basic Kubernetes concepts like pods, services, and deployments. After mastering chart templates and values.yaml, you can move on to advanced Helm features like hooks, chart dependencies, and creating your own Helm repositories.

Mental Model

Core Idea

Chart templates are like blueprints with blanks, and values.yaml is the form you fill out to customize each blueprint for your Kubernetes app.

Think of it like...

Imagine ordering a custom sandwich at a deli. The chart template is the sandwich menu with options like bread, meat, and toppings listed as blanks. The values.yaml is your order form where you specify exactly what you want in each blank. The kitchen then makes your sandwich exactly as you ordered without rewriting the menu.

Chart Template (blueprint) ──> uses placeholders like {{ .Values.name }}
          │
          ▼
values.yaml (form) ──> fills placeholders with actual values
          │
          ▼
Rendered Kubernetes YAML ──> ready to deploy

Build-Up - 7 Steps

1

Foundation

Understanding Helm Chart Structure

Concept: Learn what a Helm chart is and its basic folder and file layout.

A Helm chart is a package that contains all files needed to deploy an app on Kubernetes. It has a 'templates' folder with YAML files containing placeholders, and a 'values.yaml' file that holds default values. When you run Helm, it combines these to create Kubernetes manifests.

Result

You can identify the templates folder and values.yaml file inside a Helm chart directory.

Knowing the chart structure helps you find where to put your customizations and understand how Helm organizes deployment files.

2

Foundation

Basics of values.yaml File

Concept: Learn what the values.yaml file is and how it stores default configuration values.

The values.yaml file is a simple YAML file listing keys and values. These values fill the placeholders in templates. For example, you might have 'replicaCount: 3' in values.yaml, which sets how many pod copies to run.

Result

You can read and edit values.yaml to change app settings without touching templates.

Separating configuration from templates makes it easier to customize deployments for different environments.

3

Intermediate

Using Placeholders in Chart Templates

🤔Before reading on: do you think placeholders in templates are replaced by values.yaml automatically or do you need to write extra code to connect them? Commit to your answer.

Concept: Learn how templates use Go templating syntax to insert values from values.yaml.

Templates use double curly braces {{ }} to mark placeholders. Inside, you write expressions like {{ .Values.replicaCount }} to get the value from values.yaml. Helm processes these templates and replaces placeholders with actual values.

Result

Templates render into complete Kubernetes YAML files with values filled in.

Understanding the templating syntax is key to customizing deployments dynamically and avoiding hardcoded values.

4

Intermediate

Overriding values.yaml at Install Time

🤔Before reading on: do you think you can change values.yaml after packaging a chart, or must you edit the file directly before install? Commit to your answer.

Concept: Learn how to override default values.yaml settings when installing or upgrading a chart.

You can pass custom values using the --set flag or a separate YAML file with helm install or helm upgrade commands. This lets you change settings without modifying the original values.yaml file inside the chart.

Result

Your deployed app uses the overridden values instead of defaults.

Knowing how to override values at install time allows flexible deployments and environment-specific configurations without changing the chart package.

5

Intermediate

Conditional Logic in Templates

🤔Before reading on: do you think templates can include if-else conditions to change output based on values.yaml? Commit to your answer.

Concept: Learn how to use conditional statements in templates to control resource creation.

Templates support if, else, and with statements. For example, you can write {{- if .Values.enableFeature }} to include a resource only if enableFeature is true in values.yaml. This makes charts adaptable to different needs.

Result

Templates generate different Kubernetes resources depending on values.yaml settings.

Using conditionals in templates makes charts more powerful and reusable across scenarios.

6

Advanced

Template Functions and Pipelines

🤔Before reading on: do you think template functions can transform values.yaml data before rendering, or are values used as-is? Commit to your answer.

Concept: Learn how to use built-in functions and pipelines to manipulate data in templates.

Helm templates support many functions like 'default', 'quote', 'upper', and pipelines to chain them. For example, {{ .Values.name | default "app" | upper }} uses the value of name or 'app' if empty, then converts it to uppercase.

Result

Templates can produce customized output by transforming input values.

Mastering functions and pipelines lets you write concise, flexible templates that handle edge cases gracefully.

7

Expert

Complex Values and Nested Structures

🤔Before reading on: do you think values.yaml supports only simple key-value pairs or can it hold nested maps and lists? Commit to your answer.

Concept: Learn how to define and use complex nested data structures in values.yaml and access them in templates.

Values.yaml can contain nested maps and lists, like: replicaDetails: count: 3 labels: app: myapp In templates, you access nested values with dot notation: {{ .Values.replicaDetails.count }}. You can loop over lists with 'range' to create multiple resources.

Result

You can configure complex app settings and generate multiple Kubernetes objects dynamically.

Understanding nested values and loops unlocks advanced templating capabilities for real-world complex deployments.

Under the Hood

Helm uses the Go template engine to process chart templates. When you run helm install or helm template, Helm loads the templates and the values.yaml file. It merges default values with any overrides, then parses templates, replacing placeholders with actual values. The output is standard Kubernetes YAML manifests ready for kubectl to apply. This separation allows Helm to generate many variations from one chart.

Why designed this way?

Helm was designed to simplify Kubernetes app deployment by avoiding repetitive YAML writing. Using templates with values.yaml lets users customize deployments without duplicating files. The Go template engine was chosen for its power and flexibility. Alternatives like static files or complex scripting were rejected because they lacked reusability and clarity.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Chart Template│──────▶│  Template     │──────▶│ Rendered YAML │
│  (with {{}})  │       │  Engine (Go)  │       │ (K8s manifests)│
└───────────────┘       └───────────────┘       └───────────────┘
         ▲                      ▲                      ▲
         │                      │                      │
         │                      │                      │
┌───────────────┐       ┌───────────────┐              │
│ values.yaml   │──────▶│ Values Merged │──────────────┘
│ (default data)│       │ with overrides│
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think changing values.yaml inside a packaged chart affects already deployed releases? Commit yes or no.

Common Belief: If I edit values.yaml inside a chart after deployment, the running app will update automatically.

Reality: Changing values.yaml inside a packaged chart does not affect existing deployments. You must run helm upgrade with new values to update the app.

Why it matters: Assuming changes apply automatically can cause confusion and stale deployments, leading to bugs or outdated configurations.

Quick: Do you think templates can only use values.yaml data, or can they access environment variables directly? Commit your answer.

Common Belief: Templates can directly read environment variables from the system during rendering.

Reality: Templates cannot access environment variables directly. All data must come from values.yaml or passed explicitly via helm commands.

Why it matters: Expecting environment variables to work in templates can cause deployment failures or unexpected behavior.

Quick: Do you think values.yaml must contain all possible keys used in templates? Commit yes or no.

Common Belief: values.yaml must define every key used in templates, or rendering will fail.

Reality: Templates can use the 'default' function to provide fallback values if keys are missing in values.yaml.

Why it matters: Knowing this prevents errors and allows charts to be more flexible and robust.

Quick: Do you think you can use complex logic like loops and conditionals in values.yaml? Commit your answer.

Common Belief: values.yaml supports loops and conditionals to generate dynamic data structures.

Reality: values.yaml is static YAML data. Logic like loops and conditionals must be done inside templates, not in values.yaml.

Why it matters: Misunderstanding this leads to attempts to put logic in values.yaml, which is invalid and causes errors.

Expert Zone

1

Templates can be nested and include other templates using 'include' and 'template' functions, enabling modular chart design.

2

Using 'required' function in templates enforces mandatory values, preventing silent failures due to missing configuration.

3

Helm merges multiple values files and --set flags in a specific order, which can cause subtle overrides if not understood.

When NOT to use

For very simple or static Kubernetes apps, plain YAML files or Kustomize might be better choices. Helm's templating adds complexity and learning overhead that is unnecessary for small deployments.

Production Patterns

In production, teams use values.yaml files per environment (dev, staging, prod) and override them with CI/CD pipelines. Charts are stored in private Helm repositories. Templates use conditionals to enable or disable features dynamically. Complex apps split charts into subcharts for modularity.

Connections

Configuration Management

Chart templates and values.yaml build on the idea of separating configuration from code.

Understanding this separation helps grasp why tools like Ansible or Puppet also separate templates and variables for flexible automation.

Software Design Patterns

Templates with placeholders follow the 'Template Method' pattern where the structure is fixed but details vary.

Recognizing this pattern clarifies how Helm charts provide a reusable deployment framework with customizable parts.

Cooking Recipes

Like a recipe template with ingredient lists, chart templates define steps and values.yaml lists ingredients.

This connection shows how separating instructions from ingredients allows cooking many dishes from one recipe format.

Common Pitfalls

#1 Editing values.yaml inside a packaged chart to change deployment settings.

Wrong approach:

helm install myapp ./mychart
# Then edit ./mychart/values.yaml and expect changes
kubectl get pods # No change seen

Correct approach:

helm install myapp ./mychart --values custom-values.yaml
# Or
helm upgrade myapp ./mychart --set replicaCount=5

Root cause:

Misunderstanding that packaged charts are static and deployed apps do not auto-update from chart files.

#2 Using environment variables directly in templates.

Wrong approach:

In template.yaml: image: {{ .Env.IMAGE_TAG }}

Correct approach:

Pass environment variables via values.yaml or --set, then use {{ .Values.imageTag }} in templates.

Root cause:

Confusing Helm template context with shell environment variables.

#3 Not using default values in templates causing rendering errors when keys are missing.

Wrong approach:

replicas: {{ .Values.replicaCount }}

Correct approach:

replicas: {{ .Values.replicaCount | default 1 }}

Root cause:

Assuming all values.yaml keys are always present.

Key Takeaways

Helm chart templates use placeholders filled by values.yaml to create flexible Kubernetes manifests.

Separating configuration (values.yaml) from templates allows easy customization without changing core files.

You can override values.yaml defaults at install time using --set or custom files for environment-specific setups.

Templates support logic like conditionals and loops to adapt resource creation based on values.

Understanding Helm's rendering process and value merging prevents common deployment mistakes and enables advanced usage.