Chart templates and values.yaml in Kubernetes - Commands & Configuration

Introduction

When you want to deploy apps on Kubernetes, you often need to repeat similar settings with small changes. Chart templates and values.yaml help you write these settings once and reuse them easily with different values.

When you want to deploy the same app multiple times with different configurations like ports or replicas.

When you want to share your app deployment setup with others without hardcoding details.

When you want to update app settings quickly by changing values without editing many files.

When you want to keep your Kubernetes files clean and easy to understand by separating data from templates.

When you want to automate app deployments with tools like Helm using reusable templates.

Config File - deployment.yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.app.name }}
  labels:
    app: {{ .Values.app.name }}
spec:
  replicas: {{ .Values.app.replicas }}
  selector:
    matchLabels:
      app: {{ .Values.app.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.app.name }}
    spec:
      containers:
      - name: {{ .Values.app.name }}-container
        image: {{ .Values.app.image }}
        ports:
        - containerPort: {{ .Values.app.port }}

This is a Kubernetes Deployment template file using Helm syntax.

• {{ .Values.app.name }} inserts the app name from values.yaml.
• replicas sets how many copies of the app run.
• image is the container image to use.
• containerPort is the port the app listens on.

This template lets you change these values easily without editing this file.

Commands

Creates a new Helm chart named 'my-app' with default templates and a values.yaml file.

Terminal

helm create my-app

Expected Output

Creating new chart 'my-app'

Shows the default values.yaml file where you can set app-specific values used in templates.

Terminal

cat my-app/values.yaml

Expected Output

replicaCount: 1

image:

  repository: nginx

  pullPolicy: IfNotPresent

  tag: ""

service:

  type: ClusterIP

  port: 80

Installs the Helm chart with custom values overriding defaults to deploy 3 replicas of the app on port 8080.

Terminal

helm install example-release my-app --set replicaCount=3,image.repository=myapp/image,image.tag=v1.0,service.port=8080

Expected Output

NAME: example-release

LAST DEPLOYED: Thu Apr 27 12:00:00 2024

NAMESPACE: default

STATUS: deployed

REVISION: 1

TEST SUITE: None

→

--set - Override values.yaml settings directly from the command line

Displays the values used for the installed release to verify the applied configuration.

Terminal

helm get values example-release

Expected Output

replicaCount: 3

image:

  repository: myapp/image

  pullPolicy: IfNotPresent

  tag: v1.0

service:

  type: ClusterIP

  port: 8080

Key Concept

If you remember nothing else from this pattern, remember: templates define the structure and values.yaml provides the flexible data to customize deployments easily.

Common Mistakes

Editing the template files directly for each deployment instead of using values.yaml.

This causes duplication and makes updates hard because you must change many files.

Keep templates generic and change settings only in values.yaml or with --set flags.

Using incorrect Helm template syntax like missing curly braces or wrong variable names.

Helm will fail to render templates and the deployment will not work.

Use {{ .Values.key }} syntax exactly and test templates with 'helm template' command.

Not overriding values when installing the chart, so the app runs with default settings.

The deployment might not match your needs like wrong ports or image versions.

Use a custom values.yaml file or --set flags to provide correct values.

Summary

Helm chart templates use placeholders to define Kubernetes resources generically.

The values.yaml file holds the data that fills these placeholders for each deployment.

You can override values.yaml settings using the --set flag during helm install for quick changes.

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