Master Server

If pods and labels are virtual collections of containers and Kubernetes is the overlying management framework, the two spheres must somehow be linked. Google uses multiple components for linking Kubernetes with the containers.

The central hub of a Kubernetes installation is a master server. The master server consists of several components: A collection of APIs, a scheduler for pods, a controller for the user's server services, a database for configuring the cloud, and an authentication component on which all other services are oriented.

The APIs are the most outwardly visible parts: kubectl is the standard command for Kubernetes. You can use it to issue the platform commands directly. A kubectl call leads to a request to the Kubernetes API, which is based on the REST principle. The clients register with the authorization service in advance. The Kubernetes Info Service also provides information for Kubelet instances on the container hosts from the API Kubernetes.

Kubelet designates the service running as an agent on the hypervisors; it starts containers on demand. A separate scheduler in Kubernetes specifies which hypervisor should start a VM – the scheduling actuator forwards the information to the Kubernetes Info Services, where the Kubelet instances pick up their orders.

Integrated Replication

A component known as the controller manager, which manages a replication controller, can also be found on the master server in Kubernetes. This is – very much like the service – a label that expresses the dependencies between two pods. Replication controllers ensure horizontal scaling in Kubernetes: If a replication controller is defined for a pod, Kubernetes automatically starts new instances for each pod based on definable parameters – such as whether specific load limits are exceeded.

Finally, etcd is an integral component of the Kubernetes master. The service acts as a platform-wide key/value store for settings that are required on hypervisor nodes. Etcd is decentralized and automatically replicates its information on all instances of the installation so that all configuration options are available on each host on which etcd runs.

Working Remotely

Other services for Kubernetes also run on the hypervisor hosts, as well as the aforementioned Kubelet, such as networking. Kubernetes currently comes with a separate proxy component that centrally handles network access inside and outside the platform (Figure 2).

Figure 2: Kubernetes comes with a rather simple network setup out of the box. The developers are also working on integration with SDN solutions, such as Open vSwitch.

Whenever a pod needs to be reached, the process is currently handled by the proxy server configured by Kubernetes. However, this approach is anything but elegant and, if you want a genuine software-defined network (SDN) setup, the proxy server needs far more functionality. In any case, the rally to couple SDN approaches such as Open vSwitch with Kubernetes began some time ago, and such solutions are likely to prevail over the simple proxy approach in the long term.

Finally, of course, don't forget SaltStack, which Kubernetes uses internally. SaltStack is a tool for configuration management and clouds. In principle, it is very similar to other solutions, such as Puppet or Chef, but the manufacturers dubbed the product "optimized for the cloud." SaltStack supposedly offers massive benefits over other solutions, especially with scalable systems.

SaltStack has obviously had an effect on Kubernetes developers: Each Kubernetes hypervisor is considered a Minion, where "Minion" is the standard name in SaltStack-speak for a host that participates in configuration management through SaltStack.

Google – whether intentionally or not – staked out a specific claim for Kubernetes when deciding to use its own tool for maintaining and distributing configuration files. If a virtualization solution comes with its own management solution, it is no longer a small tool, but a full-blown environment.