Module 2 · Task — Write a Helm chart for podinfo (via Claude)

The task

Write a Helm chart that deploys podinfo (same image as module 1), parameterising the image tag, replica count, and service port. Install it into your kind cluster. Prove that overriding values at the CLI actually changes the running resources. Drive the work through Claude Code; read the templates before you apply them.

Acceptance test: helm upgrade podinfo ./podinfo-chart -n demo --set replicaCount=3 --set image.tag=6.7.0 --wait completes, then kubectl -n demo get pods -l app.kubernetes.io/name=podinfo-chart shows 3 pods running image tag 6.7.0.

Same ground rule as module 1: read every template Claude writes before you helm install. Templates are leverage — a bug in a template is a bug in every deployment.

Setup

From the same working directory as module 1 (or a sibling — it doesn't matter, Helm only needs the chart dir). Preflight:

• kind cluster from module 1 is up, or recreate it with the kind create cluster ... command Claude wrote for you.
• helm version prints a version. If not, ask Claude for the install command for your OS.
• The demo namespace exists.

Drive it through Claude

1. Scaffold the chart. Send Claude:

   "Scaffold a Helm chart called podinfo-chart using helm create. Keep the default layout. Show me the directory tree."

   Inspect the tree. Most of the scaffold is useful; the autoscaling and ingress templates you won't touch today.

2. Adjust values.yaml. Send:

   "Edit podinfo-chart/values.yaml so the image block uses ghcr.io/stefanprodan/podinfo tag 6.6.2, replicaCount: 1, and the service block is type: NodePort, port: 9898, with a new field nodePort: 30080. Set ingress.enabled: false and autoscaling.enabled: false."

   Open values.yaml. Ask Claude: why is a NodePort Service appropriate for kind but never for production? what would I use instead on GKE or EKS? You don't need to implement the alternative — just understand the trade-off before you ship the chart.

3. Wire nodePort into the Service template. Send:

   "In podinfo-chart/templates/service.yaml, add nodePort: {{ .Values.service.nodePort }} and set targetPort: 9898 (numeric, not named) on the single port entry. Keep port: {{ .Values.service.port }} as-is."

   Read templates/service.yaml. Ask: why is targetPort hardcoded to 9898 instead of parameterised? what goes wrong if targetPort and the container's containerPort drift? (Remember the break-on-purpose failure from module 1.)

4. Wire the container port + probes. Send:

   "In podinfo-chart/templates/deployment.yaml, set containerPort: 9898 and change livenessProbe to hit /healthz on port http, readinessProbe to hit /readyz on port http."

5. Clear the raw-YAML podinfo from module 1. Send:

   "Delete the raw Deployment and Service named podinfo in the demo namespace so the Helm install doesn't collide."

   Claude will run kubectl delete -n demo deployment podinfo and kubectl delete -n demo service podinfo. Confirm with kubectl -n demo get all.

6. Install and verify. Send:

   "Run helm install podinfo ./podinfo-chart -n demo --wait, then curl http://localhost:9898/healthz to confirm."

Break it on purpose

Helm's power is that one bad override ships to every environment. Probe that now.

1. Upgrade with a mismatched nodePort:

   helm upgrade podinfo ./podinfo-chart -n demo --set service.nodePort=31080 --wait
   

2. Predict: what happens when you curl http://localhost:9898/healthz now? Write the answer in one sentence.
3. Run the curl. Compare.
4. Inspect what changed: kubectl -n demo get svc podinfo-chart -o yaml | grep nodePort. The Service is happily listening on 31080; the kind cluster config only forwards host port 9898 to node port 30080, so traffic to localhost:9898 goes nowhere and the failure is silent until you trace it.
5. Revert: helm upgrade podinfo ./podinfo-chart -n demo --set service.nodePort=30080 --wait.

The failure mode you're internalising: a value override can break the deployment without breaking the chart. Charts lint fine. Templates render fine. Pods run fine. Traffic still doesn't land. Your skill in the next lesson will need to know about this class of failure.

Acceptance test

helm upgrade podinfo ./podinfo-chart -n demo \
  --set replicaCount=3 \
  --set image.tag=6.7.0 \
  --wait

kubectl -n demo get pods -l app.kubernetes.io/name=podinfo-chart

Expect 3 pods, all Running. Confirm the image tag:

kubectl -n demo get deployment podinfo-chart -o jsonpath='{.spec.template.spec.containers[0].image}'

That should print ghcr.io/stefanprodan/podinfo:6.7.0. If you see something else, the upgrade didn't take.

Troubleshooting

• Error: UPGRADE FAILED: another operation ... is in progress — a previous helm command crashed mid-apply. Ask Claude to run helm rollback podinfo 0 -n demo or helm uninstall podinfo -n demo and retry.
• Pods Running but curl fails — helm get manifest podinfo -n demo shows the rendered YAML. Check nodePort and targetPort. If nodePort is blank, the template isn't picking up .Values.service.nodePort — re-inspect service.yaml.

What to keep for the next lesson

Keep the chart directory, the Claude transcript, and your Break it on purpose notes on the nodePort mismatch. In the next lesson you'll codify .claude/skills/helm-chart-scaffold/ and explicitly teach it that overrides can silently break a deploy even when every command succeeds.