Most answers to the question, “What is Kubernetes?” follow a pattern. It’s open-source. It’s a container-orchestration system. It automates application deployment, scaling, and management. All are true.

However, when I first came across the word ‘Kubernetes,’ I thought it could well be a German martial art (…uber...), a new religious belief system, a new-fangled diet or variation of the forbidden dance.

Today, with associations with the Borg (thanks to Google’s project name in early development) almost forgotten, it seems that Kubernetes is, in fact, a disruptive technology that improves container management and deployment (on virtual or physical machines) for all who need performance enhancement in this area.

Before explaining, “What is Kubernetes?” it’s necessary to explain what it isn’t and outline what is not possible using Kubernetes.

Common Kubernetes Misconceptions

First off, I’d like to state that K8S (an alternate name for Kubernetes) is eight characters that are substituted with the number 8.

Kubernetes is not a replacement for Docker, AWS, or their alternatives. It’s a possible replacement for Docker Swarm, AWS ECS, or Mesos. All are orchestration tools. OR you can use two tools, Kubernetes and the other one.

It’s a tool for optimizing containerized workloads and services. In Kubernetes terms, a workload is an application running in Kubernetes. Such a requirement is rare in the SMB space. They typically use traditional and VM-based infrastructure solutions.

Kubernetes is easy to deploy. Yes, it is, but only for those with experience in containers and their environments (whether Docker, AWS, or other) Familiarity with Kubernetes’ tools, terminology and terminal-based commands (there is no GUI) is also necessary.

Using Kubernetes means no vendor lock-in. A true statement, but perhaps this is not true of another element in the container environment. Using Kubernetes will not eliminate vendor lock-in for other deployed solutions.

Kubernetes is competing with other solutions. Not true, as Docker, Azure, AWS and others all offer Kubernetes as part of their branded services. Its adoption rate continues to grow.

Now let’s delve into what Kubernetes can do for your containerized workload and services.

Why is Kubernetes Necessary?

In ye olde times, companies ran applications on physical servers. Many still do (me included) but I’ll ignore them for this article. In a traditional deployment, load balancing between applications is difficult and some could use up the majority of resources. Dedicating each application to its own server was expensive so , virtual machines became common, allowing allocation of resources per machine via a hypervisor. But each VM required an OS and individual software installs.

Finally, containers were an option, are similar to VMs but can share the OS. Containers have their own filesystem, CPU, memory, storage, etc. This makes them ‘portable’ allowing deployment across cloud and OS variations. Kubernetes sits on top of containers in the hierarchy and its name has Greek origins, meaning ‘helmsman’ or ‘pilot,’ presumably because it’s navigating the problems common to stable container deployment and related performance.

Commonly known as an orchestration tool, various analogies are attempted to reflect Kubernetes‘ role in terms of infrastructure. Most don’t work – conductors in an orchestra, for example, don’t work because when a conductor is removed, it’s without a significant impact on the entire orchestra. He/she conducts on a set workflow – the music. That’s not so with Kubernetes. I’m not even going to attempt an analogy. I was toying with the loaves and the fishes’ story from a well-known work of fiction but it only works for one aspect of Kubernetes – the creation of new containers as needed.

Let’s look at some of the areas Kubernetes is known for:

Load Balancing

If a container experiences high traffic, Kubernetes can balance and distribute traffic to other newly created containers if necessary.

Storage Orchestration

I’m not a big fan of orchestration as a term but management is the wrong word. It will allocate storage from other sources (physical or cloud-based) as needed.

Container States

If you have a new container update, rollouts take place in a controlled manner to avoid user downtime. It will ultimately remove existing containers when not in use and deployment in the new state. A phased rollout is the best term, I guess.

Self-healing

A major part of Kubernetes ‘ appeal is that it actively seeks to eliminate errors. It removes failed containers and replaces them with ones that pass a health check.

Sensitive Info

Passwords, keys, and tokens could be stored in Kubernetes. Updates take place without container rebuilds and most importantly, without revealing clues to your configuration.

As security is my bag (dated Austin Powers reference), I believe that any company considering new technology (including Kubernetes) must weigh the security risks involved and verify that any potential vulnerabilities are plugged before production rollout.

Finally, with this brief overview of Kubernetes completed, your eyes won’t glaze over the next time someone mentions it. If you want a more in-depth view, then have a look at the Kubernetes site, which offers a wide variety of resources, including tutorials. If you're going to delve into terminology that means something else in Kubernetes (node and workload, for example), there’s a glossary. Enjoy.