Chart values and customization in Kubernetes - Step-by-Step Execution

Process Flow - Chart values and customization

Start with default Chart

↓

Create values.yaml

↓

Edit values.yaml to customize

↓

Run helm install/upgrade with values

↓

Helm merges values with Chart templates

↓

Kubernetes resources created with custom settings

↓

End

This flow shows how Helm uses a values.yaml file to customize a Chart before deploying Kubernetes resources.

Execution Sample

Kubernetes

helm install myapp ./mychart -f custom-values.yaml
kubectl get pods
helm upgrade myapp ./mychart -f custom-values.yaml

Install and upgrade a Helm Chart using a custom values file to change settings.

Process Table

Step	Command/Action	Values Used	Effect	Output/Result
1	helm install myapp ./mychart -f custom-values.yaml	custom-values.yaml overrides defaults	Chart templates rendered with custom values	Release 'myapp' installed, resources created
2	kubectl get pods	N/A	Check running pods	Shows pods with names from 'myapp' release
3	helm upgrade myapp ./mychart -f custom-values.yaml	custom-values.yaml overrides defaults	Chart templates re-rendered with updated values	Release 'myapp' upgraded, resources updated
4	kubectl get pods	N/A	Verify pods after upgrade	Pods reflect updated configuration
5	Exit	N/A	Process complete	Custom values applied successfully

💡 All steps complete; Helm applied custom values to Kubernetes resources

Status Tracker

Variable	Start	After Install	After Upgrade	Final
replicaCount	3 (default)	5 (custom-values.yaml)	5 (custom-values.yaml)	5
image.tag	"1.0.0" (default)	"2.1.0" (custom-values.yaml)	"2.1.0" (custom-values.yaml)	"2.1.0"
service.type	"ClusterIP" (default)	"LoadBalancer" (custom-values.yaml)	"LoadBalancer" (custom-values.yaml)	"LoadBalancer"

Key Moments - 3 Insights

Why does Helm use values.yaml instead of changing templates directly?

Helm keeps templates generic and uses values.yaml to customize deployments easily without editing templates. See execution_table step 1 where custom-values.yaml changes settings without touching templates.

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

Helm uses the default value from the Chart's values.yaml. This is why in variable_tracker some variables start with defaults and only change if overridden.

How does Helm apply changes on upgrade?

Helm re-renders templates with updated values and applies changes to Kubernetes resources, shown in execution_table step 3 and 4 where upgrade updates pods.

Visual Quiz - 3 Questions

Look at the variable_tracker after install. What is the replicaCount value?

A 1

B 3

C 5

D 0

💡 Hint

Check the 'After Install' column for replicaCount in variable_tracker

At which step in execution_table does Helm upgrade the release?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look for the 'helm upgrade' command in execution_table

If custom-values.yaml did not specify image.tag, what would happen?

A The default image.tag from Chart is used

B Helm would fail to deploy

C Pods would not start

D Helm ignores image.tag completely

💡 Hint

Refer to key_moments about missing values and variable_tracker start values

Concept Snapshot

Helm Charts use values.yaml files to customize deployments.
Custom values override defaults without changing templates.
Use 'helm install -f values.yaml' to apply custom settings.
Upgrades reapply templates with updated values.
Missing values fall back to Chart defaults.
This keeps deployments flexible and reusable.

Full Transcript

This visual execution shows how Helm uses a values.yaml file to customize Kubernetes deployments. First, a Helm Chart has default values. We create a custom-values.yaml file to override some settings like replica count and image tag. When we run 'helm install' with the custom values file, Helm merges these values with the Chart templates and deploys resources accordingly. We verify pods are running with 'kubectl get pods'. Later, we run 'helm upgrade' with the same custom values to update the deployment. Helm re-renders templates with the updated values and applies changes to the cluster. Variables like replicaCount and image.tag change from defaults to custom values, as tracked in the variable tracker. Key moments clarify why values.yaml is used, what happens if values are missing, and how upgrades apply changes. The quiz tests understanding of these steps and variable changes. This process helps keep Helm Charts reusable and easy to customize for different environments.

Practice

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

easy

A. To define Kubernetes cluster nodes

B. To store the application source code

C. To provide default configuration values for the chart

