CloudNativeCon and KubeCon Europe 2017: an overview

CloudNativeCon and KubeCon Europe 2017 took place in Berlin on March 29th and 30th, and they were packed with clever things you can do in, around, and on top of, Kubernetes. It is possible that not every reader of LWN is familiar with Kubernetes, so I'd like to give a brief description of it before I describe any of the talks that I heard there. To do that, I'll have to at least mention tools, containerization, cloud-native computing and microservices, and the Cloud Native Computing Foundation (CNCF).

Containers are an elegant way to combine two Linux primitives, control groups and and namespaces, with loopback filesystems to provide isolated structures that in many ways resemble virtual machines (VMs), though they don't have their own kernels. It is important to remember, however, that they are not actually VMs; no less an authority than Jessie Frazelle, who maintained Docker and now hacks on containers for Google when not speaking at KubeCon 2017, says exactly that in her blog. If you treat your containers like VMs, you're using them wrong, and things may not end well if you do that in production.

Tools like Docker and rkt automate the deployment of applications inside containers; Docker has the larger mindshare, but rkt is growing as well. I'll focus mostly on Docker here. It uses some elegant union filesystem magic to allow many containers to run inside many copies of the same file space, each seeing only its own version, without the host having to maintain many separate copies of the filesystem. It also prefers to only allow one process to run inside any given container. This last has given rise to the idea of the microservice: a single process, running inside its own container, doing exactly one thing well. Hook many microservices together, usually with some kind of persistent off-container data store, and you can build complex and clever applications.

Docker exploded into the world in 2013, instantly becoming beloved of developers. As a systems administrator, I've felt the resource and time pain of maintaining lots of individual copies of a production environment so that developers could work in their own sandboxes. A tool that allows each of them to spin up many such copies using amazingly little memory and disk space to do so is indeed a big win. But I will put my cards on the table here and say that the ways developers have deployed containers into production are often not ideal from a reliability and maintainability standpoint. The deep nesting of containers and the profusion of embedded distributions that results has led one commentator to write:

Containers should be ephemeral. To be production-ready, they should be able to be rebuilt from clean, trusted sources at the slightest provocation, without any interruption to your production services. What containerization needs for this is infrastructure which understands this ephemerality and the idea of microservices, and holds tight to those concepts to allow rapid deployment of containerized microservices into production as part of an orderly development and testing chain. Once you build your business applications around this sort of architecture, you're doing what the attendees called "cloud-native computing".

Kubernetes, which the majority of speakers at KubeCon 2017 pronounced to rhyme with "goober gettys", is such a tool. It's not the only one, but it seems to be gaining a lot of ground, probably because it came out of Google. But it now belongs to the CNCF, which is part of the Linux Foundation, and which maintains a toolchain of cloud-native computing tools, principal amongst which is Kubernetes.

Finally, before I can describe some of the talks I heard at CNC/KubeCon, a few Kubernetes-specific concepts must briefly be mentioned. The node is the basic unit of computing power given to a Kubernetes deployment; it comprises a server with some memory, disk, and CPU, which is given over to Kubernetes to manage. The pod is the basic unit of microservice deployment, and comprises one or more dockerized containers running on the same node. A service is a set of similar pods, usually on different nodes, that together provide one tier of a multi-tier application. The Kubernetes master gets your microservices out to pods on its nodes, checks they're happy, and ensures that pods and services can all find each other so they can work together to provide your business application.

Hopefully, that seems simple. As a number of people at CNC/KubeCon were willing to say, the really painful bit for most people is making their business applications cloud-native. Once that pain, which can be considerable, is absorbed, the benefits can be substantial. The business application can run in-house or in any cloud, managed by Kubernetes, with very little transitional pain. Scaling becomes fairly painless; have Kubernetes deploy more pods, and if you're running in-house, feed more nodes to Kubernetes when it needs them.

Now let's see how this works out in practice.

[Thanks to the Linux Foundation, LWN's travel sponsor, for assistance in getting to Berlin for CNC and KubeCon.]

Index entries for this article
GuestArticles	Yates, Tom
Conference	CloudNativeCon+KubeCon/2017

---

to post comments