<p>I've built an application through Docker with a docker-compose.yml file and I'm now trying to convert it into deployment file for K8S.</p>
<p>I tried to use <code>kompose convert</code> command but it seems to work weirdly.</p>
<p>Here is my docker-compose.yml:</p>
<pre><code>version: &quot;3&quot;
services:

  worker:
    build:
      dockerfile: ./worker/Dockerfile
    container_name: container_worker
    environment:
      - PYTHONUNBUFFERED=1
    volumes:
      - ./api:/app/
      - ./worker:/app2/

  api:
    build:
      dockerfile: ./api/Dockerfile
    container_name: container_api
    volumes:
      - ./api:/app/
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - &quot;8050:8050&quot;
    depends_on:
      - worker
</code></pre>
<p>Here is the output of the <code>kompose convert</code> command:</p>
<pre><code>[root@user-cgb4-01-01 vm-tracer]# kompose convert
WARN Volume mount on the host &quot;/home/david/vm-tracer/api&quot; isn't supported - ignoring path on the host 
WARN Volume mount on the host &quot;/var/run/docker.sock&quot; isn't supported - ignoring path on the host 
WARN Volume mount on the host &quot;/home/david/vm-tracer/api&quot; isn't supported - ignoring path on the host 
WARN Volume mount on the host &quot;/home/david/vm-tracer/worker&quot; isn't supported - ignoring path on the host 
INFO Kubernetes file &quot;api-service.yaml&quot; created   
INFO Kubernetes file &quot;api-deployment.yaml&quot; created 
INFO Kubernetes file &quot;api-claim0-persistentvolumeclaim.yaml&quot; created 
INFO Kubernetes file &quot;api-claim1-persistentvolumeclaim.yaml&quot; created 
INFO Kubernetes file &quot;worker-deployment.yaml&quot; created 
INFO Kubernetes file &quot;worker-claim0-persistentvolumeclaim.yaml&quot; created 
INFO Kubernetes file &quot;worker-claim1-persistentvolumeclaim.yaml&quot; created 
</code></pre>
<p>And it created me 7 yaml files. But I was expected to have only one deployment file. Also, I don't understand these warning that I get. Is there a problem with my volumes?</p>
<p>Maybe it will be easier to convert the docker-compose to deployment.yml manually?</p>
<p>Thank you,</p>

Vida Eninkio
<p>I'd recommend using Kompose as a starting point or inspiration more than an end-to-end solution.  It does have some real limitations and it's hard to correct those without understanding Kubernetes's deployment model.</p>
<p>I would clean up your <code>docker-compose.yml</code> file before you start.  You have <code>volumes:</code> that inject your source code into the containers, presumably hiding the application code in the image.  This setup mostly doesn't work in Kubernetes (the cluster cannot reach back to your local system) and you need to delete these <code>volumes:</code> mounts.  Doing that would get rid of both the Kompose warnings about unsupported host-path mounts and the PersistentVolumeClaim objects.</p>
<p>You also do not normally need to specify <code>container_name:</code> or several other networking-related options.  Kubernetes does not support multiple networks and so if you have any <code>networks:</code> settings they will be ignored, but most practical Compose files don't need them either.  The obsolete <code>links:</code> and <code>expose:</code> options, if you have them, can also usually be safely deleted with no consequences.</p>
<pre class="lang-yaml prettyprint-override"><code>version: &quot;3.8&quot;
services:
  worker:
    build:
      dockerfile: ./worker/Dockerfile
    environment:
      - PYTHONUNBUFFERED=1
  api:
    build:
      dockerfile: ./api/Dockerfile
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - &quot;8050:8050&quot;
    depends_on:  # won't have an effect in Kubernetes,
      - worker   # but still good Docker Compose practice
</code></pre>
<p>The bind-mount of the Docker socket is a larger problem.  This socket usually doesn't exist in Kubernetes, and if it does exist, it's frequently inaccessible (there are major security concerns around having it available, and it would allow you to launch unmanaged containers as well as root the node).  If you <em>need</em> to dynamically launch containers, you'd need to use the <a href="https://kubernetes.io/docs/concepts/overview/kubernetes-api/" rel="nofollow noreferrer">Kubernetes API</a> to do that instead (look at creating one-off <a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/" rel="nofollow noreferrer">Jobs</a>).  For many practical purposes, having a long-running worker container attached to a queueing system like RabbitMQ is a better approach.  Kompose can't fix this architectural problem, though, you will have to modify your code.</p>
<p>When all of this is done, I'd expect Kompose to create four files, with one Kubernetes YAML manifest in each: two <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployments</a>, and two matching <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">Services</a>.  Each of your Docker Compose <code>services:</code> would get translated into a separate Kubernetes Deployment, and you need a paired Kubernetes Service to be able to connect to it (even from within the cluster).  There are a number of related objects that are often useful (ServiceAccounts, PodDisruptionBudgets, HorizontalPodAutoscalers) and a typical Kubernetes practice is to put each in its own file.</p>
