etcd

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.

kube-scheduler

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.

kube-controller-manager

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.

Cloud-controller-manager

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

Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.

kubelet

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

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.

Container runtime

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.

Addons

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.

Source: Kubernetes

Source: Appvia