Container-based virtualization has several advantages over classical virtualization tools such as KVM or Xen. Containers allow a higher packing density: A container is initially no more than a directory within a Linux system that shares the host's resources, comprising only the components needed for the container and stressing the CPU only as needed by the services within the container.

In Its Sights for Years

Google has focused on container virtualization for years. The need for efficient management tools is particularly high at Google, which operates so large an infrastructure that even the smallest performance gains quickly translate into big savings.

Google generally allows the open source community to participate in testing and developing its products; against this background, the company published the first public version of Kubernetes [1] in 2014. Behind the somewhat unwieldy name, you will find Google's own Linux distribution, specifically geared toward operating Docker containers and extending Docker [2] to include many useful functions for large computing networks. SUSE and Red Hat now also participate in Kubernetes' development.

How does Kubernetes fare in a market in which CoreOS and various other container-friendly systems are already active?

The Problem

Google has to unite countless systems worldwide to form a single computing environment and ensure that servers can be managed well remotely. Kubernetes is Google's approach to making Docker enterprise-ready (Figure 1). The Kubernetes solution is designed to leverage the benefits of large-scale computing environments.

Figure 1: Docker can only use containers on the local host out of the box. Kubernetes is designed to expand the tool for fleet capacity.

Kubernetes has competitors: CoreOS [3] and Red Hat's Atomic project [4] have similar goals. Kubernetes, however, occupies a special position in the ranks of fleet virtualizers with container technology. It follows a superordinate goal and seeks to be a universal solution because it does not rely on any specific distribution and is not developed directly by a distributor. This distributor independence is reflected in the fact that Kubernetes works the same way on Red Hat as it does on Ubuntu.

Docker is networked out of the box and is designed to manage containers. Kubernetes aims to extend Docker to add fleet capacity, so Google has introduced several technical terms in its design documents to explain the capabilities of Kubernetes. The following sections describe some of those important terms and concepts.

Pods

A pod is the smallest administrative unit in which Google's Kubernetes operates. In its documentation, Google always talks about applications and not containers. Even if a user only launches a single container, Kubernetes builds a wrapper pod around it. However, Google actually views pods as a management option for thousands of containers.

In the Kubernetes universe, pods take care of orchestration. You can write text files to define pods; possible formats include YAML or JSON. The pod definition contains all the relevant details: Which containers should the pod include? Which operating systems use them? What specific services will run within the pods? Once a suitable file for starting the pod has been created, you send it to Kubernetes, which ensures in the background that the containers start as desired.