Dynamic Manifests with Helm Templates

1. Helm Functions and Pipelines

At the heart of Helm's templating engine is the concept of functions and pipelines. You've already used simple value access like {{ .Values.replicaCount }}. A pipeline allows you to take that value and pass it through a series of functions, where the output of one becomes the input of the next. The pipe character | is used for this.

For example:
{{ .Values.appName | upper | quote }}

This pipeline does three things:

1. It retrieves the value of appName from values.yaml.
2. It passes this value to the upper function, which converts it to uppercase.
3. The result of upper is then passed to the quote function, which wraps it in double quotes, ensuring it's a valid YAML string.

Helm includes all of the functions from Go's Sprig library, giving you a vast toolkit for string manipulation, math, type conversions, and more.

2. Conditional Logic with if/else

One of the most common requirements in advanced charting is conditional logic. For example, you might want to create an Ingress resource only if a specific value is set to true in your values.yaml. This is handled with if/else blocks.

The basic syntax is:

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Release.Name }}-ingress
spec:



  # ... ingress spec
{{- end }}

• {{- if PIPELINE }}: The block is rendered only if the pipeline evaluates to true. In Helm, false, 0, nil, and empty strings/lists/dicts are considered false. Everything else is true.
• {{- end }}: This closes the if block.
• {{- and -}}: Notice the hyphens. These are for whitespace control. {{- removes whitespace to its left, and -}} removes it to its right. Using them is crucial for generating clean, valid YAML.

You can also build more complex logic with else if and else, using comparison functions like eq (equal), ne (not equal), gt (greater than), etc.

To dive deeper into the syntax and rules, the official Helm documentation is the best source.

3. Iterating with range

The range action allows you to loop through collections like lists (slices) and dictionaries (maps). This is incredibly useful for dynamically generating repeated blocks of YAML.

Ranging over a List

Imagine you want to define multiple container ports from a list in values.yaml:

values.yaml:

ports:
  - name: http
    containerPort: 80
  - name: metrics
    containerPort: 9100

deployment.yaml template:

ports:
{{- range .Values.ports }}
- name: {{ .name }}
  containerPort: {{ .containerPort }}
{{- end }}

Inside the range block, the dot (.) is scoped to the current item in the iteration. In the first loop, . refers to the first port object ({name: http, containerPort: 80}), and so on.

Ranging over a Dictionary

You can also iterate over key-value pairs in a map, which is perfect for generating labels or annotations:

values.yaml:

podAnnotations:
  prometheus.io/scrape: "true"
  prometheus.io/port: "9100"

deployment.yaml template:

spec:
  template:
    metadata:
      annotations:
      {{- range $key, $value := .Values.podAnnotations }}
        {{ $key }}: {{ $value | quote }}
      {{- end }}

Here, range assigns the key to $key and the value to $value for each item in the map.

4. Reusable Logic with Named Templates

As your charts grow, you'll often find yourself repeating the same snippets of code. A common example is the block of labels applied to every resource. Instead of copying and pasting, you can define this logic once in a named template and include it wherever needed.

These reusable templates are traditionally defined in the _helpers.tpl file. The define action creates the template, and include renders it.

5. Putting It All Together: A Comprehensive Example

Now that you understand the individual components, let's see how they work together in a realistic scenario. The following video demonstrates how to build a single, flexible Helm chart that can be deployed across multiple environments with significantly different configurations.

This walkthrough is dense but extremely practical for your role as a DevOps Engineer. It covers:

• Using if/end to conditionally enable/disable the HPA.
• Using named templates (include) and nindent for reusable labels.
• Rendering entire YAML blocks from values.yaml using toYaml.
• Dynamically selecting and rendering entire configuration files using variables, printf, and the .Files.Get function.

6. Debugging Your Dynamic Templates

As templates become more complex, debugging becomes essential. You need to be able to see the final rendered YAML before applying it to a cluster.

The helm template and helm install --dry-run commands are your best friends here.

A common debugging technique is to temporarily use the fail function to print out a value and stop the rendering process: {{ .Values | toPrettyJson | fail "Dumping values" }}. This will print the entire .Values object in a readable format.

Conclusion

You have now moved from basic value substitution to advanced dynamic manifest generation. By mastering functions, pipelines, and control structures, you can create professional, reusable, and highly flexible Helm charts that can adapt to any environment or configuration requirement.

Key Takeaways:

• Pipelines (|) chain functions together to transform data.
• if/else blocks provide conditional logic to include or exclude parts of a template based on values.
• range iterates over lists and maps, allowing you to generate repetitive YAML structures dynamically.
• Named templates (define/include) in _helpers.tpl promote code reuse and maintainability.
• Functions like toYaml and .Files.Get enable you to manage complex configuration blocks and entire files within your chart.

What's Next?

You've now mastered how to package and configure your applications with Helm. The next logical step is to automate the deployment of these packages. In the next lesson, we will explore the principles of GitOps and use ArgoCD to automatically deploy an application from a Git repository whenever changes are made. This will connect your packaging skills to a modern, declarative deployment workflow.