Helm Interview Preparation

Helm is a package manager for Kubernetes. Without Helm, deploying an application requires managing many YAML files (Deployment, Service, ConfigMap, Secret, Ingress, etc.) individually. Helm bundles them into a chart with templating, versioning, and dependency management. Benefits: one-command install/upgrade/rollback, reusable across environments, version control, dependency management.

Chart: A package containing templates, values, and metadata (like a recipe). Release: A running instance of a chart in a cluster (like a dish cooked from the recipe). You can install the same chart multiple times with different names/values. Repository: A server hosting chart archives (.tgz + index.yaml). Examples: Bitnami, Artifact Hub, OCI registries.

Chart.yaml (metadata: name, version, dependencies), values.yaml (default config), templates/ (Go-templated YAML manifests), templates/_helpers.tpl (named template definitions), templates/NOTES.txt (post-install message), charts/ (subchart dependencies), .helmignore (files to exclude from packaging).

helm install <name> <chart> -n <namespace> to install. helm uninstall <name> -n <namespace> to remove all resources and the release record. Use --create-namespace if the namespace doesn't exist. Use helm upgrade --install for idempotent operations (installs if new, upgrades if existing).

Three ways: 1) -f values-prod.yaml — a YAML file with overrides. 2) --set key=value — individual values on CLI. 3) --set-file key=filepath — value from a file. Priority: --set > last -f file > first -f file > chart defaults. Use helm show values <chart> to see all available options.

helm upgrade <name> <chart> -f values.yaml — applies new version/values. helm rollback <name> <revision> — reverts to a previous revision. helm history <name> — shows all revisions with status. Each upgrade increments the revision number. Rollback creates a new revision (it's a new operation, not undo).

Helm 2 used Tiller (a server-side component in the cluster) — security risk, required RBAC setup. Helm 3 removed Tiller entirely: client-only, uses kubeconfig for auth. Helm 3 also: stores releases as Secrets (not ConfigMaps), uses 3-way merge (detects manual edits), release names are namespace-scoped, validates against JSON schema.

.Values — values from values.yaml and overrides. .Chart — Chart.yaml metadata (name, version, appVersion). .Release — release info (name, namespace, revision, isUpgrade, isInstall). .Template — current template file info. .Capabilities — cluster info (K8s version, API versions). .Files — access non-template files in the chart.

helm template — renders locally, no cluster needed. Fast but can't validate apiVersions, CRDs, or quotas. helm install --dry-run — renders and validates against the cluster API without creating resources. Slower but catches more issues. Use template for quick iterations, dry-run for final validation.

As Kubernetes Secrets in the release's namespace. Each revision creates a new Secret: sh.helm.release.v1.<name>.v<revision>. Contains the chart, values, and rendered manifests (base64-encoded, gzipped). Helm reads these to know the current state for upgrades and rollbacks.

Uses Go text/template. Actions in {{ }}. Variables: {{ .Values.key }}. Pipelines: {{ .Values.name | upper | quote }}. Conditionals: {{ if .Values.enabled }}...{{ end }}. Loops: {{ range .Values.list }}...{{ end }}. Whitespace control: {{- trims left, -}} trims right. Named templates: {{ define "name" }}...{{ end }}, used via {{ include "name" . }}.

Both invoke named templates. template inserts output directly (can't pipe). include captures output as a string (can pipe through functions like nindent, quote). Always use include — it's more flexible. Example: {{ include "myapp.labels" . | nindent 4 }} wouldn't work with template.

Declared in Chart.yaml under dependencies:. Each dependency has name, version, repository. helm dependency update downloads them as .tgz into charts/ and generates Chart.lock. Subchart values are nested under the subchart name in parent's values.yaml. condition toggles individual deps, tags toggle groups. global: values are shared with all subcharts.

Resources with helm.sh/hook annotation that run at lifecycle events. Common: pre-install/pre-upgrade for DB migrations, post-install for notifications, test for validation. Hook-weight controls order, hook-delete-policy manages cleanup. If a hook fails, the operation fails. Use --atomic for auto-rollback on hook failure.

Helm 3 compares three states during upgrade: 1) Old chart manifests (from last release), 2) Live cluster state, 3) New chart manifests. This detects manual changes (kubectl edit). If someone manually changed replicas from 3→5 and chart says 3→3, Helm preserves the manual change. If chart says 3→4, Helm applies 4. Prevents accidental overwrites of manual hotfixes.

