✦ For everyone, free.

Practical knowledge for real and everyday life

Home

Chart Values

Chart Values define configurable parameters in Helm charts, enabling flexible deployment of applications across different environments and configurations.

Chart Values define the default and user-supplied configuration settings for a Helm chart, enabling customization and parameterization of Kubernetes resources generated by the chart. They serve as a centralized collection of key-value pairs specifying configuration parameters that templates use to render Kubernetes manifests dynamically. By adjusting these values, users can tailor deployments to different environments, requirements, or operational preferences without altering the underlying templates.

Purpose and Role of Chart Values

Chart Values act as the primary interface for users to configure a Helm chart. They provide a flexible mechanism for defining options such as image tags, resource limits, replica counts, environment variables, service ports, and other deployment-specific settings. This separation between the templates and the configuration allows charts to be reusable and adaptable.

When Helm processes a chart during installation or upgrade, it merges values from multiple sources, with values.yaml in the chart providing defaults. User-provided values override these defaults via command-line arguments (--set), separate values files (-f), or environment-specific overrides, ensuring that the most specific configuration takes precedence.

Structure and Content of Chart Values

Hierarchical Key-Value Organization

Chart Values are organized as a hierarchical YAML map, where keys represent configuration options and values can be primitives (strings, numbers, booleans), lists, or nested maps. This structure mirrors the configuration complexity and allows for logical grouping of related settings.

Example:

replicaCount: 3
image:
  repository: nginx
  tag: stable
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

Common Configuration Categories

  • Replica and Scaling Settings: Number of pod replicas or autoscaling parameters.
  • Container Image Settings: Repository, tag, and image pull policies.
  • Service Configuration: Type (ClusterIP, LoadBalancer), ports, and annotations.
  • Resource Requests and Limits: CPU and memory allocations for containers.
  • Environment Variables: Custom environment settings passed to containers.
  • Persistence and Storage: Volume claims, storage classes, and mount paths.
  • Ingress and Networking: Hostnames, TLS settings, and ingress annotations.
  • Feature Toggles: Boolean flags to enable or disable specific chart features.

Values Sources and Precedence

Chart Values can originate from several sources during chart deployment:

  1. Chart’s values.yaml File: Contains default values shipped with the chart.
  2. User-Supplied Values Files: Additional YAML files specified with -f or --values override defaults.
  3. Command-Line Overrides: Key-value pairs passed via --set or --set-string have the highest precedence.
  4. Chart Dependencies: Subcharts have their own values.yaml files, and parent charts can override those values via namespaced keys.

Helm merges these sources in order, with later sources overriding earlier ones. This merging supports fine-grained customization without modifying the original chart sources.

Validation and Schema Definition

To enhance reliability, charts can include a values.schema.json file defining JSON Schema validation rules for values. This schema describes allowed keys, data types, default values, enumerations, and constraints. Validation prevents incorrect or incomplete configurations from being applied, reducing runtime errors.

When a user installs or upgrades a chart, Helm validates the provided values against the schema and rejects invalid configurations early.

Usage in Templates

Within Helm templates, values are referenced using the .Values object, which exposes the merged configuration at render time. For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            limits:
              cpu: {{ .Values.resources.limits.cpu }}
              memory: {{ .Values.resources.limits.memory }}

This direct mapping allows dynamic manifest generation tailored to the user’s environment.

Best Practices for Defining Chart Values

  • Provide Sensible Defaults: Default values should enable a functional deployment without requiring user input.
  • Group Related Settings: Use nested maps to organize values logically and improve readability.
  • Document All Values: Include comments or separate documentation to explain each configurable parameter.
  • Avoid Hardcoding Values in Templates: Use values exclusively for configuration so users can customize as needed.
  • Use Consistent Naming: Adopt a naming convention for keys that is descriptive and predictable.
  • Support Overrides: Design the values structure to allow overriding subchart or dependency values cleanly.

Summary

Chart Values are the fundamental mechanism by which Helm charts achieve configurability and reuse. They encapsulate all user-customizable parameters as hierarchical key-value pairs, sourced from default files and user overrides, validated by optional schemas, and accessed within templates to produce dynamic Kubernetes manifests. Properly crafted Chart Values empower users to deploy complex applications flexibly and consistently across diverse environments.

Related content