What Kubernetes really is, and how orchestration redefines the data center



Video: What is Kubernetes?

The purpose of Kubernetes is not immediately obvious to anyone whose concept of the purpose and function of a data center was established in the era when the operating system was the platform upon which all software depended. Kubernetes is the product of a massive, ongoing realignment of the software resources that collectively comprise a network application. That alignment is centered around a concept called the workload, which is a broad concept of a job performed by one or more applications, or one or more services, across a multitude of processors.

Must read: How GitHub became the nexus of software automation

A workload is a job — for example, managing a supply chain, overseeing logistics, tracking inventory, facilitating a securities market. Kubernetes has become the modern era’s job control system.

“You can think of Kubernetes as a platform for application patterns,” explained Google software engineer Janet Kuo, during a tutorial session at the KubeCon 2017 conference. “The patterns make your application easy to deploy, easy to run, and easy to keep running.”

(Image: National Gallery of Art/public domain)

The declining virtue of virtual machines

There is a growing class of data center infrastructure that is geared to concentrate on the health and well-being of workloads rather than that of the servers. Whether they’re physical processors or virtual machines, servers may fail. The impact of that failure upon the availability and functionality of these workloads should be less than minimal — they should not appear impacted at all.

Up until 2016, the open source community had come up with a handful of methodologies for orchestrating workloads for maximum availability. In a very short period of time, Kubernetes became the choice of enterprises that had made investments in open source. The reasons why could constitute an entire book, and if written well enough, it could be adapted to one of those art theater movies that win over the critics but never the Oscars.

Read also: Kubernetes vendors agree on standardization

Here, perhaps, is the only reason that matters: Google’s early move to spur the Linux Foundation’s establishment of the Cloud Native Computing Foundation (CNCF) gave Kubernetes enough time to organically nurture a following among the broadest group of people. The entire open-source business model revolves around the value of support. Enterprises that no longer desire to be locked into a single vendor (which, admittedly, is not everyone) appreciate the newfound value of pluralism in a support system. A group of vendors acting, if not always in concert, then at least with some modicum of coordination toward the same goal, is superior to a single vendor leading a monopolistic platform in no particular direction.

Why Kubernetes matters now

Kubernetes is not owned by any one company, although it’s based on a project called Borg that was originally developed internally at Google, and Google is often perceived to be the de facto leader of the Kubernetes development community. That said, Microsoft has completely retooled its entire server system philosophy around Kubernetes, and hired several of its principal creators. As an open-source project, Kubernetes is governed by the Cloud Native Computing Foundation (CNCF), an agency of the Linux Foundation.

Read also: Kubernetes graduates to full-pledged, open-source program

Google originally designed Borg to suit its own internal purposes. So it’s more than fair to use Google’s search engine itself as an example: The basic job of hunting for matching entries in a search query is conducted by hundreds, perhaps thousands, of individual services that share the responsibility. I’d say “countless,” but that’s not only wrong but contrary to the whole point of Kubernetes. It does keep count of all the services and components that comprise the active job, or jobs, throughout the network.

Didn’t Docker have something to do with this?

There is no better term at present, sadly, for the container in which these distributed pieces of programs are contained than “container.” (For a while, we called these things “Docker containers” to distinguish them from “Tupperware containers,” but today, Docker comprises only a part of the container ecosystem; plus, there’s more than one format of container.) If you’re familiar with a ZIP file, which uses mathematical compression to mash several files together into one, then you already understand quite a bit about modern software containers. They actually do use the same method to compress several files together. Those files are made up of just the executable elements and data the program would need to run, without having to look someplace else in the network. One of those elements may actually be a small operating system — a miniaturized version of Linux, typically, or from Microsoft, a tiny cousin of Windows called Nano Server.

Read also: How to get the Kubernetes help you need

A program that was written for this method of containerized deployment, such as a search query response, could look through an index of cached Web pages for an entry that hasn’t been selected yet, examine the semantic context of that entry for matches against the content of the query, rank the result, and register it in a list for later collection and retrieval. The program would then terminate. This is one of the characteristics of a distributed service that makes it so different from a PC application: It fulfills a request and then stops. It knows it’s part of a much broader job, so once it fulfills its function, it ceases to exist. Software engineers borrow a concept from modern philosophy to describe this aspect: Ephemeralism. Unlike a GUI-based application, that literally spends most of its cycles waiting for a response from its user, an ephemeral service fulfills its function and then expires.

In a containerized network (again, so sorry, but there’s no better word), programs are run in isolation from one another. Even though they may share the same processor and memory space, the host operating system outside the containers maintains their separation. (Theoretically this joint dependency is exploitable, though no known threatening exploit yet exists in the wild.) Communication can only take place between containers through a software-defined network. A more sophisticated SDN will give these containers network addresses strategically, taking into account how they will be collected together to perform a common job.

What it means to orchestrate workloads

Here is where orchestration enters the picture. Unlike “container,” “orchestration” is term that perfectly describes the role Kubernetes plays. While some have illustrated this concept using an orchestra conductor, there’s a big difference between a conductor and an orchestrator, both in music and in distributed applications. The act of orchestration lays out the patterns for individual applications to work together, in concert with one another — like instruments in a band. While the composer produces the software’s original pattern, including its melodic line and rhythm (the term for assembling a software container actually is composition), the orchestrator makes the piece audible.

“This is why I call Kubernetes a ‘composable platform,'” explained Brian Gracely, director of product strategy for Red Hat, during a recent company webinar. “There is somewhat of a framework of what it should look like — and some of this comes from the Kubernetes community, some of it comes from years and years of experience across the community, of how to go about deploying applications.”

Read also: Why Docker is finally embracing Kubernetes – TechRepublic

The orchestrator’s principal job is to maintain the operating status of the applications under its trust. In another era, that job was entrusted to the operating system. But that was when the platform was a single processor with a single bank of memory and dedicated storage devices. Today, there isn’t much to materially link a containerized service with any broader context of an application. (With the most sophisticated of these architectures, utilized by huge cloud services such as Netflix, no such link exists at all.) Indeed, it is the orchestrator that takes the functionality and the work product of all these services, organizes them through some form of a manifest, and comes up with some semblance of an application. Change the manifest, and you might have a different application altogether.

(Image: Red Hat)

There is nothing structurally unique that distinguishes Kubernetes from any other type of application. It is not a virtual machine. Its orchestrator runs on an operating system. When running, it maintains a cluster of nodes, which is a more abstract way of referring to servers that may be physical or virtual. On each of these nodes are pods of containers. And within each of them is a client-side agent called the kubelet, which manages functions independently on behalf of the orchestrator, for the node to which it’s assigned. But even that is a program like any other.

Read also: How to quickly install Kubernetes on Ubuntu – TechRepublic


Has Kubernetes Already Become Too Unnecessarily Complex for Enterprise IT? by Scott M. Fulton, III, The New StackContext: Kubernetes, OpenStack, and How SAP Built Its Own Containerized Platform [podcast] by Scott M. Fulton, III, The New StackThe State of the Kubernetes Ecosystem — e-book co-authored by Scott Fulton and contributors to The New Stack

Related Topics: