Chart templates and values.yaml in Kubernetes - Step-by-Step Execution

Process Flow - Chart templates and values.yaml

Start: Helm Chart

↓

Read values.yaml

↓

Load templates

↓

Substitute values into templates

↓

Generate Kubernetes manifests

↓

Deploy manifests to cluster

Helm reads values.yaml, loads templates, replaces placeholders with values, then creates Kubernetes manifests for deployment.

Execution Sample

Kubernetes

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Values.name }}-config
  labels:
    app: {{ .Values.app }}

A Helm template for a ConfigMap using values from values.yaml to fill name and app labels.

Process Table

Step	Action	Template Line	Value Used	Resulting Line
1	Read values.yaml	name: myapp	name=myapp	name: myapp
2	Read values.yaml	app: demo	app=demo	app: demo
3	Load template line	metadata.name: {{ .Values.name }}-config	name=myapp	metadata.name: myapp-config
4	Load template line	labels.app: {{ .Values.app }}	app=demo	labels.app: demo
5	Generate final manifest	Full ConfigMap	Values substituted	ConfigMap with name 'myapp-config' and label 'app: demo'

💡 All placeholders replaced with values from values.yaml, manifest ready for deployment

Status Tracker

Variable	Start	After Step 1	After Step 3	Final
name	undefined	myapp	myapp	myapp
app	undefined	demo	demo	demo

Key Moments - 2 Insights

Why does {{ .Values.name }} get replaced with 'myapp'?

Because in the execution_table at Step 1, values.yaml defines name as 'myapp', which Helm uses to substitute in the template at Step 3.

What happens if a value is missing in values.yaml?

Helm will leave the placeholder empty or use a default if defined; this is shown by no substitution in the execution_table rows for that value.

Visual Quiz - 3 Questions

Look at the execution_table at Step 3, what is the resulting line after substitution?

A metadata.name: config-myapp

B metadata.name: {{ .Values.name }}-config

C metadata.name: myapp-config

D metadata.name: myapp

💡 Hint

Check the 'Resulting Line' column at Step 3 in the execution_table.

At which step does Helm read the values.yaml file?

A Step 1

B Step 3

C Step 5

D Step 4

💡 Hint

Look at the 'Action' column in the execution_table for when values.yaml is read.

If the values.yaml had app: 'testapp' instead of 'demo', what would be the label in the final manifest?

A app: demo

B app: testapp

C app: myapp

D app: config

💡 Hint

Refer to the variable_tracker for 'app' value changes and the substitution in Step 4.

Concept Snapshot

Helm charts use templates with placeholders like {{ .Values.key }}.
Values.yaml provides the actual values.
Helm reads values.yaml, substitutes values into templates.
Generates Kubernetes manifests ready for deployment.
Missing values can cause empty fields or use defaults.
This process simplifies app configuration and deployment.

Full Transcript

This visual execution shows how Helm uses values.yaml and templates to create Kubernetes manifests. First, Helm reads values.yaml to get values like 'name' and 'app'. Then it loads the template file which contains placeholders such as {{ .Values.name }}. Helm replaces these placeholders with the actual values from values.yaml. For example, {{ .Values.name }} becomes 'myapp'. This substitution happens line by line, resulting in a complete manifest file. The final manifest can then be deployed to the Kubernetes cluster. If a value is missing in values.yaml, Helm may leave the placeholder empty or use a default if specified. This process helps manage configuration easily and consistently.

Practice

1. What is the main purpose of the values.yaml file in a Helm chart?

easy

A. To store default configuration values for templates

B. To define Kubernetes resource limits

C. To write deployment scripts

D. To list all Kubernetes nodes

Solution

1. Step 1: Understand Helm chart structure

   Helm charts use templates with placeholders to create Kubernetes manifests dynamically.

2. Step 2: Role of values.yaml

   The values.yaml file provides default values for these placeholders, allowing customization without changing templates.

3. Final Answer:

   To store default configuration values for templates -> Option A

4. Quick Check:

   values.yaml = default settings [OK]

Hint: Remember: values.yaml holds default settings for templates [OK]

Common Mistakes:

• Confusing values.yaml with deployment scripts
• Thinking it defines resource limits directly
• Assuming it lists Kubernetes nodes

2. Which of the following is the correct syntax to reference a value named replicaCount from values.yaml inside a Helm template?

easy

A. {{ .Values.replicaCount }}

B. {{ .replicaCount }}

C. {{ values.replicaCount }}

D. {{ .Config.replicaCount }}

Solution

1. Step 1: Understand Helm template syntax

   Helm templates access values using the .Values object followed by the key name.

2. Step 2: Match syntax for replicaCount

   The correct way is {{ .Values.replicaCount }} to get the value from values.yaml.

3. Final Answer:

   {{ .Values.replicaCount }} -> Option A

4. Quick Check:

   Use .Values.key to access values [OK]

Hint: Use .Values.key to get values in templates [OK]

Common Mistakes:

• Omitting the .Values prefix
• Using lowercase 'values' instead of .Values
• Confusing .Config with .Values

3. Given this snippet in values.yaml:

replicaCount: 3
image:
  repository: nginx
  tag: stable

What will be the output of this Helm template snippet?

{{ .Values.replicaCount }} replicas of {{ .Values.image.repository }}:{{ .Values.image.tag }}

medium

A. replicaCount replicas of image.repository:image.tag

B. Error: undefined values

C. 3 replicas of nginx:latest

D. 3 replicas of nginx:stable

Solution

1. Step 1: Read values.yaml keys and values

   replicaCount is 3, image.repository is 'nginx', and image.tag is 'stable'.

2. Step 2: Substitute values in template

   The template outputs: '3 replicas of nginx:stable' by replacing placeholders with values.

3. Final Answer:

   3 replicas of nginx:stable -> Option D

4. Quick Check:

   Values replaced correctly = 3 replicas of nginx:stable [OK]

Hint: Match keys exactly to get correct output [OK]

Common Mistakes:

• Using wrong tags like 'latest' instead of 'stable'
• Not accessing nested keys properly
• Expecting literal placeholders in output

4. You have this template snippet:

{{ if .Values.enableFeature }}Feature is enabled{{ else }}Feature is disabled{{ end }}

But the output always shows "Feature is disabled" even when you set enableFeature: true in values.yaml. What is the likely cause?

medium

A. The template syntax is incorrect and missing a closing tag

B. enableFeature is set as a string "true" instead of boolean true

C. The values.yaml file is not saved properly

D. Helm does not support boolean values in values.yaml

Solution

1. Step 1: Check boolean handling in values.yaml

   YAML treats unquoted true as boolean, but quoted "true" is a string, which evaluates as true in some contexts but false in Helm conditionals.

2. Step 2: Understand Helm conditional evaluation

   Helm expects boolean true, so if enableFeature is a string, the condition fails and goes to else.

3. Final Answer:

   enableFeature is set as a string "true" instead of boolean true -> Option B

4. Quick Check:

   Boolean true must be unquoted in values.yaml [OK]

Hint: Use unquoted true/false for booleans in values.yaml [OK]

Common Mistakes:

• Quoting booleans as strings
• Assuming template syntax error without checking values
• Not saving values.yaml after changes

5. You want to create a Helm chart template that sets the container port only if service.port is defined in values.yaml. Which template snippet correctly implements this conditional logic?

hard

A. {{- if .Values.service.port }}
containerPort: "{{ .Values.service.port }}"
{{- else }}
containerPort: 80
{{- end }}

B. {{- if .service.port }}
containerPort: {{ .service.port }}
{{- end }}

C. {{- if .Values.service.port }}
containerPort: {{ .Values.service.port }}
{{- end }}

D. {{- if .Values.service.port != null }}
containerPort: {{ .Values.service.port }}
{{- end }}

Solution

1. Step 1: Identify correct value reference

   Use .Values.service.port to access the port value from values.yaml.

2. Step 2: Use proper conditional syntax

   Helm templates use {{- if .Values.service.port }} to check if the value exists and is non-empty.

3. Step 3: Evaluate options

   {{- if .Values.service.port }} containerPort: {{ .Values.service.port }} {{- end }} correctly uses the conditional and outputs the port only if defined. {{- if .service.port }} containerPort: {{ .service.port }} {{- end }} misses .Values. {{- if .Values.service.port }} containerPort: "{{ .Values.service.port }}" {{- else }} containerPort: 80 {{- end }} adds an else block which is not requested. {{- if .Values.service.port != null }} containerPort: {{ .Values.service.port }} {{- end }} uses invalid syntax (!= null is not valid in Helm templates).

4. Final Answer:

   {{- if .Values.service.port }} containerPort: {{ .Values.service.port }} {{- end }} -> Option C

5. Quick Check:

   Use if .Values.key for conditionals [OK]

Hint: Check existence with if .Values.key, no need for != null [OK]

Common Mistakes:

• Omitting .Values prefix
• Using invalid comparison operators
• Adding unnecessary else blocks