Search code examples
dockerkubernetesdocker-composedocker-swarm

Docker Swarm, Kubernetes and Compose

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?
Solution

  • 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.