Old Friends: Namespaces

Pods are characterized by several features on the server side. First, a pod slips several Linux namespaces, which all pod containers can then access, over the containers running in it. Remember that namespaces are a feature in the Linux kernel that sets up virtual sections in various areas, such as the network or process level. Applications that run within a namespace cannot just leave it but are virtually locked into it.

A pod's containers therefore have access to the same virtual stack for the network and its processes. Moreover, they share a hostname. Kubernetes also supports interprocess communication. It almost seems as if Google does not even regard Docker containers in a pod as containers, but instead as single programs.

This design fits well with the manufacturer's statement that Kubernetes is, in reality, application specific. Google clarifies that it may be possible to have multiple containers in a pod, but that each container within the environment performs precisely one specific task and, ideally, only runs a single application. Anyone wanting to host more than one application is, therefore, obliged to fit out their pod with more containers as early as pod definition time.

Group Hug

The applications that are part of a pod are stored on the same host. Anyone thinking about the topics of high availability and redundancy might be perplexed here. Google has, however, indicated that pods are actually ephemeral (i.e., not designed to exist permanently). The idea regularly created a stir in the past few years in the context of the cloud, because it apparently conflicts with the mantra of high availability.

In fact, this concept achieves the same goal, but just in another way: Instead of individual, highly specific hosts, there are many generic systems that can be reproduced quickly in a worst-case situation. Specific data is not impossible, but it must be connected separately. Google views pods in Kubernetes along the same lines: Persistence might be possible via specifically bound storage, but this only applies to the specific data.

The pods and the associated applications are replaceable at any time. Kubernetes therefore lacks any kind of functionality for moving VMs: Instead of migrating, the same pod is simply started again on another host, and the same persistent storage is then connected to it.

Labels

In addition to the pods, Kubernetes also gives administrators an option for expressing a relation existing between pods. Pods offering similar services could be linked to a logical unit using a service label at the Kubernetes level. Labels mainly offer administrative benefits. By using them, you can express the fact that three different pods contain applications that talk to one another in the background.

A Galera cluster with MySQL is a typical example: You'll need at least three pods with a Galera application. Using a corresponding label selector, you can ensure that Kubernetes recognizes the pods as belonging together and ensures sound network throughput performance between the pods.