<p>I just heard of the native Kubernetes support in the future Docker version. I never used Kubernetes before, so I started reading about it. But I got a little bit confused: Kubernetes is described as <strong>orchestration</strong> tool and also as an alternative to Dockers <strong>swarm mode</strong>. </p>

<p>So if Kubernetes does orchestration, is it also an alternative to docker-compose? Or can compose <em>and</em> Kubernetes be used together?</p>

<p>Some specific questions:
Let's say I want (or have) to use Kubernetes:</p>

<ul>
<li>I have a docker-compose file containing multiple microservices, but they are running as a standalone app on a single machine. Can (or should) it be replaced by Kubernetes?</li>
<li>I have a docker-compose file with multiple services configured in swarm mode (running on multiple machines). Which part has to be replaced by Kubernetes? The whole compose file? Or is it somehow possible to define basic configuration (env_var, volumes, command, ...) within compose file and use Kubernetes only to orchestrate the clustering?</li>
</ul>

<blockquote>
  <p>So if Kubernetes does orchestration, is it also an alternative to
  docker-compose? </p>
</blockquote>

<p>Short Answer: NO </p>

<p>It's not just orchestration, essentially <code>Kubernetes</code> is a production grade container orchestration and scheduling engine. It is far more advanced than <code>docker-compose</code> itself. I would say <code>docker swarm</code>, <code>kubernetes</code> and <code>amazon ecs</code> belong in the same category. </p>

<blockquote>
  <p>Or can compose and Kubernetes be used together?</p>
</blockquote>

<p>In the next version of docker engine you will be able to use docker-compose to create <code>kubernetes</code> objects. But as of now you can't.</p>

<blockquote>
  <p>I have a docker-compose file containing multiple microservices, but
  they are running as a standalone app on a single machine. Can (or
  should) it be replaced by Kubernetes?</p>
</blockquote>

<p>Ok, in the context of running it in production, I would say <strong>absolutely</strong>, you should definitely look to host your applications on a <code>kubernetes</code> cluster because it provides </p>

<ul>
<li>resilience (rescheduling of pods if they die)</li>
<li>scaling (scale pods based on cpu or any other metrics)</li>
<li>load-balancing (provides VIP knows service and attaches all pods to it)</li>
<li>secrets and config management</li>
<li>namespaces (logical grouping of kubernetes objects)</li>
<li>network polices (custom policies to control traffic flow between pods)</li>
</ul>

<p>and many more features out of the box. And when you declare a state <code>kubernetes</code> would always try to achieve and maintain that state.</p>

<blockquote>
  <p>I have a docker-compose file with multiple services configured in
  swarm mode (running on multiple machines). Which part has to be
  replaced by Kubernetes? The whole compose file? Or is it somehow
  possible to define basic configuration (env_var, volumes, command,
  ...) within compose file and use Kubernetes only to orchestrate the
  clustering?</p>
</blockquote>

<p>I would replace the whole swarm cluster and compose files constructs with a <code>kubernetes</code> cluster and object definition <code>yaml</code>s. Having said that from my experience those <code>yamls</code> can get bit verbose so, if you are keen have a look at <a href="https://docs.helm.sh/using_helm/#quickstart-guide" rel="noreferrer">Helm</a>. It is a package manager for <code>kubernetes</code> which, you don't <strong>have</strong> to use but I think it is one of the best tools in <code>kubernetes</code> ecosystem at the moment and there are plenty of open source charts readily available.</p>

<p>I would heavily recommend playing around with <code>kubernetes</code> using <code>minikube</code> on your local system just to get familiar with the general concepts. And then you will be able to answer the above questions for yourselves.</p>
