Search code examples
kuberneteskubernetes-helm

How to convert deployment, configmap and service yaml files to helm package


I have an application with many services that are deployed in kubernetes. These services are represented by yaml files like configmap.yaml and deployment.yaml.

How can I convert these files to helm charts et deploy the application using:

helm install 
 

Solution

  • If you run helm create to create a skeleton chart, that will create a basic file structure for you. Within that chart, the templates directory contains a set of templated YAML files.

    If you're just getting started, it's enough to move aside the YAML files that helm create generates and copy your existing YAML into the templates directory. helm install will install those exact files, similar to what kubectl apply would do, though note that the specific named resources need to not exist yet in the cluster.

    helm create my-chart
    cd my-chart
    mkdir original-templates && mv templates/*.yml original-templates
    cp ~/application/k8s/*.yml templates
    # helm template .
    helm install --generate-name .
    

    If you do look at the helm create template files, you'll notice that there are some conventions on how it chooses things like resource names, calling support functions in the _helpers.tpl file that allow installing the chart multiple times in parallel. A good next step would be to update the metadata: blocks in the YAML files to follow these conventions.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: {{ include "mychart.fullname" . }}
      labels:
        {{- include "mychart.labels" . | nindent 4 }}
    spec:
      ...
    

    From there I'd suggest figuring out what specific things you need to have customized at install time, and replace those with template expressions and specific values.yaml settings. I would not try to inject large parts of the Kubernetes configuration through values, though the boundary can be a little blurry here. (It makes sense to me to specify a Service type, node port, and annotations through values, but not necessarily a long list of Pod environment variables.)