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
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.
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 mychartnameRead more at : https://opensource.com/article/20/5/helm-charts
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: 4Gihelm install bookstore . -f values.dev.yamlIf 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.