Bird
Raised Fist0
Kubernetesdevops~5 mins

Chart values and customization in Kubernetes - Commands & Configuration

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
When you install software on Kubernetes using Helm charts, you often want to change how it works. Chart values let you customize settings easily without changing the main files. This helps you adjust the app to your needs.
When you want to change the number of app replicas to handle more users.
When you need to set a custom image version for your app.
When you want to enable or disable features like logging or monitoring.
When you want to add environment variables to your app containers.
When you want to change resource limits like CPU or memory for your app.
Config File - values.yaml
values.yaml
replicaCount: 3
image:
  repository: nginx
  tag: stable
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 250m
    memory: 128Mi

This values.yaml file sets the number of replicas to 3, uses the stable nginx image, and defines resource limits and requests for CPU and memory. It also sets the service type and port. You can change these values to customize your app deployment without editing the main chart files.

Commands
This command installs the nginx chart using the custom settings from the values.yaml file. It applies your changes like replica count and resource limits.
Terminal
helm install my-nginx nginx -f values.yaml
Expected OutputExpected
NAME: my-nginx LAST DEPLOYED: Fri Apr 26 12:00:00 2024 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None
-f - Specifies the custom values file to override default chart settings
This command lists the pods running in your Kubernetes cluster to verify that your app pods are created with the custom settings.
Terminal
kubectl get pods
Expected OutputExpected
NAME READY STATUS RESTARTS AGE my-nginx-5d8f9d7f7b-abcde 1/1 Running 0 1m my-nginx-5d8f9d7f7b-fghij 1/1 Running 0 1m my-nginx-5d8f9d7f7b-klmno 1/1 Running 0 1m
This command updates the existing nginx release with any changes made in the values.yaml file, allowing you to customize the app after installation.
Terminal
helm upgrade my-nginx nginx -f values.yaml
Expected OutputExpected
Release "my-nginx" has been upgraded. Happy Helming! NAME: my-nginx LAST DEPLOYED: Fri Apr 26 12:05:00 2024 NAMESPACE: default STATUS: deployed REVISION: 2 TEST SUITE: None
-f - Uses the custom values file for the upgrade
This command shows the current values used by the installed nginx release, so you can check what customizations are active.
Terminal
helm get values my-nginx
Expected OutputExpected
replicaCount: 3 image: repository: nginx tag: stable pullPolicy: IfNotPresent service: type: ClusterIP port: 80 resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi
Key Concept

If you remember nothing else from this pattern, remember: customizing Helm chart values lets you change app settings easily without touching the main chart files.

Common Mistakes
Editing the chart's default values.yaml file directly inside the chart folder.
This can cause problems when upgrading the chart because your changes may be overwritten.
Always create and use a separate custom values.yaml file and pass it with the -f flag during install or upgrade.
Not specifying the -f flag when installing or upgrading, so the default values are used.
Your custom settings will be ignored and the app will run with default configurations.
Always include -f values.yaml to apply your custom settings.
Changing values that do not exist or are misspelled in the custom values file.
Helm will ignore unknown keys, so your changes won't take effect and can cause confusion.
Check the chart documentation for valid keys and use correct spelling and indentation.
Summary
Create a custom values.yaml file to set your app's configuration like replicas, image, and resources.
Use helm install or helm upgrade with the -f flag to apply your custom values.
Verify your app pods with kubectl get pods and check active values with helm get values.

Practice

(1/5)
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