Helm Values Gotcha

Helm, the package manager for Kubernetes, simplifies deploying and managing Kubernetes applications. Helm Charts, the packages Helm manages, use a combination of default and environment-specific values to configure these applications. However, a common challenge arises when dealing with multiple values files. This article dives into how Helm merges values from different files and provides strategies to effectively manage them.

The Basics of Helm Chart Values

Helm Charts use a values.yaml file to define default configuration parameters. This file acts as the foundational configuration for a chart. Here's an example structure of a simple Helm Chart:

my-chart/
├── charts/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   └── service.yaml

Default Values File: values.yaml

# values.yaml
replicaCount: 1
image:
  repository: nginx
  tag: stable
service:
  type: ClusterIP
  port: 80

Introducing Environment-Specific Values Files

In real-world scenarios, you might need different configurations for different environments (e.g., development, staging, production). This is where additional values files like values-prod.yaml come into play.

# values-prod.yaml
replicaCount: 3
image:
  tag: latest

The Gotcha: Merging Values

When deploying or upgrading a chart, Helm merges values from these files. However, it does so in a specific manner:

1. values.yaml provides the base configuration.
2. Additional values files (e.g., values-prod.yaml) override values in values.yaml.

Command to Deploy with Environment-Specific Values:

$ helm upgrade --install my-release my-chart/ -f my-chart/values-prod.yaml

In this command, my-release is the release name, and my-chart/ is the chart directory. The -f flag specifies the custom values file.

Understanding the Merge Behavior

The crucial point is that only the values explicitly defined in values-prod.yaml override those in values.yaml. If a parameter is defined in values.yaml but not in values-prod.yaml, the value from values.yaml is used.

Example:

• replicaCount in values-prod.yaml overrides the default in values.yaml.
• service.type and service.port are not defined in values-prod.yaml, so the defaults from values.yaml are used.

Best Practices for Managing Values Files

1. Explicit Overrides: Clearly define overrides in environment-specific values files. If a default value should not be used, explicitly set it to null or an empty value in the specific values file.
2. Documentation: Comment your values files extensively. Explain each parameter, especially why certain overrides are necessary for specific environments.
3. Version Control: Keep your values files under version control. This practice helps in tracking changes and understanding the evolution of your configurations.

Conclusion

Understanding how Helm merges values from different files is key to effectively managing configurations across environments. By explicitly defining overrides and documenting your configurations, you can avoid surprises and maintain control over your Kubernetes applications' behaviour.