I'm new to Kubernetes and understand the basics of writing YAML for Deployments, Services, Ingresses, and other resources. I'm now trying to understand how Helm fits into that workflow. If I already have deployment.yaml, service.yaml, and ingress.yaml files, do I need to move them into a chart's templates/ directory and replace hardcoded values with expressions such as {{ .Values.image.tag }}? Or can existing manifests be used without modification? I'd also appreciate a simple example and an explanation of how teams usually structure and manage Helm charts across development, staging, and production.
3 Answers
The usual gradual approach is to begin with your working manifests, move them into templates/, and then parameterize only the values that actually vary. For example, change a hardcoded Deployment from replicas: 2 and image: nginx:1.25 to replicas: {{ .Values.replicaCount }} and image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}". Then define replicaCount and image settings in values.yaml. The Kubernetes resource structure remains essentially the same; Helm just fills in the configurable parts. Start with a Deployment and Service, validate the rendered output, and add the remaining resources afterward.
Helm is not the only valid option. If your YAML is already easy to maintain and you mainly need small overlays, Kustomize may be simpler and introduce less templating syntax. Helm is especially useful when you want versioned, reusable packages, release history, rollbacks, dependencies, and a consistent interface of configurable values. The right choice depends on whether you need packaging and templating or mainly environment-specific patches.
Running helm create can show you the conventional directory layout and sample templates, although the generated boilerplate may be more than you need. A production-oriented chart commonly includes Chart.yaml, values.yaml, templates/, and sometimes helper templates such as _helpers.tpl for shared names and labels. Validate changes with commands such as helm template or helm lint, and inspect the rendered manifests before deploying.
You do not have to template every field. Keeping stable configuration directly in the manifest is often clearer. Template settings only when reuse or environment-specific changes justify the extra complexity.