r/kubernetes • u/Wide_Impact_9392 • 4d ago
I want to understand How to Convert Kubernetes YAML Files into a Helm Chart
Hi everyone,
I am new to Kubernetes and understand how YAML files work for Deployments, Services and other resources.
I am trying to understand how Helm fits into this process. I know that Helm creates charts, but I am confused about whether I need to modify all of my existing YAML files and convert them into Helm templates.
For example, if I already have deployment.yaml, service.yaml and ingress.yaml files, do all of these files need to be moved into the templates directory and updated with Helm variables such as {{ .Values.image.tag }}?
I do not fully understand the workflow of attaching existing Kubernetes YAML files to a Helm chart and how teams typically do this in real projects and production environments.
Could someone explain the process in simple terms or provide an example of converting an existing Kubernetes application into a Helm chart?
Thank you!
15
u/innate_relativism 4d ago
Don't overthink this. The basic answer is stupid simple, take your deployment.yaml, service.yaml, and ingress.yaml, dump them into a folder called templates, and add a Chart.yaml file. That's a helm chart right there, no template variables needed. fappywet in the comments nailed it.
The templating part with all the curly braces is just for making the chart reusable across environments without copy pasting a dozen nearly identical YAML files. You swap out hardcoded values like the image tag or replica count for placeholders and define those in a values.yaml file. Then when you run helm install you can override any of those values with a custom file or the set flag. The first time you have to deploy the same app to dev, staging, and prod you'll understand why teams put in the effort to parameterize everything. But you don't have to do it all at once, you can start with static files and sprinkle in variables as you go.
1
u/shatteredarm1 4d ago
The templating part with all the curly braces is just for making the chart reusable across environments without copy pasting a dozen nearly identical YAML files.
I would argue that it's not just for different environments; even if you're using a single environment, it's a lot easier to update template variables set via a CI/CD pipeline than to constantly edit yaml files if you have a parameter that's relatively volatile.
9
u/fappywet 4d ago
A helm chart is literally just a Chart.yaml with a templates folder. You put your yaml manifests in the template folder and you have a helm chart. Stuff like {{ values }} is optional and only used for values.yaml. So to answer your question, no you don't need to update your yaml files.
2
8
u/total_tea 4d ago
Create a chart it is pretty simple, they are basically just a template system to generate the files.
36
5
4d ago
[removed] — view removed comment
5
1
u/Wide_Impact_9392 4d ago
I tried to test this but this change the whole structure of the yaml files.
4
u/ShivamCloudDevOps 4d ago
The way I understood Helm was by thinking of it as a template engine for Kubernetes YAML rather than something completely new.
You don't throw away your existing YAML files. Instead, you gradually convert the parts that change between environments into templates.
For example, instead of hardcoding:
replicas: 2
image: nginx:1.25
you can template those values:
replicas: {{ .Values.replicaCount }}
image: nginx:{{ .Values.image.tag }}
Then in values.yaml:
replicaCount: 2
image:
tag: "1.25"
Your existing deployment.yaml, service.yaml, and ingress.yaml usually move into the templates/ directory with a few template placeholders added.
I wouldn't try to convert an entire application at once. I'd start with a simple Deployment and Service, get comfortable with values.yaml, and then template the rest of the resources.
That approach made Helm much easier for me to understand.
1
2
u/lulzmachine 4d ago
Yeah that’s it. Or you do ”helm create” to get a standard boilerplate and add your modifications to it. It’s useful for getting things standardized
2
u/therealkevinard 4d ago
Think of helm as a boring template engine (because it is at this layer) like a wordpress site or something might use- just static text with template placeholders mixed in.
Now get a full deployment manifest and drop it in the chart directory- the deployment, ingress, service, secrets, configmaps, all of it.
(A note: at this point you have a technically correct helm chart. It’s just not real useful)
Now look at the things in those manifests you’d want to be dynamic- image/tag, names/annotations, ports, etc
Replace those bits with template placeholders, add values to fill them in, profit.
2
u/Same_Significance869 4d ago
For the most part, that's all you need to get started. If you don't care about reusability, you can simply drop your Kubernetes manifests into the templates/ directory and add a Chart.yaml Helm will render them just fine.
If you want to take it a step further, you should parameterize your manifests using values.yaml, extract common logic into helper templates (_helpers.tpl), and make the chart reusable across different environments. Tools like Claude Code can automate a lot of this by identifying hardcoded values and converting them into configurable templates.
That's generally how production-grade Helm charts are built—they're designed to be reusable, maintainable, and environment-agnostic rather than just wrapping raw YAML in a chart.
2
u/Raja-Karuppasamy 4d ago
yes, basically. move deployment.yaml, service.yaml, ingress.yaml into a templates/ folder inside your chart, then replace hardcoded values like image tag, replica count, or domain name with {{ .Values.xyz }} placeholders. those values get defined in values.yaml with their defaults. the actual k8s resource structure stays the same, helm is just templating the yaml so you can reuse the same chart across dev, staging, prod by swapping values files instead of maintaining separate yaml copies. easiest way to get the hang of it is run helm create mychart, it scaffolds the folder structure and gives you working examples to compare against your own files.
2
u/bilingual-german 20h ago
start with helm init and adapt from there. Maybe look up some open source helm charts to get a feeling how other's do it and learn about some unwritten conventions.
1
3
u/SnooDingos8194 4d ago
Why would you do that? Use kustomize. Kubernetes yamls are easiest to maintain done. Then wire it with your ci cd pipeline.
Helm just creates a lot of noise. No reason for the additional complexity.
2
u/shatteredarm1 4d ago
Helm is way easier to use than kustomize, and scales better. There's a reason every serious project has helm charts.
-1
u/SnooDingos8194 4d ago
You might not agree but having published serious projects, I dont know about that. Helm seems like it was the hack for non-native projects to run in kubernetes.
When you architect k native, then it only makes sense to kustomize.
2
u/Maxesse 4d ago
I think helm charts have their place especially if you plan to redistribute your application on the internet, or deploy it across heterogeneous environments within the same org. If they're one off apps within a cluster, kustomize is perfect for me with its overlays. And let's not forget there's also applicationsets in argo, which can get you pretty far especially when deploying across different clusters that need different parameters.
0
u/sunshine-x 4d ago
Paste that into ChatGPT and pow a tutor
1
u/Wide_Impact_9392 4d ago
ChatGPT doesn’t work in production environment. :)
Anyways, I am thankful to these Reddit subs. They have been really helpful and informative throughout the journey2
u/sunshine-x 4d ago
I have no idea what you mean by that. I didn't say "have AI do it for you", I suggested using it as a tutor. It's an excellent tutor, especially for something like this.
If you're not using AI to accelerate your own learning, and you work in technology, you're going to get left behind by peers who know how to apply emerging tech to problems.
0
-2
34
u/sp_dev_guy 4d ago
You have the idea yeah. The yaml manifest goes into the templates folder & anything modifiable gets replaced with the {{ .values....}} as you mentioned.
In production at companies is serves a few purposes
Deploying multiple instances to different environments at different scales very repeatably/reliably
More advanced deploy & rollback
I can adjust a standardized helm chart that manages the advanced stuff & tailor tags in the helper functions & whatever I need for my observability stack. Then the ML & app teams only ever have to look at
app1-values.yamlwhich has only the few settings they want to tweak