Homework

Three tasks to master _helpers.tpl, define/include, scope control, and DRY patterns in Helm charts.

Setup: Start each task with a fresh chart created via helm create. All tasks can be completed locally using helm template -- no running cluster is required, though you may optionally install to verify.

Tasks

Task 1 — Multi-Image Helper with Registry Support

Create a Helm chart for a microservice that has three containers: app, sidecar-proxy, and log-collector. Each container uses a different image.

In values.yaml, define each container's image with registry, repository, and tag fields.
Write a single named template called mychart.imageRef in _helpers.tpl that takes an image dict and produces a fully qualified reference: registry/repository:tag. If registry is empty, omit it. If tag is empty, fall back to .Chart.AppVersion.
Use the helper in templates/deployment.yaml for all three containers, passing the correct image dict each time using a dict call.

Self-check

✓ Run helm template myrel . and confirm all three container images render correctly.
✓ Run helm template myrel . --set app.image.registry=ghcr.io and verify only the app container includes the registry prefix.
✓ Run helm template myrel . --set app.image.tag=v3.0 and verify the app uses v3.0 while the others fall back to appVersion.
✓ Run helm lint . with zero errors.

Task 2 — Scope, the Dot, and $ in Range Loops

Create a chart that generates a ConfigMap per environment using range over a list in values, while still accessing root-level helpers inside the loop.

In values.yaml, define a list called environments with three entries, each having name (e.g., dev, staging, prod) and logLevel fields.
Create templates/configmaps.yaml that uses {{- range .Values.environments }} to produce one ConfigMap per entry.
Each ConfigMap must:
- Be named <fullname>-<env-name>-config using the mychart.fullname helper (requires $ since dot is rebound inside range).
- Include the standard labels via include "mychart.labels" $.
- Have data keys ENV and LOG_LEVEL populated from the current range item.

Self-check

✓ helm template myrel . produces exactly three ConfigMaps with distinct names (e.g., myrel-mychart-dev-config).
✓ Each ConfigMap carries the full label set (including app.kubernetes.io/name and app.kubernetes.io/instance).
✓ Removing the $ in the include call and running helm template produces an error -- this confirms you understand scope rebinding.

Task 3 — DRY Probes and Annotations via Helpers

Build a chart with a Deployment and a CronJob that share the same health-probe configuration and annotation set.

Write a helper mychart.httpProbe that accepts a dict with path, port, and initialDelay keys, and outputs a complete httpGet probe block (suitable for both livenessProbe and readinessProbe).
Write a helper mychart.commonAnnotations that merges .Values.global.annotations (a dict) with a resource-specific annotation dict passed as an argument. Use the Sprig merge function.
Use both helpers in the Deployment container spec and the CronJob container spec. The Deployment should add its own annotation (deploy-version), while the CronJob adds a different one (schedule-owner).
Pipe all helper output through nindent at the correct indentation level -- do not use the template action.

Self-check

✓ helm template myrel . --set global.annotations.team=sre shows team: sre in annotations on both the Deployment and the CronJob.
✓ The Deployment has deploy-version but not schedule-owner; the CronJob has the reverse.
✓ Probe blocks in both resources are identical, produced by the same helper.
✓ Changing values.yaml probe settings (path or port) updates both resources -- verify with two helm template runs.
✓ helm lint . reports zero errors.

Grading Rubric

Criterion	Excellent	Satisfactory	Needs Work
Helper Design	Helpers are generic, accept dicts or scoped data, and produce clean YAML with no trailing whitespace	Helpers work but are tightly coupled to specific values paths	Helpers are missing or use `template` instead of `include`
Scope & Dot	Correctly uses `$` inside `range`/`with`; can explain why it is needed; passes custom dicts to helpers	Uses `$` correctly but cannot explain the mechanism	Scope errors in rendered output; labels or names missing inside loops
nindent Usage	All helper invocations use `include` piped to `nindent` at the correct level; YAML is valid	Indentation mostly correct with minor cosmetic issues	Broken YAML due to incorrect indentation; uses `template` with attempted pipe
DRY Principle	No duplicated YAML blocks; every repeated fragment is extracted into a named template	Most duplication removed but one or two blocks remain inlined	Significant copy-paste between templates; helpers exist but are unused
Validation	`helm lint` passes with zero warnings; `helm template` output is valid Kubernetes YAML	Lint passes but template output has minor issues (e.g., empty values)	Lint errors or template rendering failures

Tip: When debugging helpers, use helm template . --debug to see the full rendering trace. If indentation looks wrong, double-check your nindent value -- it counts from the start of the line, not from the current cursor position. A quick way to verify: pipe template output through kubectl apply --dry-run=client -f - to catch YAML structure errors.