Kubernetes can speed up the development process by making easy, automated deployments, updates (rolling-update) and by managing our apps and services with almost zero downtime.
In this article, we'll walk back in time to see how Kubernetes evolved from an internal container orchestration solution at Google to the tool that we know today.
To begin our Kubernetes history, we must begin with Google. Google faced a major issue in the early 2000s. While they continued to dominate the majority of the digital world, they were still figuring out how to make revenue from their extensive number of free services. This included popular services like:
- Google Search
The problem for Google, which was not the profit-making machine we know today, was finding a way to offer these free services without tanking the business. Keep in mind that it costs a ton to keep services like these up and running — especially if they are popular, which they were.
The difficulty for Google, which was not yet a profit-making machine, was figuring out how to deliver these free services without destroying the business. Keep in mind that maintaining services like this is expensive, especially if they are popular, as they were.
While Google was not producing the amount of money that it is today, it did have one advantage. Google, you see, was still pulling the best and brightest to its teams even in the early millennium. With this in mind, Google's primary objective evolved.
Google asked its team, “How can we get maximum performance from our hardware?”
The problem was managing Google's huge architecture of commodity hardware. Google used a completely different approach to achieve its new aim. Google's infrastructure and application architecture have to be totally redesigned. As a result, around 2003-2004 Google created a new application orchestration system known as 'Borg'.
You may be unfamiliar with the Borg; the name comes from the American science fiction series Star Trek. The Borg are an alien group that appears as recurrent enemies in the fictional Star Trek universe. They weren't the good guys, but it's an excellent metaphor for the technology that would eventually become Kubernetes.
Borg developed the cluster management system required by Google to keep up with the millions of users of its services. It even preceded Linux kernel capabilities like control groups, which are today foundational elements of containerized applications. This meant that the project wasn't very outside party-friendly and could only be used within Google.
Google felt Borg provided them a competitive advantage at the time. As a result, the initiative was kept a secret. Nonetheless, the project's contributions to what is now known as Kubernetes are priceless.
Now another tech startup was developing really cutting-edge techniques to application development. We're talking about Docker.
We could talk about the Docker Engine and containerized apps all day. However, the focus of today's article is on the influence Docker had on Google's team, and how it pushed a few Googlers to create the open-source Kubernetes we use today.
Now, 2013 was an interesting year since Docker popularised container management, Borg was around a decade old at this point.
The project had developed significantly throughout those years. The creation and design of Borg and its successor, Omega, taught Google's engineers a lot. In fact, many team members had no idea how influential their work would be in the future.
Borg was around a decade old at this point. However, Joe Beda, Brendan Burns, and Craig McLuckie looked at the popularity of Docker’s containers and saw a path forward for some of Borg’s more useful elements.
Those three Googlers set out to develop a project that would combine all of the fantastic qualities of Borg/Omega with Docker's containers. It was a difficult choice to make the entire thing open source. Google's cloud services were in their beginnings at the time. This meant that adopting a Google-only container orchestration platform wasn't an option.
Google Cloud was able to create an useable and scalable containerized orchestration platform internally with the Borg/Omega project, but to bridge the gap between internal and external required the participation of engineers all around the world — and the only way to do this was to make the whole project open-source.
Thus, Kubernetes was born, and the basic components of Kubernetes architecture that we know today became part of the tech world.
- Kubernetes v1.0.0 was released on July of 2015, since than we’ve only seen the Kubernetes cluster grow.
- Google worked with the Linux Foundation to form the Cloud Native Computing Foundation (CNCF) in 2015.
- Google gave the Kubernetes project to the Cloud Native Computing Foundation in 2016. (CNCF). The CNCF was established in 2015 as a Linux Foundation initiative and presently has over 500 members, including developers, end users, and IT technology and service providers. This community's purpose is to create an open source ecosystem of vendor-neutral products.
- In February 2016, the Helm package manager for Kubernetes was released. Helm basically helps you manage Kubernetes applications.
- On March 6, 2018, Kubernetes Project reached ninth place in the list of GitHub projects by the number of commits, and second place in authors and issues, after the Linux kernel.
- Until version 1.18, Kubernetes followed an N-2 support policy, meaning that the three most recent minor versions receive security updates and bug fixes. Starting with version 1.19, Kubernetes follows an N-3 support policy.
We are excited to see where Kubernetes will take us. There is a lot of buzz these days about 'serverless' solutions, but Kubernetes is headed in the opposite way. Kubernetes, on the other hand, has a place in our 'increasingly serverless' world. Kubernetes-based tools such as Kubeless and Fission provide equivalents to functions-as-a-service.
It was interesting to learn about the history of Kubernetes, but there is a lot more to know about our favourite orchestration engine. Check out - Learn Kubernetes for Beginners