“Kubernetes is for automating deployment, scaling, and management of containerized applications.”
Basic idea is that a user defines what should run, and kubernetes will manage it on available machines. If you have more than a few applications and/or need to run them on a lot of machines, it can help you in many ways from packaging applications to making them highly available to service discovery.
We had been hearing about some cluster management magic from our friends at Google and on the blogosphere at large for some time, so it wasn’t a total surprise when the project was announced in 2014. It made sense to us not because it was popularized by good marketing, but because we were knee-deep in managing an Openstack cloud and docker was just a new kid on the block without a say on anything distributed. The pain of managing large infrastructures was real to us.
But while kubernetes had a solid idea, it was missing a whole bunch to be actually useful back then. Needless to say, things changed a lot. We’re planning, deploying and using kubernetes clusters for some time now. Still, not just for the sake of it, or just because it’s popular, but because we believe it’s helpful in lots of environments.
Deploying kubernetes on a single machine might arguably be an overkill, but it’s not fair to say the same thing for docker, considering it’s generally just a single install away. As developers, we love docker because we control our applications’ environment. As operations people, we love docker because we know our applications are truly portable.
