The Origin of Kubernetes
While many are aware that Kubernetes was launched as an Open Source project by Google, there are a number of interesting facts about the origin of Kubernetes of which you may not be familiar.
Hi, this is Jonathon Smith, Director of Field Engineering and Education for Cloud Native Applications. I don’t know about you, but I always enjoy origin stories, so today I’m going to talk about the Kubernetes Origin and provide a little bit of back story on how Kubernetes came to be.
So I’ll start this story at the end. As many of you may know, Kubernetes was born at Google, but it didn’t start off known as Kubernetes and it almost didn’t happen at all. Version One of Kubernetes was launched in 2015 and this is a Hacker news thread from around that time. While this is only four years ago, it’s important to remember at the time Docker was a hot start up that had popularized container usage. Mesos was an orchestration tool powering Twitter, and it was far from certain that Kubernetes was going to be successful.
Now, two things stand out to me from this thread. First, wagering on Google was generally viewed as a pretty good bet, and second, a lot of people mentioned Borg. If we’re going to understand Kubernetes, we have to go back at least 10 years prior to 2015 to talk about how Google was managing infrastructure at a scale that was truly remarkable. Google had many successes, not the least of which is Google Search, Gmail and certainly, eventually, YouTube but success isn’t all roses and flowers because quantity has a quality all of its own.
At massive scale when we’re talking about things like Search and Gmail and YouTube, architectural solutions that worked before may no longer work. Either the scale is so large that things simply break under load, or solving the problem is so expensive it’s just not realistic using traditional means. And so a free product with millions of users, it’s expensive, and remember Google wasn’t always one of the most valuable corporations in the world.
In the early 2000s it was still dialing in its revenue, and internet advertising was a relatively nascent thing. Google may not have had an abundance of cash but it did attract many very talented engineers so Google created a new goal. They decided to engineer a system that could wring every ounce of performance from its hardware, and not just any hardware but commodity hardware. And it did so by rethinking its infrastructure and application architecture. And thus, Borg was born. The name Borg is a reference to Star Trek. In the Star Trek: The Next Generation, there was an alien race of cybernetic organisms linked in a hive mind known as the Collective that forcibly transformed individual humans into drones through a process known as assimilation.
They weren’t friendly, uh, but this is a really a great name and a metaphor for a cluster management system that’s responsible for keeping workloads running, that supports millions of users for Google services. Now Borg predated the Linux kernel feature such as Control Groups which is a foundational technology for containers, but it had the same goal, to allow for data centers to run processes at very high efficiency on commodity infrastructure.
However, Borg was built from scratch and it was uniquely designed for use at Google, not something that could easily be exposed to outside parties, and more importantly it was viewed as a significant competitive advantage and rarely spoken of outside of Google. The primary goal was, of course, cost savings, however there were additional benefits, namely improvements in developer productivity. With Borg and many other systems Googlers spent an enormous amount of time creating infrastructure, tools and processes that significantly increased developer productivity by allowing them to focus on things that mattered.
Borg, again, predated cgroups but ultimately was contributed, uh, to the open source community and it made a lot of things possible, uh, around containers and containerization. Around 2013, 2014 Docker, uh, again was, uh, was the, the company that really popularized the use of containers and seeing the rise of containers as a scalable, portable, efficient mechanism for running workloads, Joe Beda, Craig McLuckie, and Brendan Burns at Google set out to create a project that incorporated everything Google engineers had learned through the design and, and development of Borg and its successor, Omega.
Of course, I think it’s fair to say that nobody on the team had any idea the impact of that decision but it wasn’t easy. Urs Holzle, Google’s CTO, his initial reaction was, “So let me get this straight. You want to build an external version of the Borg task scheduler. One of our most important competitive advantages. The one we don’t even talk about externally. And, on top of that, you want to open source it?”
Arguments were made and at this point Google Cloud, uh, was still relatively early and, and behind, uh, competitors, but the team and Urs recognized that containers were a great way to standardize workload management, and the fact that Google had over 10 years of experience made them uniquely positioned to do this and to do it well.
Now what’s an origin story without a few Easter eggs, so let’s provide a couple of unique things, uh, uh, that, that hopefully you, you don’t already know. So internally the Kubernetes project was known as Project Seven or Project Seven of Nine, and for those of you who are not Star Trek fans, Seven of Nine was a member of Star Trek Voyager, uh, and she was rescued, uh, from the Borg Collective. So by calling uh, the, the project Project Seven it extended the Star Trek Borg naming theme, but also represented that the project was designed to be a friendlier Borg. In keeping with its name, Project Seven was designed to be used uh, uh, by developers and more easily.
That may seem a little bit funny since Kubernetes is still challenging to use for developers, but we’re talking about relative terms here. Compared to the massive system that is Borg, there were many improvements made to make container technologies accessible outside the walls of Google and easier for developers to consume. The project was officially launched as an open source project in 2014 as part of the Linux Foundation in keeping with the, the Docker container, nautical shipping theme it was named Kubernetes, which is, uh, Greek for helmsman or captain. Unfortunately that ended the Star Trek naming themes, however in homage to Project Seven the Kubernetes logo noticeably has seven points to its wheel. After Google, Joe Beda and Craig McLuckie founded Heptio with a mission to help companies successfully adopt Kubernetes. And just to point out the link, Heptio, uh, extends the Greek root word Hept, uh, which means seven, again in honor of Kubernetes, its origin as Project Seven of Nine.
And even the Heptio logo, uh, provides a little Easter egg, uh, which is the number seven, uh, used as a mask to create the H in Heptio. In 2018 Heptio was acquired by vmware and, of course, the team is still quite engaged in continuing its mission of helping customers be successful with Kubernetes and Kubernetes has come a long way since the early days inside of Google and its initial launch as an open source project. It is now one of the most significant, uh, as well as successful open source projects and it’s also spawned an entire community. Uh, the CNCF or the Cloud Native Compute Foundation was created as a governance model for both Kubernetes as well as the many open source projects spawned out of, uh, the Cloud Native movement. So, hopefully that was useful and helpful to learn a little bit about, uh, Kubernetes, and thank you for your time.
Have questions about the material in this lesson?
We’ve got answers!
Post your questions in the Kubernetes community Slack. Questions about this lesson are best suited for the #kubernetes-novice channel.
Not yet a part of the Kubernetes Slack community? Join the discussion here.
Have feedback about this course or lesson? We want to hear it!
Send your thoughts to KubeAcademy@VMware.com.