Under the hood

Now we have learned a little about the functionality that Kubernetes provides to us, the user, let's go a little deeper and look at the components that Kubernetes uses to implement these features. Kubernetes makes this task a little easier for us by having a microservice architecture, so we can look at the function of each component in a certain degree of isolation.

We will get our hands dirty over the next few chapters by actually deploying and configuring these components ourselves. However for now, let's start by getting a basic understanding of the function of each of these components by looking at the following diagram:

The main Kubernetes components on the master node

API server

The API server acts as Kubernetes' central hub. All the other components in Kubernetes communicate by reading, watching, and updating resources in Kubernetes APIs. This central component is used for all of the access and manipulation of information about the current state of the cluster, allowing Kubernetes to be extended and augmented with new features while still maintaining a high degree of consistency.

Kubernetes uses etcd to store the current state of the cluster. An etcd store is used because its design means that it is both resistant to failure and has strong guarantees of its consistency. However, the different components that make up Kubernetes never directly interact with etcd; instead, they communicate with the API server. This is a good design for us, the operator of a cluster, because it allows us to restrict access to etcd only to the API server component, improving security and simplifying management.

While the API server is the component in the Kubernetes architecture that everything else communicates with to access or update the state, it is stateless itself, with all storage being deferred to the backing etcd cluster. This again is an ideal design decision for us as cluster operators since it allows us to deploy multiple instances of the API server (if we wish) to provide high availability.

Controller manager

The controller manager is the service that runs the core control loops (or controllers) that implement some of core functionality that makes Kubernetes function. Each of these controllers watches the state of the cluster through the API server and then makes changes to try and move the state of the cluster closer to the desired state. The design of the controller manager means that only one instance of it should be running at a given time; however, to simplify deployment in a high-availability configuration, the controller manager has a built-in leader election functionality, so that several instances can be deployed side by side, but only one will actually carry out work at any one time.

Scheduler

The scheduler is perhaps the single most important component that makes Kubernetes a useful and practical tool. It watches for new pods in the unscheduled state, and then analyzes the current state of the cluster with regard to running workloads, available resources, and other policy-based issues. It then decides the best place for that pod to be run in. As with the controller manager, a single instance of the scheduler works at any one time, but in a high-availability configuration, leader election is available.

Kubelet

The kubelet is the agent that runs on each node, and is responsible for launching pods. It doesn't directly run containers but instead controls a runtime, such as Docker or rkt. Typically, the kubelet watches the API server to discover which pods have been scheduled on its node.

The kubelet operates at the level of PodSpec, so it only knows how to launch pods. Any of the higher-level concepts in the Kubernetes API are implemented by controllers that ultimately create or destroy pods with a specific configuration.

The kubelet also runs a tool called cadvisior that collects metrics about resource usage on the node, and using each container that is running on the node, this information can then be used by Kubernetes when making scheduling decisions.