How to build Helm chart from existing Kubernetes manifest

Question

i'm a newbie to k8s. I have a homework and this is my situation:
There is an app with microservice-oriented, build with amount ten containers. It had a docker-compose file for easily set up. Now my mission is deploy it into Kubernetes. My idea: convert docker-compose file to k8s manifest with kompose, and create helm chart for each services.
My question is: I have to modify each chart one-by-one, isn't it? Is there any way to generate values.yaml base on existing k8s manifest? example, from this:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose convert
    kompose.version: 1.22.0 (955b78124)
  creationTimestamp: null
  labels:
    io.kompose.service: bookstore-account-service
  name: bookstore-account-service
...

to this, automatically:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: {{ .Values.cmd }}
    kompose.version: {{ .Values.ver }}
  creationTimestamp: null
  labels:
    io.kompose.service: {{ .Values.name }}
  name: {{ .Values.name }}
...

# values.yaml
cmd: kompose convert
ver: 1.22.0 (955b78124)
name: bookstore-account-service

p/s: sorry for my bad English, it's not my first language :D

Take a look into [helmify](https://github.com/arttor/helmify) CLI. It generates a Helm chart from k8s yaml. I've explained how to use it in [this answer](https://stackoverflow.com/a/69150410/6065134) — Artem, Sep 12 '21 at 13:01

score 3 · Accepted Answer · answered Aug 13 '21 at 11:03

The Helm values.yaml file is the main point where you can configure the chart at deployment time. On the one hand, you can't configure anything that's not referenced in .Values; on the other hand, you usually don't want every individual line of the YAML file to be configurable.

If I was going to approach this, I'd start by helm create a new chart. I'd then switch to the templates directory, move aside most of the boilerplate there (but leave the generated _helpers.tpl file), and run kompose convert. This will generate a set of YAML files, though with no Helm templating.

From here I'd edit the files to make them match typical Helm usage. Look at the original files from helm create (or in the Helm source) for examples. I would expect the edited deployment.yaml to look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  {{-/* delete the Kompose annotations: and empty creationTimestamp: */}}
  labels:
    {{-/* get a standard set of labels from _helpers.tpl }}
    {{- include "bookstore.labels" . | nindent 4 }}
  {{-/* get a standard name from _helpers.tpl }}
  name: {{ include "bookstore.fullname" . }}

What should go in the values.yaml file, then? These are things you'd need to configure at deploy time. If you need to override the container command: or args:, these would usually be fixed, but if you needed to supply some sort of credentials or host name, those could vary per-deployment. (If you helm installed the chart twice, what would be different between the installs?) The helm create template makes resource limits configurable, since these can vary heavily based on the actual workload:

# deployment.yaml (from helm/create.go linked above)
resources:
  {{- toYaml .Values.resources | nindent 12 }}

# values.yaml (also from helm/create.go)
resources: {}

You could deploy this with a specific set of values here:

# values.dev.yaml
resources:
  requests:
    memory: 256Mi
  limits:
    memory: 1Gi

# values.prod.yaml
resources:
  requests:
    memory: 2Gi
  limits:
    memory: 4Gi

helm install bookstore . -f values.dev.yaml

If you had preserved, for example, the "what version of Kompose generated this file" annotation, there'd be no reason to change that between environments, and so you could just leave that as a fixed string.

I just wonder how devops engineer do this job, in case they have to work with hundreds of container, for example. Do they have to edit `values.yaml` manually? — manhtr76, Aug 13 '21 at 14:45
In my day job, each microservice has its own Helm chart and its checked-in set of `values.some-environment.yaml` files; the deployment system knows how to handle this. Most of the details are in the template files and only the things that are different between dev/staging/prod are in the `values.*.yaml` files. But absolutely hand-edit these YAML files and check them in to source control. — David Maze, Aug 13 '21 at 17:03

score 0 · Answer 2 · answered Aug 13 '21 at 04:36

the thing is, how do you decide which one will be customizable (go into values file). if you do have that list, then it's easier. you can use a yaml parser, replace teh value for those fields you want to customize and place those values to values.yaml file.

score 0 · Answer 3 · answered Aug 13 '21 at 04:58

0

You can run the docker-compose file to deploy the services and from the K8s YAML manifest you can write down the helm chart with the fields you want.

In values.yaml you can add necessary based on your requirement which one you want to keep configurable.

You can also run the command for the basic helm template and edit it as per requirement

helm create mychartname

Read more at : https://opensource.com/article/20/5/helm-charts

answered Aug 13 '21 at 04:58

Harsh Manvar

27,020
6
48
102

Thanks for you answer, so i have to config `values.yaml` manually, right? I just wonder how devops engineer do this job, in case they have to work with hundreds of container, for example. – manhtr76 Aug 13 '21 at 07:41
above command shared in create template of chart and you can edit as per need . – Harsh Manvar Aug 13 '21 at 07:54

score 0 · Answer 4 · answered Aug 09 '22 at 01:38

I was trying to find one open-source project to do this, but none of them fits my requirement. I decided to write one myself, so https://github.com/yeahdongcn/kustohelmize was created for this.

It could be simply integrated with any of Golang's projects, especially for the projects generated by Operator SDK. Say your project has a Makefile, insert the following lines:

.PHONY: helm
helm: kustohelmize
    $(KUSTOHELMIZE) create --from=<<path-to-your-all-in-one-yaml-file>> <<path-to-your-target-dir>>
    helm lint <<path-to-your-target-dir>>

KUBERNETES-SPLIT-YAML ?= $(LOCALBIN)/kubernetes-split-yaml
KUSTOHELMIZE ?= $(LOCALBIN)/kustohelmize

.PHONY: kubernetes-split-yaml
kubernetes-split-yaml: $(KUBERNETES-SPLIT-YAML) ## Download kubernetes-split-yaml locally if necessary.
$(KUBERNETES-SPLIT-YAML): $(LOCALBIN)
    GOBIN=$(LOCALBIN) go install github.com/yeahdongcn/kubernetes-split-yaml@v0.4.0

.PHONY: kustohelmize
kustohelmize: $(KUSTOHELMIZE) ## Download kustohelmize locally if necessary.
$(KUSTOHELMIZE): $(LOCALBIN) kubernetes-split-yaml
    GOBIN=$(LOCALBIN) go install github.com/yeahdongcn/kustohelmize@latest

Try make helm and a helm chart is created with the default configurations. One can update the <>.config with your own config, please ref to https://github.com/yeahdongcn/kustohelmize/blob/main/examples/README.md

How to build Helm chart from existing Kubernetes manifest

4 Answers4

Linked