Lesson 10 Helm Chart for the Two Services
Theme:

Homework 10 — Helm Chart for the Two Services

Lesson 10 · Cloud Infrastructure & DevOps · Three tasks

These three tasks extend the chart from the lab. Each addresses a real production concern: install verification, input validation, and CI fixture management. You will need the kind cluster from Lab 10 running, or re-create it before beginning Tasks 1 and 2.

Task 1 — Add a chart-test hook

Helm supports test hooks: pods that run after install and verify the release works. A test hook is a Job (or Pod) annotated with helm.sh/hook: test. After helm install or helm upgrade, you run helm test <release> to execute all test hooks and collect pass/fail results. ct install runs helm test automatically during chart-testing.

  1. Create sample-app/helm/templates/tests/test-api-healthz.yaml with a Kubernetes Job that:
    • Is annotated helm.sh/hook: test.
    • Is annotated helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded (so it doesn’t accumulate stale pods).
    • Uses image curlimages/curl:8.5.0.
    • Runs curl -fsS "http://<api-service>/healthz" and exits non-zero on failure.
    • Uses restartPolicy: Never.
  2. Install the chart (or upgrade an existing release) and run the test: 
    helm upgrade --install shortener helm/ \
  -f helm/values-dev.yaml \
  --namespace shortener --create-namespace --wait
helm test shortener -n shortener
  3. Check that ct install picks up the test automatically (it calls helm test after the install step).

✓ Self-check: helm test shortener -n shortener reports Phase: Succeeded for the test pod. Running ct install --chart-dirs sample-app --charts sample-app/helm locally includes a Running chart tests... line in the output.

Task 2 — Add a values.schema.json

Helm validates user-supplied values against a JSON Schema (draft 7) placed at helm/values.schema.json. Schema validation runs at helm install, helm upgrade, and helm lint — before templates are rendered, so bad input fails loudly at the gate rather than producing a subtly broken manifest.

  1. Create sample-app/helm/values.schema.json that:
    • Requires the image, api, worker, and postgres top-level keys.
    • Requires image.repository to be a non-empty string.
    • Validates api.replicas is an integer ≥ 1.
    • Constrains postgres.storage to either the literal string "ephemeral" or a size string matching ^[0-9]+Gi$.
    • Does not use "additionalProperties": false at the root (this would break any future value addition).
  2. Verify it works: 
    helm lint helm/ -f helm/values-prod.yaml       # should pass
helm lint helm/ --set api.replicas=0           # should fail

✓ Self-check: helm lint with a valid values file passes; helm lint --set api.replicas=0 fails with a JSON Schema validation error mentioning api.replicas.

Task 3 — Add a values-ci.yaml for chart-testing

ct install automatically discovers any YAML file under helm/ci/ and uses each as a separate install permutation. This is the standard way to provide CI-friendly overrides without polluting values.yaml or the per-env files. Common use: override postgres.storage: ephemeral (no PVC required in the ephemeral CI cluster), force secrets.inChart: true, and set image.pullPolicy: IfNotPresent for speed.

  1. Create the directory sample-app/helm/ci/.
  2. Create sample-app/helm/ci/test-values.yaml with values suitable for chart-testing on a local kind cluster: ephemeral storage, secrets in-chart, no ingress.
  3. Push the change and open a PR. In the CI workflow log, confirm that ct install reports --values .../ci/test-values.yaml being picked up automatically.

✓ Self-check: the chart-testing CI workflow log shows the ci/test-values.yaml path referenced in the ct install invocation, and the install step still passes.

View solutions →