“Kubernetes is for automating deployment, scaling, and management of containerized applications.”
Basic idea is that a user defines what should run, and it manages by running those 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 updating services to making them highly available.
We had been hearing about some cluster management magic from our friends working 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. Things changed a lot of course. For some time now we’re planning, deploying and using kubernetes clusters when we decide it’s going to be helpful. Still, not just for the sake of it, or just because it’s popular.
On the other hand, 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.