Continuing with the Kubernetes entries, in this post, we will delve into the Kubernetes architecture and specifically explore how the Master Node operates.

Elements of a Kubernetes Architecture

In summary, Kubernetes consists of the following components:

• One or more Master Nodes.
• One or more Worker Nodes.
• A distributed key-value store, such as etcd.

Master Node

The Master Nodes provide an execution environment for the control plane, which manages the state of the Kubernetes cluster. It serves as the brain behind all cluster operations. The Control Plane components are agents with different roles in cluster management. Communication with the cluster can be done through the command-line interface, a user interface, or an API.

It is crucial to keep the Control Plane running at all times. Losing the Control Plane can introduce downtime, causing service disruptions to clients and potential business losses. To ensure fault tolerance of the Control Plane, multiple replicas of the Master Node are added to the cluster, configured in a high-availability (HA) mode. While only one of the Master Node replicas actively manages the cluster, the Control Plane components remain synchronized across the Master Node replicas. This configuration adds resilience to the cluster’s Control Plane in case the active Master Node replica fails.

Etcd always knows and stores the state of the Kubernetes cluster.

Etcd is a key-value store that maintains information related to the cluster’s state. The configuration is done on the Master Node, and it communicates through the API Server. Configuring it in an externalized manner is also possible, but in such cases, resilience is not guaranteed unless the Master Nodes are in HA mode.

Master Node Components

Api Server

The Kube-apiserver, a Control Plane component, coordinates all task management and runs on the Master Node. The API Server intercepts REST calls from users, operators, and external agents, validates and processes them. During this processing, the API server reads the state of the Kubernetes cluster, stored in etcd, and subsequently updates this information back to etcd. This component is the only one that can communicate with etcd.

Scheduler

The Kube Scheduler is responsible for assigning new objects, such as pods, to nodes. It receives requirements for the new object from the API Server as part of its configuration data, which may include usage constraints or quotas, data placement, fault tolerance systems, etc.

Managers Controller

The Controller Managers are Control Plane components that regulate the state of the Kubernetes cluster. They continuously run a loop that compares the existing state with the desired state. If the states do not match, corrective actions are taken.

The kube-controller-manager executes controllers responsible for acting when nodes become unavailable, ensuring the expected number of pods, creating endpoints, service accounts, and access tokens to APIs.

The cloud-controller-manager manages cloud infrastructure, including storage, load balancing, and routing, when nodes are unavailable.

Etcd

Kubernetes uses Etcd as a distributed key-value data store to persist its state. New data (state) is store by adding a new record; it is never replaced or updated. Values are periodically compacted to minimize disk space usage. Etcd can only be accessed through the API Server.

Etcd CLI allows backup and restore in learning and development, valuable for single K8s cluster environments. However, for production environments, it is crucial to have replicas in HA mode.

Some Kubernetes cluster bootstrapping tools, by default, provide etcd master nodes, where the data store runs alongside and shares resources with other Control Plane components on the same Master Node. To isolate etcd, configure it externally. However, ensure high availability (HA) configuration for reliable operation with Control Plane components.

As a curiosity, etcd is based on the Raft consensus algorithm, which means that a collection of machines work as a coherent group that can survive the failures of some of its members. In Kubernetes, at any given time, you can treat any node as a master, while the rest of the nodes act as followers. The developers wrote Etcd in Go, and although its primary purpose in K8s is to store state, it can also store configurations, ConfigMaps, Secrets, etc., as we will explore later.

Conclusion

In this post, we have seen how the Master Node works in a Kubernetes architecture, as well as its various components. In the next post, we will delve into the various components of the Worker Node.