It all began in the fall of 2013, with three of us : Craig McLuckie, Joe Beda and I were working on public cloud infrastructure.

If you cast your mind back to the world of cloud in 2013, it was a vastly different place than it is today. Imperative bash scripts were only just starting to give way to declarative configuration of IaaS with systems. Netflix was popularizing the idea of immutable infrastructure but doing it with heavy-weight full VM images. The notion of orchestration and container orchestration existed in a few internet scale companies, but not in cloud and certainly not in the enterprise.

Docker changed all of that. By popularizing a lightweight container runtime and providing a simple way to package, distribute and deploy applications onto a machine, it popularized a brand-new cloud native approach to application packaging and maintenance.

But as we thought about it, it was obvious that Docker, with its focus on a single machine, was not the complete solution. While Docker was great at building and packaging individual containers and running them on individual machines, there was a clear need for an orchestrator that could deploy and manage large number of containers across a fleet of machines.

This realization crystallized for us in the late fall of 2013, and thus began the rapid development of a first prototype, and then the system that would eventually become known as Kubernetes.

The initial goal was to develop a "minimally viable orchestrator". From experience, we knew that the basic feature set of such an orchestrator was : replication to deploy multiple instances of an application; load balancing and service discovery to route traffic to these replicated containers; basic health checking and repair to ensure a self-healing system; scheduling to group many machines into a single pool and distribute work to them.
—Brendan Burns (July 20, 2018) The History of Kubernetes & the Community Behind It kubernetes.io