The Evolution of Kubernetes

Let’s start from the beginning.

Amazon Web Services (AWS) changed the world when it brought us modern day cloud computing. Since then, everyone else has been trying to catch up. One of the companies trying to catch up is Google. Google has its own excellent cloud, but it needs a way to abstract the value of AWS and make it easier for potential customers to use the Google Cloud.

Google has a lot of experience working with containers at scale. For example, huge Google applications, such as Search and Gmail, have been running at extreme scale on containers for many years – way before Docker brought us easy-to-use containers. To orchestrate and manage these containerized apps, Google had a couple of in-house proprietary systems. They took the lessons learned from these in-house systems and created a new platform called Kubernetes; they donated it to the newly formed Cloud Native Computing Foundation (CNCF) in 2014 as an open-source project.

Since then, Kubernetes has become the most important cloud-native technology on the planet. Like many of the modern cloud-native projects, it’s written in Go (Golang), it’s built in the open on GitHub (at kubernetes/kubernetes), it’s actively discussed on the IRC channels, you can follow it on Twitter (@kubernetesio) and slack.k8s.io is a pretty good slack channel.

There are also regular meetups and conferences all over the planet.

Kubernetes and Docker

Kubernetes and Docker are complementary technologies. For example, it’s common to develop your applications with Docker and use Kubernetes to orchestrate them in production.

In this model, you write your code in your favorite languages and then use Docker to package it, test it, and ship it. But the final steps of deploying and running it are handled by Kubernetes.

At a high level, you might have a Kubernetes cluster with 10 nodes to run your production applications. Behind the scenes, each node is running Docker as its container runtime. This means that Docker is the low-level technology that starts and stops the containerized applications. Kubernetes is the higher-level technology that looks after the big picture decisions, such as deciding which nodes to run containers on, deciding when to scale up or down, and executing updates.

As can be seen in the figure above, Docker isn’t the only container runtime that Kubernetes supports. In fact, Kubernetes has a couple of features that abstract the container runtime (make it interchangeable):

1. The Container Runtime Interface (CRI) is an abstraction layer that standardizes the way third-party container runtimes interface with Kubernetes. It allows the container runtime code to exist outside of Kubernetes, but interfaces with it in a supported and standardized way.

2. Runtime Classes is a new feature that was introduced in Kubernetes 1.12 and promoted to beta in 1.14. It allows for different classes of runtimes. For example, the gVisor or Kata Containers runtimes might provide better workload isolation than the Docker and containerd runtimes.

At the time of writing, containerd is catching up to Docker as the most commonly used container runtime in Kubernetes. It is a stripped-down version of Docker with just the stuff that Kubernetes needs. It’s pronounced container dee.

Kubernetes is deprecating Docker as a container runtime after v1.20.

While all of this is interesting, it’s low-level stuff that shouldn’t impact your Kubernetes learning experience. For example, whichever container runtime you use, the regular Kubernetes commands and patterns will continue to work as normal.

What about Kubernetes vs. Docker Swarm?

In 2016 and 2017 we had the orchestrator wars, in which Docker Swarm, Mesosphere DCOS, and Kubernetes competed to become the de-facto container orchestrator. To cut a long story short, Kubernetes won. It’s true that Docker Swarm and other container orchestrators still exist, but their development and market share are small compared to Kubernetes

Kubernetes and Borg: resistance is futile

There’s a good chance you’ll hear people talk about how Kubernetes relates to Google’s Borg and Omega systems. As previously mentioned, Google has been running containers at scale for a long time – crunching through billions of containers a week. So yes, Google has been running things like Search, Gmail, and GFS on lots of containers for a very long time.

Orchestrating these containerized apps was the job of a couple of in-house Google technologies called Borg and Omega. So, it’s not a huge stretch to make the connection with Kubernetes – all three are in the game of orchestrating containers at scale, and they’re all related to Google.

However, it’s important to understand that Kubernetes is not an open-sourced version of Borg or Omega. It’s more like Kubernetes shares its DNA and family history with Borg and Omega. A bit like this:in the beginning was Borg, and Borg begat Omega. Omega knew the open-source community and begat her Kubernetes.

The point is, all three are separate, but all three are related. In fact, some of the people who built Borg and Omega are involved in building Kubernetes. So, although Kubernetes was built from scratch, it leverages much of what was learned at Google with Borg and Omega. As things stand, Kubernetes is an open-source project donated to the CNCF in 2014, it’s licensed under the Apache 2.0 license, version 1.0, shipped way back in July 2015, and, at-the-time-of-writing, we’ve already passed version 1.16.

Kubernetes: what’s in the name?

The name Kubernetes (koo-ber-net-eez) comes from the Greek word meaning “Helmsman” – the person who steers a seafaring ship. This theme is reflected in the logo.

Apparently, some of the people involved in the creation of Kubernetes wanted to call it Seven of Nine. If you know your Star Trek, you’ll know that Seven of Nine is a female Borg rescued by the crew of the USS Voyager under the command of Captain Kathryn Janeway. Sadly, copyright laws prevented it from being called Seven of Nine. However, the seven spokes on the logo are a tip of the hat to Seven of Nine.

One last thing about the name before moving on: you’ll often see Kubernetes shortened to K8s (pronounced “Kates”). The number 8 replaces the 8 characters between the “K” and the “s” – making it great for tweets and lazy typists like me 😃.