<p>I have an application with many services that are deployed in kubernetes. These services are represented by yaml files like <code>configmap.yaml</code> and <code>deployment.yaml</code>.</p>
<p>How can I convert these files to helm charts et deploy the application using:</p>
<pre><code>helm install 
 
</code></pre>

karlos
<p>If you run <a href="https://docs.helm.sh/docs/helm/helm_create/" rel="nofollow noreferrer"><code>helm create</code></a> to create a skeleton chart, that will create a basic file structure for you.  Within that chart, the <a href="https://docs.helm.sh/docs/topics/charts/#the-chart-file-structure" rel="nofollow noreferrer"><code>templates</code> directory</a> contains a set of <a href="https://docs.helm.sh/docs/topics/charts/#template-files" rel="nofollow noreferrer">templated YAML files</a>.</p>
<p>If you're just getting started, it's enough to move aside the YAML files that <code>helm create</code> generates and copy your existing YAML into the <code>templates</code> directory.  <code>helm install</code> will install those exact files, similar to what <code>kubectl apply</code> would do, though note that the specific named resources need to not exist yet in the cluster.</p>
<pre class="lang-bash prettyprint-override"><code>helm create my-chart
cd my-chart
mkdir original-templates &amp;&amp; mv templates/*.yml original-templates
cp ~/application/k8s/*.yml templates
# helm template .
helm install --generate-name .
</code></pre>
<p>If you do look at the <code>helm create</code> template files, you'll notice that there are some conventions on how it chooses things like resource names, calling support functions in the <code>_helpers.tpl</code> file that allow installing the chart multiple times in parallel.  A good next step would be to update the <code>metadata:</code> blocks in the YAML files to follow these conventions.</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include &quot;mychart.fullname&quot; . }}
  labels:
    {{- include &quot;mychart.labels&quot; . | nindent 4 }}
spec:
  ...
</code></pre>
<p>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 <code>values.yaml</code> 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.)</p>
