Generate Production-Ready Helm Charts

Provides expert guidance for creating production-ready Helm charts following best practices for templating, values management, resource definitions, and maintainability - covering chart structure, Go templating with validation, and multi-environment deployment patterns.

Use this skill when scaffolding a new Helm chart, structuring values.yaml for a Kubernetes application, writing reusable helper templates, making resources conditional, or setting up multi-environment value files for dev/staging/prod deployments.

Standard chart structure: Chart.yaml, values.yaml, a templates/ directory (deployment, service, ingress, configmap, secret, serviceaccount, _helpers.tpl, NOTES.txt), a charts/ subdirectory for dependencies, and a crds/ directory. Chart.yaml follows apiVersion: v2 with semantic version and appVersion, maintainers, keywords, and conditional dependencies (e.g. a postgresql subchart gated by condition: postgresql.enabled).

values.yaml is organized into clear sections: image repository/tag/pullPolicy, service type/port, ingress (disabled by default, with host/path/TLS config), resource limits/requests, a security context (runAsNonRoot, runAsUser, fsGroup), autoscaling (min/max replicas, target CPU utilization), and node selection (nodeSelector/tolerations/affinity).

Helper templates in _helpers.tpl define reusable functions: myapp.name (truncated, trimmed chart name with override support), myapp.fullname (handles release-name collision to avoid double-naming), myapp.labels (standard Kubernetes labels including helm.sh/chart and app.kubernetes.io/managed-by), and myapp.selectorLabels (the stable subset used for pod selection).

A deployment template example demonstrates key patterns: conditionally omitting replicas when autoscaling is enabled, a checksum/config pod annotation computed via sha256sum on the configmap template so pods restart when config changes, liveness/readiness probes on /health//ready, and with-gated blocks for optional fields like imagePullSecrets, env, nodeSelector, affinity, and tolerations.

Conditional resource management wraps entire resources (Ingress, ServiceAccount) in {{- if .Values.x.enabled -}} blocks so they're only rendered when explicitly turned on.

Validation and testing: helm lint for syntax validation, helm test hooks for post-deployment verification, --dry-run for template validation, testing against multiple values files per environment, and kubectl --dry-run=client to validate the generated YAML.

Advanced templating techniques: the required function to enforce mandatory values ({{ required "image.repository is required" .Values.image.repository }}), default for fallback values, include for reusing complex templates, range for generating resources dynamically, if/else/end conditionals, and with to change template context scope.

Multi-environment support uses separate values files (values-dev.yaml, values-staging.yaml, values-prod.yaml) deployed via helm install myapp ./chart -f values-prod.yaml.

Built entirely on Helm's own templating engine (Go templates), Kubernetes resource types (Deployment, Service, Ingress, ConfigMap, Secret, ServiceAccount), and the helm lint/helm test/kubectl --dry-run toolchain, with subchart dependencies pulled from chart repositories like Bitnami.

Kubernetes platform engineers creating or maintaining Helm charts who need concrete patterns for reusable templates, conditional resources, security defaults, and multi-environment values rather than assembling Helm syntax from scratch.