D. To list all installed Helm charts

Solution

1. Step 1: Understand the role of values.yaml

   The values.yaml file contains default settings that the Helm chart uses when installing an app.

2. Step 2: Compare other options

   Options B, C, and D describe unrelated tasks: source code, cluster nodes, and installed charts, which are not the purpose of values.yaml.

3. Final Answer:

   To provide default configuration values for the chart -> Option C

4. Quick Check:

   Default config = values.yaml [OK]

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

Common Mistakes:

• Confusing values.yaml with application code
• Thinking values.yaml manages cluster nodes
• Assuming values.yaml lists installed charts

2. Which of the following is the correct way to override a Helm chart value from the command line?

easy

A. helm install myapp ./chart --set image.tag=1.2.3

B. helm install myapp ./chart -override image.tag=1.2.3

C. helm install myapp ./chart --config image.tag=1.2.3

D. helm install myapp ./chart --change image.tag=1.2.3

Solution

1. Step 1: Recall Helm syntax for setting values

   The correct flag to override values is --set, followed by the key=value pair.

2. Step 2: Check other options for correctness

   Options A, C, and D use invalid flags (-override, --config, --change) which Helm does not recognize.

3. Final Answer:

   helm install myapp ./chart --set image.tag=1.2.3 -> Option A

4. Quick Check:

   Override values with --set [OK]

Hint: Use --set key=value to override values [OK]

Common Mistakes:

• Using incorrect flags like --config or --change
• Forgetting to use --set for overrides
• Misplacing the key=value syntax

3. Given this snippet from values.yaml:

replicaCount: 2
image:
  repository: nginx
  tag: stable

What will be the replica count if you run:

helm install myapp ./chart --set replicaCount=5

medium

A. 2

B. 5

C. stable

D. nginx

Solution

1. Step 1: Understand default and override values

   The default replicaCount is 2 from values.yaml. The command line uses --set replicaCount=5 to override it.

2. Step 2: Determine final replica count

   Overrides from --set take priority, so replicaCount becomes 5.

3. Final Answer:

   5 -> Option B

4. Quick Check:

   Command line override changes replicaCount to 5 [OK]

Hint: Command line --set overrides values.yaml [OK]

Common Mistakes:

• Ignoring command line overrides
• Confusing image tag or repository with replicaCount
• Assuming default always applies

4. You tried to override a nested value with helm install myapp ./chart --set image.tag=1.0.0, but the deployment still uses the old tag. What is the most likely cause?

medium

A. The chart does not use the image.tag value in templates

B. You must use --set-string instead of --set

C. The values.yaml file is missing

D. You need to delete the release before installing

Solution

1. Step 1: Check if the chart templates use the overridden value

   If the chart templates do not reference image.tag, overriding it has no effect.

2. Step 2: Evaluate other options

   Using --set-string is only needed for forcing string types, not usually for tags. Missing values.yaml would cause defaults to fail, and deleting release is unrelated to value overrides.

3. Final Answer:

   The chart does not use the image.tag value in templates -> Option A

4. Quick Check:

   Override ignored if template doesn't use value [OK]

Hint: Ensure templates use the value you override [OK]

Common Mistakes:

• Assuming --set always works without template usage
• Confusing --set and --set-string flags
• Thinking release deletion is needed for overrides

5. You want to customize a Helm chart to deploy multiple instances of the same app with different configurations. Which approach best supports this?

hard

A. Install the chart once and manually edit Kubernetes resources

B. Edit the chart source code to hardcode different values

C. Use helm upgrade without changing values

D. Create separate values.yaml files for each instance and install with --values

Solution

1. Step 1: Understand multi-instance customization

   Using separate values.yaml files allows you to define different settings for each instance without changing the chart code.

2. Step 2: Evaluate other options

   Editing chart source is complex and error-prone. Using helm upgrade without changes won't customize. Manually editing resources breaks Helm management.

3. Final Answer:

   Create separate values.yaml files for each instance and install with --values -> Option D

4. Quick Check:

   Use multiple values files for multi-instance customization [OK]

Hint: Use different values files per instance with --values [OK]

Common Mistakes:

• Hardcoding values in chart source
• Ignoring Helm's value override features
• Manually editing deployed resources