Two weeks ago, at the OpenInfra Summit in Berlin we had a lot of talks about Kubernetes and the components from which it is setup. Fairbanks supports teams working with Kubernetes and I thought it might be a good idea to do a short recap on all the components.
Kubernetes consists of several components. At a base level, a Kubernetes cluster is made up of a control plane (master), distributed storage system for keeping the cluster state consistent (etcd) and a group of cluster nodes (workers). In this blog, we will outline the various components for you and explain what makes Kubernetes architecture.
Control Plane Components
The control plane’s components make global decisions about the cluster, as well as detect and responding to cluster events. As the control plane handles most of Kubernetes’ ‘decision making’, nodes which have these components running, generally don’t have any user containers running. These are normally named as master nodes.
The kube-apiserver is a component of the Kubernetes control plane that exposes the Kubernetes API. In other words: The Kubernetes API server validates and configures data for the API objects which include pods, services, replication controllers, and others. The API Server services REST operations and provides the frontend to the cluster’s shared state through which all other components interact. The API server is the front end for the Kubernetes control plane. kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances.
etcd is a distributed key-value store and the primary datastore of Kubernetes. It stores and replicates the Kubernetes cluster state.
The name “etcd” originated from two ideas, the unix “/etc” folder and “d”istributed systems. The “/etc” folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a “d”istributed “/etc” is “etcd”.
etcd is designed as a general substrate for large scale distributed systems. These are systems that will never tolerate split-brain operation and are willing to sacrifice availability to achieve this end. etcd stores metadata in a consistent and fault-tolerant way. An etcd cluster is meant to provide key-value storage with best of class stability, reliability, scalability and performance.
This is a control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on. Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware / software / policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.
The Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and service accounts controller.
This is a Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider’s API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.
As with the kube-controller-manager, the cloud-controller-manager combines several logically independent control loops into a single binary that you run as a single process. You can scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
Kubelet is an agent that runs on each node in the cluster. It makes sure that containers are running in a Pod. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes.
Other than from a PodSpec from the apiserver, there are three ways that a container manifest can be provided to the Kubelet.
- File: Path passed as a flag on the command line. Files under this path will be monitored periodically for updates. The monitoring period is 20s by default and is configurable via a flag.
- HTTP endpoint: HTTP endpoint passed as a parameter on the command line. This endpoint is checked every 20 seconds (also configurable with a flag).
- HTTP server: The kubelet can also listen for HTTP and respond to a simple API (underspec’d currently) to submit a new manifest.
kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept. kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.
The container runtime is the component that is responsible for running containers. Kubernetes supports container runtimes such as containerd, CRI-O, Docker Engine or Mirantis Container Runtime. You need to install a container runtime into each node in the cluster so that Pods can run there.
Then there are many addons for Kubernetes. Addons use Kubernetes resources such as DaemonSet and Deployment to implement cluster features.
Examples of the most used addons are ‘Networking and Network Policy’ addons, ‘Service Discovery’ addons, ‘Virtualization and Control’ addons and ‘Infrastructure’ addons like KubeVirt to run virtual machines on Kubernetes which is usually used on bare-metal clusters.
Also, some legacy addons are available; these can be found on the Kubernetes GitHub page.
There you have it, some of the most important components that make a Kubernetes cluster. We hope this quick outline helps you! At Fairbanks and 42on we love open source and Kubernetes; we help out teams with the support of Kubernetes clusters, whether they still need to be setup or complex problems and questions about the architecture or the integration with applications.
Have we missed an important component that you are using within Kubernetes? Let us know in the comments.