How to build Helm chart from existing Kubernetes manifest

8/13/2021

i'm a newbie to k8s. I have a homework and this is my situation:<br> 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.<br> 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: <br>

# 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

-- manhtr76
docker
kubernetes
kubernetes-helm

3 Answers

8/13/2021

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.

-- Tuan Anh Tran
Source: StackOverflow

8/13/2021

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

-- Harsh Manvar
Source: StackOverflow

8/13/2021

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.

-- David Maze
Source: StackOverflow