An Idiot's Guide to Kubernetes: Of Cowboys and K8s

You may have heard people talking about Kubernetes.

“We’re using K8s”, they might have said nonchalantly, because they’re on nickname terms with this bit of open source technology; developed by Google and now increasingly underpinning a wealth of “cloud-native” computing applications.

You may have nodded approvingly and muttered something about “container orchestration”, while finding it more arcane than seventeenth century hermiticism; all cryptic codes and confusingly simple sounding utopianism (“run on any platform without any changes to the application code!”)

Nickname terms seem a long way away…

So, what on earth is Kubernetes anyway?

idiot's guide to kubernetes — Credit: Daniil Vnoutchkov

“It’s a cowboy”, says Paul Jones, Associate Partner at Citihub Consulting.

“Modern applications should be thought of like cattle, not pets. Kubernetes autonomously directs cattle to the right fields, replaces animals that are sick and provides the herd with the food and water it needs…

“No matter where it places a particular service, in short, it will ensure that the right network, storage, and configuration is made available.”

Like a cowboy, it likes to operate largely quasi-autonomously.

As Jones notes: “To use it, it’s best to be declarative – to describe the state you’d like to achieve, but not how it should be achieved. For example, you can tell Kubernetes that you’d like to have three instances of a service. If an instance dies, it will automatically create a new one in order to maintain the desired state. The same applies to storage and load balancers and other primitives that Kubernetes can control.”

The containers that Kubernetes are orchestrating, meanwhile, should be as small and free from dependencies as possible. As Synopsys CyRC’s Tim Mackey puts it: “They also should have no expectation of long life span – also known as having no expectation of being “Stateful”. These attributes are part of what makes an application “cloud native”, and cloud native applications are ideal for deployment within Kubernetes.”

n.b. Computer Business Review contacted various experts to help create this Idiot’s Guide to Kubernetes. For readers with short attention spans and limited appetite for zoological metaphors, their responses boiled down to this description: it’s an OS for container-based applications running in hybrid environments; it’s not as widely used in mission-critical environments as you would think; with off-the-shelf software vendors increasingly embracing container images as the standard unit of deployment for their applications, familiarising yourself with Kubernetes is a good investment.)

What is it gooooood for?

As Martin Percival, a solutions architect manager at Red Hat puts it: “’Kubernetes is the orchestrator of choice for containers’.

“So far so glib, but what does that actually mean both technically and for your business? What, even, is a container?

“At its most basic level a container is a piece of code which carries much of what it needs to run on its back, like a tortoise. That makes a container a uniquely portable item in a software architecture, able to be deployed across different machines without traditional worries about getting mismatches caused by the changing environments.

Dan Noguerol, a senior platform architect at Pivotal, makes the same point: emphasising that to understand why a business would use Kubernetes, you have to understand why they would use containers. He offers three reasons:

#1 “Microservice architectures that decompose applications into smaller, independent services have benefits that include greater reusability, more frequent release cycles and improved testing. Containers are lightweight and enable better utilisation of infrastructural resources. This makes them ideally suited for supporting microservices…

#2 “Certain workloads require elasticity: they must grow to support spikes in usage and shrink when idle. Containers, being lightweight and fast to start/stop, support elasticity requirements extremely well…

#3 “Runtime dependencies can be challenging to manage, especially in polyglot architectures. Containers encapsulate their runtime dependencies and provide isolation between application dependencies. Anyone that has had to manage multiple versions of Java or Node.js on a server will appreciate this benefit.”

How wide used is Kubernetes?

Brad Heller, Director of Engineering, Puppet is not alone in emphasising that while Kubernetes is maturing fast and increasingly widely used, adoption has (in reality) been a lot more gradual than people think.

He told Computer Business Review: “It seems to have been behaving similarly to the adoption of Docker.

“One of the biggest drivers for adoption has been the cloud providers’ distros that makes it trivial to stand up a Kubernetes cluster and get to work. [But] much of the adoption has been from new product development. Only the most forward-leaning companies are migrating existing workloads to Kubernetes.”

(These include Amadeus, Amdocs, Monzo, and Sky among others…)

How Challenging is it to Orchestrate this Orchestrator?

Decidedly difficult, comes the answer from many.

