While diving into Docker, Google Cloud and Kubernetes, and without clearly understanding all three of them yet, it seems to me these products are overlapping, yet they're not compatible.
For example, a docker-compose.yml file needs to be re-written so an app can be deployed to Kubernetes.
Could someone provide a high-level, rough description of where Docker, Docker Compose, Docker Cloud, and Kubernetes overlap and where one is dependent on the other?
In addition to @yamenk's answer, I'd like to add a few details here which might help people with their journey of understanding Kubernetes.
docker-compose: is a tool that takes a YAML file which describes your multi-container application and helps you create, start/stop, remove all those containers without having to type multiple docker ... commands for each container.Kubernetes: is a platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. What? Keep reading...(from the docs): Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration. Compose has commands for managing the whole lifecycle of your application:
- Start, stop, and rebuild services
- View the status of running services
- Stream the log output of running services
- Run a one-off command on a service
(from Introduction to Kubernetes): Kubernetes is a container orchestrator like Docker Swarm, Mesos Marathon, Amazon ECS, Hashicorp Nomad. Container orchestrators are the tools which group hosts together to form a cluster, and help us make sure applications:
- are fault-tolerant,
- can scale, and do this on-demand
- use resources optimally
- can discover other applications automatically, and communicate with each other
- are accessible from the external world
- can update/rollback without any downtime.
Many people argue that Kubernetes is hard to learn. It's because it solves a series of problems and people try to understand without knowing all the prerequisites. This makes it complicated. Start putting the pieces of the puzzle together by reading about concepts/terms like the following. This process will help you understand the kind of problems Kubernetes tries to solve:
And because there are a lot of different things around containers and their management, keep an eye on the Cloud Native landscape:
Interactive version here: landscape.cncf.io/
May 2020: Docker Compose Specification is now an open standard
Working with AWS, Microsoft, and others in the open source community, we have extended the Compose Specification to support cloud-native platforms like Kubernetes, and Amazon ECS in addition to the existing Compose platforms. More here: blog / compose-spec.io
If you are networking containers within the same host go for docker compose.
If you are networking containers across multiple hosts go for kubernetes.
Docker Compose is not a production ready tool. It works great for PoC or development environments, but lacks a lot of the capabilities that are more or less table stakes for serious production use. Swarm is more production-ready, but I would never invest into Swarm in a greenfield scenario. Kubernetes has won the orchestration battle, as evidenced by its inclusion into Docker Desktop and it being offered by all major cloud providers. Kubernetes is much more capable and has far more community and corporate support.
I would recommend diving into some of the Kubernetes tutorials available at Pluralsight, Linux Academy, etc. and spinning up a cluster to play around with in your cloud platform of choice (EKS, AKS, GKE, etc.). If you are trying to spin up on bare metal, take a look at OpenShift, but recognize that you lose some of the magic of Kubernetes in this setup.