A common theme that emerged during these conversations was that of course everyone knew what Kubernetes was, was actively deploying it, and understood it thoroughly– until the conference halls emptied, the after-hours events started, and the truth started flowing. What emerged was rather telling; Kubernetes means different things to different people, and communicating its value to people who hadn't encountered it in the real world yet was something of an exercise in metaphor.
During those conversations, a number of different descriptions for what Kubernetes actually is emerged. One that I'm particularly partial towards is describing it as the kernel for a computer that spanned multiple nodes. "It manages messaging between processes, handles queuing, and resource allocation." The challenge with that description is that presupposing a knowledge of operating system design in your audience isn't the most approachable thing in the world.
It might be more apt to describe Kubernetes as an air traffic controller. A central point of command and control that assumes responsibility for scheduling arrivals, departures, ensuring that planes/containers don't smash into one another and kill hundreds of people, etc.
And for the incredibly cynical among us, you might go so far as to explain Kubernetes with a complex analogy to neurosurgery. It almost doesn't matter which direction you take that one in-- nobody is going to be confident enough in this arena to intelligently dispute your characterization! If you can't explain something accurately, explain it in so complex a way that nobody dares question you-- ask any company with 30,000 microservices in production.
Ultimately, you can describe Kubernetes in a lot of ways. The one thing you increasingly can't do is ignore it.