Yet as James Strachan, distinguished engineer, CloudBees says that regardless of the challenges, it’s rewarding: “Kubernetes is a pretty large and powerful platform; it takes a while to fully understand all of its ideas, concepts, features and tools.

“However learning about Kubernetes is very rewarding; by following the Kubernetes approaches (canonical REST APIs with versioning, controllers, feedback loops based on declarative metadata etc) it helps you learn how to build your own modern cloud native microservices… it’s pretty easy to get started deploying applications as a developer.”

Yet with an ecosystem still growing up around Kubernetes, and companies still exploring different ways to manage their emerging microservices, there are plenty of potential pitfalls (and ways to circumvent them).

Patrick Callaghan, an enterprise architect at DataStax notes one hurdle many businesses face: “The challenge with microservices is that it still creates data. You have to take data out of the application and use it somehow, either for powering other application functions or for storing and analysing over time.

“Either way, that data has to go somewhere.

“With applications being so distributed across multiple components, database deployments will also have to run in distributed environments too. There’s still a lot of work that is going on here around best practices.

He adds: “You can look at distributed data from a “per container or service” perspective – each container set will therefore store its data separately. That works, but it is hard to scale up and manage over time. Alternatively, you can centralise all the data that each of your microservices creates to one distributed database with as many nodes as required in one logical unit. For example this is what Monzo is doing with Cassandra, pulling 1,500 microservices’ data into its Apache Cassandra instance.

“The team can run this more efficiently than having multiple database instances all serving different container instances or microservices installations. That will be a common pattern for deployment at scale around microservices.”

What about security?

As Pivotal’s Noguerol puts it: “Application isolation requirements are an important aspect to consider here; default Kubernetes offers only a simple name-spacing mechanism that may not provide adequate workload isolation.

“To meet security requirements, one may need to either employ additional mechanism(s) to enforce isolation or consider running multiple Kubernetes clusters. The general consensus of the community seems to have gravitated towards the latter.

Tim Mackey, principal security Strategist for the Synopsys Cybersecurity Research Centre adds: “Often a container is developed without a full understanding of what security and compliance profiles the operations team might have.

“The perfect example of this are containers which expect to run as a ‘root’ user. A root user has the ability perform highly privileged operations on a system and novice container developers often use the elevated privileges of root as a workaround for explicitly stating the desired configuration.

“For example, a non-root user on a Linux system is prevented from binding to a low network port. If a container image exposes an HTTP service on port 80, then it implicitly expects to run as a root user and will fail to run on a secured Kubernetes system. When learning Kubernetes, one of the most important steps is to understand the security contexts available and how to identify when the security context could prevent something from running properly.

But Red Hat’s Martin Perceval says K8s is improving fast.

“Kubernetes has already grown to encompass new features which have made it a better container platform for enterprise software. Elements like security and advanced networking have been pulled into the main body of the upstream Kubernetes code, and are now available for everyone to use.

“It is, however, true that there will always be supplementary needs to cover other aspects of an enterprise solution; things like logging and performance monitoring. This is where secondary packages like Istio come into play, bringing extra functionality, but keeping the Kubernetes core to a reasonable size and set of features.

He adds: “Red Hat realised very early on that a naked Kubernetes does precisely nothing more than manage itself. It’s a bit like spinning up your favourite operating system and then never running anything on it. So in the very first version of OpenShift 3 (back in 2015), Red Hat added a development framework that made the creation and deployment of apps into Kubernetes very much easier no matter what level of approach you took, from just writing code and letting the system do the rest, all the way to deploying containers you built yourself. Since Google has now added similar features into Skaffold (GA Nov 7 2019) we will probably see more vendors adding a similar coding layer into their own approaches to Kubernetes.”

Kubernetes is free and open source. It can be downloaded from its Github repo. So should businesses be deploying it themselves, or relying on a third-party service provider? Perry Krug, Architect, office of the CTO at Couchbase, notes: “there’s much to be gained from using the expertise built into fully-managed Kubernetes layers. The benefits of doing it yourself are similar to any area: increased control and flexibility, at a lower cost. Yet this comes at a higher cost of knowledge and internal resources. You could make the same argument around managing your own datacentre or building out your own hardware – if it’s not your core competency, let someone else do it for you.”