10

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 orchestration tool and also as an alternative to Dockers swarm mode.

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

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

  • 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?
  • 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?
Munchkin
  • 4,528
  • 7
  • 45
  • 93

3 Answers3

10

So if Kubernetes does orchestration, is it also an alternative to docker-compose?

Short Answer: NO

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

Or can compose and Kubernetes be used together?

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

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?

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

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

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

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?

I would replace the whole swarm cluster and compose files constructs with a kubernetes cluster and object definition yamls. Having said that from my experience those yamls can get bit verbose so, if you are keen have a look at Helm. It is a package manager for kubernetes which, you don't have to use but I think it is one of the best tools in kubernetes ecosystem at the moment and there are plenty of open source charts readily available.

I would heavily recommend playing around with kubernetes using minikube 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.

pnyak_
  • 359
  • 1
  • 6
5

First of all, Kubernetes and Docker's Swarm "mode" are both container orchestration tools. Docker compose, the tool and the YAML file format, has historically been the way to describe multi-container applications that are then deployed into Docker's Swarm mode orchestrator.

Kubernetes has its own YAML service definition (and other definition file formats) which are not using the compose file format.

However, with the announcement of Docker's Kubernetes support, they will be providing the capability for the Docker compose tool to also target taking a compose YAML file and deploying the "content" of that compose file (networks, services + env/secrets) into a Kubernetes cluster, with Kubernetes orchestration engine placing those components on K8s pods.

Based on the above statements, your questions are really about whether you would want to switch to defining your services, environment, networks, etc. in Kubernetes YAML, or would you rely on Docker's support to use the compose format and target either Swarm mode or K8s. That is more of a business decision between Docker's support for Kubernetes or open source or other commercial Kubernetes options, so there are not necessarily direct (and/or exactly correct) answers to your questions.

Phil E
  • 1,840
  • 14
  • 19
  • 1
    "`they will be providing the capability for the Docker compose tool to also target taking a compose YAML file and deploying the "content" of that compose file (networks, services + env/secrets) into a Kubernetes cluster`" - that's the most important sentence to me, thank you! – Munchkin Oct 20 '17 at 10:54
0

You can use your existing docker-compose file with Kubernetes today using kompose: https://github.com/kubernetes/kompose . kompose will transform your docker-compose services into Kubernetes objects on the fly.

The transformation may not be perfect because there is not a 1 to 1 match between the "schema" of docker-compose and schemas of Kubernetes objects, but it should get you on your way.

If your goal is to run on a single machine, there is no need for Kubernetes. But if you have used swarm mode with your docker-compose file then you should try kompose.

Sebastien Goasguen
  • 328
  • 4
  • 9