A chart with no templates of its own — only dependencies. Used to deploy an entire stack with one command. Example: umbrella chart with subcharts for API, frontend, PostgreSQL, Redis. One helm install deploys everything. Umbrella's values.yaml configures all subcharts. Common in microservices architectures. Alternative: Helmfile.

{{ required "error message" .Values.key }} — fails with a clear error if the value is empty/missing. Use for critical values that must be provided: database URLs, API keys, image tags. Better to fail at helm install than deploy a broken release. Contrast with default which silently falls back.

Options ranked by security: 1) External Secrets Operator — syncs from Vault/AWS Secrets Manager into K8s Secrets. 2) Sealed Secrets — encrypt in Git, decrypt in cluster. 3) Helm Secrets plugin + SOPS — encrypts values files. 4) CI/CD secrets — inject via --set from pipeline. Never store plaintext secrets in values files committed to Git.

{{ lookup "v1" "Secret" .Release.Namespace "myapp-secret" }} — queries the cluster for existing resources during template rendering. Use case: check if a Secret exists to reuse a password instead of regenerating. Only works with helm install/upgrade, not helm template (no cluster access). Returns empty dict if not found.

From lowest to highest priority: 1) Subchart's values.yaml. 2) Parent chart's values.yaml. 3) First -f file. 4) Last -f file. 5) --set / --set-string. Higher priority wins. Parent values override subchart defaults. --set overrides everything. global: values are merged into all subcharts regardless of nesting.

ArgoCD Application resource points to a Git repo containing a Helm chart + values. ArgoCD periodically renders helm template and compares with live cluster state. Diffs trigger sync (deploy). CI pipeline updates image.tag in values file → Git commit → ArgoCD detects → deploys. selfHeal: true reverts manual cluster changes. prune: true removes resources deleted from chart.

Create a library chart with shared templates (deployment, service, ingress patterns). Each service's chart depends on it and uses include. Or a base application chart that all services install as subcharts, only overriding values. Publish to internal OCI registry. Version independently. Alternative: a single generic chart with per-service values files.

1) helm get values myapp -n prod — see actual values. 2) Compare with expected values file. 3) Check for case-sensitivity mismatches. 4) Check if --reuse-values is overriding new defaults. 5) For subcharts: ensure values are nested under subchart name. 6) helm get manifest myapp -n prod | grep <expected-value> — verify rendered output. 7) Compare with helm template output.

1) helm status myapp -n prod — check state (pending-upgrade, failed). 2) helm history — find last deployed revision. 3) helm rollback myapp <rev> — restore. 4) If rollback blocked: kubectl get secrets -l owner=helm,name=myapp,status=pending-upgrade → delete the stuck secret. 5) Prevention: always use --atomic --wait --timeout.

Helm: Full templating, packaging, versioning, dependencies, lifecycle management (install/upgrade/rollback). Best for distributing reusable charts, complex apps, third-party software. Kustomize: Overlay-based patching, no templating, built into kubectl. Best for simple environment-specific patches on raw YAML. They can work together: Helm renders templates, Kustomize patches the output.

Two approaches: 1) Two releases: myapp-blue and myapp-green. Deploy new version to green, test, switch the Service/Ingress selector to point to green. 2) Argo Rollouts: Replace Deployment with Rollout resource in chart, ArgoCD manages traffic switching. 3) Service mesh: Istio VirtualService routes traffic, controlled via Helm values.

Pipeline: 1) helm lint — syntax check. 2) helm template | kubeconform — schema validation. 3) helm install --dry-run — cluster-side validation. 4) Install to ephemeral namespace (kind cluster in CI). 5) helm test — run test hooks. 6) ct lint-and-install (chart-testing tool) — full test suite. 7) helm diff in PR review.

Pre-install/pre-upgrade hooks run before resource creation. If the hook fails, install fails — app doesn't deploy (good, prevents broken state). Check: kubectl logs job/myapp-migrate. Common: DB unreachable, wrong credentials, migration syntax error. Fix the migration, clean up the failed Job, redeploy. If using --atomic, the failed release was already rolled back.

