When it comes to modern IT infrastructure, the role of Kubernetes—the open-source container orchestration platform that automates the deployment, management and scaling of containerized software applications (apps) and services—can’t be underestimated. According to a Cloud Native Computing Foundation (CNCF) report (link resides outside ibm.com), Kubernetes is the second largest open-source project in the world after Linux and the primary container orchestration tool for 71% of Fortune 100 companies.
To understand how Kubernetes came to dominate the cloud computing and microservices marketplaces, we have to examine its history.
The evolution of Kubernetes
The history of Kubernetes, whose name comes from the Ancient Greek for “pilot or “helmsman” (the person at the helm who steers the ship) is often traced to 2013 when a trio of engineers at Google—Craig McLuckie, Joe Beda and Brendan Burns—pitched an idea to build an open-source container management system. These tech pioneers were looking for ways to bring Google’s internal infrastructure expertise into the realm of large-scale cloud computing and also enable Google to compete with Amazon Web Services (AWS)—the unrivaled leader among cloud providers at the time.
Traditional IT infrastructure versus virtual IT infrastructure
But to truly understand the history of Kubernetes—also often referred to as “Kube” or “K8s,” a “numeronym” (link resides outside ibm.com)—we have to look at containers in the context of traditional IT infrastructure versus virtual IT infrastructure.
In the past, organizations ran their apps solely on physical servers (also known as bare metal servers). However, there was no way to maintain system resource boundaries for those apps. For instance, whenever a physical server ran multiple applications, one application might eat up all of the processing power, memory, storage space or other resources on that server. To prevent this from happening, businesses would run each application on a different physical server. But running apps on multiple servers creates underutilized resources and problems with an inability to scale. What’s more, having a large number of physical machines takes up space and is a costly endeavor.
Virtualization
Then came virtualization—the process that forms the foundation for cloud computing. While virtualization technology can be traced back to the late 1960s, it wasn’t widely adopted until the early 2000s. Virtualization relies on software known as a hypervisor. A hypervisor is a lightweight form of software that enables multiple virtual machines (VMs) to run on a single physical server’s central processing unit (CPU). Each virtual machine has a guest operating system (OS), a virtual copy of the hardware that the OS requires to run and an application and its associated libraries and dependencies. While VMs create more efficient usage of hardware resources to run apps than physical servers, they still take up a large amount of system resources. This is especially the case when numerous VMs are run on the same physical server, each with its own guest operating system.
Containers
Enter container technology. A historical milestone in container development occurred in 1979 with the development of chroot (link resides outside ibm.com), part of the Unix version 7 operating system. Chroot introduced the concept of process isolation by restricting an application’s file access to a specific directory (the root) and its children (or subprocesses). Modern-day containers are defined as units of software where application code is packaged with all its libraries and dependencies. This allows applications to run quickly in any environment—whether on- or off-premises—from a desktop, private data center or public cloud. Rather than virtualizing the underlying hardware like VMs, containers virtualize the operating system (usually as Linux or Windows). The lack of the guest OS is what makes containers lightweight, as well as faster and more portable than VMs.
Borg: The predecessor to Kubernetes
Back in the early 2000s, Google needed a way to get the best performance out of its virtual server to support its growing infrastructure and deliver its public cloud platform. This led to the creation of Borg, the first unified container management system. Developed between 2003 and 2004, the Borg system is named after a group of Star Trek aliens—the Borg—cybernetic organisms who function by sharing a hive mind (collective consciousness) called “The Collective.” The Borg name fit the Google project well. Borg’s large-scale cluster management system essentially acts as a central brain for running containerized workloads across its data centers. Designed to run alongside Google’s search engine, Borg was used to build Google’s internet services, including Gmail, Google Docs, Google Search, Google Maps and YouTube. Borg allowed Google to run hundreds of thousands of jobs, from many different applications, across many machines. This enabled Google to accomplish high resource utilization, fault tolerance and scalability for its large-scale workloads. Borg is still used at Google today as the company’s primary internal container management system. In 2013, Google introduced Omega, its second-generation container management system. Omega took the Borg ecosystem further, providing a flexible, scalable scheduling solution for large-scale computer clusters. It was also in 2013 that Docker, a key player in Kubernetes history, came into the picture.
Docker ushers in open-source containerization
Developed by dotCloud, a Platform-as-a-Service (PaaS) technology company, Docker was released in 2013 as an open-source software tool that allowed online software developers to build, deploy and manage containerized applications. Docker container technology uses the Linux kernel (the base component of the operating system) and features of the kernel to separate processes so they can run independently. To clear up any confusion, the Docker namesake also refers to Docker, Inc. (formerly dotCloud, link resides outside ibm.com), which develops productivity tools built around its open-source containerization platform, as well as the Docker open source ecosystem and community (link resides outside ibm.com). By popularizing a lightweight container runtime and providing a simple way to package, distribute and deploy applications onto a machine, Docker provided the seeds or inspiration for the founders of Kubernetes. When Docker came on the scene, Googlers Craig McLuckie, Joe Beda and Brendan Burns were excited by Docker’s ability to build individual containers and run them on individual machines. While Docker had changed the game for cloud-native infrastructure, it had limitations because it was built to run on a single node, which made automation impossible. For instance, as apps were built for thousands of separate containers, managing them across various environments became a difficult task where each individual development had to be manually packaged. The Google team saw a need—and an opportunity—for a container orchestrator that could deploy and manage multiple containers across multiple machines. Thus, Google’s third-generation container management system, Kubernetes, was born.
Learn more about the differences and similarities between Kubernetes and Docker
The birth of Kubernetes
Many of the developers of Kubernetes had worked to develop Borg and wanted to build a container orchestrator that incorporated everything they had learned through the design and development of the Borg and Omega systems to produce a less complex open-source tool with a user-friendly interface (UI). As an ode to Borg, they named it Project Seven of Nine after a Star Trek: Voyager character who is a former Borg drone. While the original project name didn’t stick, it was memorialized by the seven points on the Kubernetes logo (link resides outside ibm.com).
Inside a Kubernetes cluster
Kubernetes architecture is based on running clusters that allow containers to run across multiple machines and environments. Each cluster typically consists of two classes of nodes: Worker nodes, which run the containerized applications. Control plane nodes, which control the cluster. The control plane basically acts as the orchestrator of the Kubernetes cluster and includes several components—the API server (manages all interactions with Kubernetes), the control manager (handles all control processes), cloud controller manager (the interface with the cloud provider’s API), and so forth. Worker nodes run containers using container runtimes such as Docker. Pods, the smallest deployable units in a cluster hold one or more app containers and share resources, such as storage and networking information.
Read more about how Kubernetes clusters work
Kubernetes goes public
In 2014, Kubernetes made its debut as an open-source version of Borg, with Microsoft, RedHat, IBM and Docker signing on as early members of the Kubernetes community. The software tool included basic features for container orchestration, including the following: Replication to deploy multiple instances of an application Load balancing and service discovery Basic health checking and repair Scheduling to group many machines together and distribute work to them.
In 2015, at the O’Reilly Open Source Convention (OSCON) (link resides outside ibm.com), the Kubernetes founders unveiled an expanded and refined version of the software, which quickly gained popularity in the industry. Today, Kubernetes continues to evolve and shape the future of cloud computing and microservices.
Source link
