Hacker News new | ask | show | jobs
by moistoreos 3000 days ago
To follow this up, can anyone explain the benefits over Docker? I've used Docker before but am unfamiliar with Kubernetes terminology. I do understand it's an open source project by Google.
8 comments

Kubernetes USES docker, so it's not a competitor.

The main benefits over the competing docker project, Docker Swarm, is that it does WAY MORE, is 100% free and open source, and has much better adoption.

I would argue that with Docker Swarm you have to bring the glue yourself, and it doesn't really solve any of the hard problems. Kubernets on the other hand is an all-in-one package that solves a LOT of hard problems for you.

+1 for open source then. Thanks for the explanation.
If you accept the analogy that Kubernetes is an OS for the Data Center, then ‘docker’ command is the process/application launcher in that model. ‘docker’ does one thing well and Kubernetes does many things to provide a management and monitoring framework around a Container Runtime like ‘docker’ or ‘cri-o’ or the others.
I appreciate this analogy. Thanks for the input. +1
Just to correct you, while Kubernetes originated at Google, it is now not owned by them and was contributed to the Cloud Native Computing Foundation (CNCF) and is independently governed there: https://www.cncf.io/projects/
Kubernetes runs Docker containers (and rkt containers) but provides additional functionality like ensuring x instances of that container run across a cluster, load balancing, service discovery, and configuration management.
Thanks!
So let’s say your application is running In Docker. How do you make sure that all the containers that should be running are running and how do you make sure they can talk to each other and the outside world as necessary?

Kubernetes is one solution. You use config files to specify how many of what should be running and it makes sure the system stays in that state and recovers as need be. It’s at a higher level of abstraction than running Docker containers manually on machines.

This makes sense from container to container communication. Does this help with database instances or is it typical to leave database calls as an external source to the orchestration?
Projects I’ve worked on have always had the DB in a separate container.
This isn't a full explanation, but Kubernetes isn't a direct competitor to Docker -- but rather Swarm, Docker's orchestration solution. Both work with Docker (or one of it's direct competitors such as Rkt) to orchestrate multiple containers that work in conjunction with eachother.
So it's essentially preference when it comes to orchestration. Thanks. :thumbs_up:
What your application like (web browser, spreadsheet, and word processor) is to your operating system. Docker is to kubernetes. Docker lets you package applications into containers, kubernetes manages your containers, in terms of scheduling, resource allocation, etc.
I assume it depends on the need but an orchestration could represent a bunch of microservice apps for a single larger project. This is making me think... can you nest orchestrations?
Received more answers than I anticipated. Thanks for the explanations my fellow tech peeps.