Place CRDs in the crds/ directory. Helm installs CRDs before templates on first install. Limitation: Helm never upgrades or deletes CRDs (to prevent data loss). For CRD lifecycle management: use a separate CRD chart installed first, or the operator pattern. Check CRD availability in templates with .Capabilities.APIVersions.Has "mygroup/v1".

Umbrella chart: Single release, all subcharts deploy/rollback together. Simple but tightly coupled. Helmfile: Multiple independent releases with their own lifecycle. Can selectively upgrade one service. Supports diff, environments, selectors. Better for large teams where services have different release cadences. Trade-off: umbrella is simpler; Helmfile is more flexible.

Multiple layers: 1) Chart template: Use required function on resources values. 2) CI: helm template | kubeconform with a policy requiring resources. 3) Cluster: LimitRange (defaults) and ResourceQuota (enforcement). 4) OPA/Gatekeeper/Kyverno: Admission controllers that reject Pods without resource limits. Defense in depth.

Use the helm-2to3 plugin: 1) helm3 2to3 move config — migrate repos and plugins. 2) helm3 2to3 convert <release> — converts release data from ConfigMaps to Secrets. 3) Verify with helm3 list. 4) helm3 2to3 cleanup — removes Tiller. Do one release at a time. Test in staging first. Have rollback plan.

Use condition in templates: {{ if .Values.features.newUI }}...{{ end }}. Values file: features.newUI: false (off by default). Enable per environment: --set features.newUI=true. For entire resources: wrap the whole template in an if block. For sub-resources: conditional blocks within templates. Works for optional sidecars, init containers, config, etc.

One chart, multiple values files: values-aws.yaml (ALB ingress, EBS storage class, ECR registry), values-azure.yaml (App Gateway ingress, managed-premium storage, ACR), values-gcp.yaml (GCE ingress, pd-standard storage, GCR). Chart templates are cloud-agnostic. Deploy with -f values-<cloud>.yaml. Common values in base values.yaml.

Helm push-based: Simple, immediate feedback, easy debugging. Con: no drift detection, no self-healing, imperative. ArgoCD GitOps: Git is truth, auto-sync, drift detection, self-healing, audit trail. Con: more complex setup, image tag updates require Git commits, learning curve. Recommendation: GitOps for production, Helm CLI for dev/testing.

Essential plugins: 1) helm-diff — helm diff upgrade previews changes before applying (like terraform plan). 2) helm-secrets — encrypt values files with SOPS/age for safe Git storage. 3) helm-unittest — unit test templates with assertions. Install: helm plugin install https://github.com/databus23/helm-diff. List installed: helm plugin list.

Helmfile is a declarative tool for managing multiple independent Helm releases. Use over umbrella charts when: services have different release cadences, teams own different services, you need selective deploys (helmfile -l name=api apply). Key advantages: supports diff, environments (helmfile -e prod apply), templated values, and dependencies between releases. Umbrella charts are simpler but tightly couple all services to one release lifecycle.

FluxCD uses native CRDs: HelmRepository + HelmRelease. It actually runs helm install/upgrade in-cluster. Helm release secrets are created naturally. ArgoCD runs helm template → kubectl apply — no Helm release secrets. Trade-off: Flux has full Helm lifecycle (rollback works); ArgoCD has better UI and multi-cluster support. Both are valid GitOps approaches.

Use helm-unittest plugin. Write test suites in YAML that assert template output for given values: suite: test deployment, set: replicaCount: 3, asserts: - equal: {path: spec.replicas, value: 3}. Also useful: ct lint-and-install (chart-testing) for integration tests in CI with ephemeral Kind clusters. Run: helm unittest .

Traditional: HTTP server with index.yaml + .tgz files. Requires helm repo add + helm repo update. OCI (GA in Helm 3.8+): Charts stored alongside container images in registries (ACR, ECR, GCR, Harbor). Push: helm push mychart.tgz oci://registry/charts. Pull: helm install myapp oci://registry/charts/mychart --version 1.0.0. OCI is the future — no index.yaml maintenance, leverage existing container registry infrastructure and auth.