The master node provides a running environment for the control plane responsible for managing the state of a Kubernetes cluster, and it is the brain behind all operations inside the cluster.
The control plane components are agents with very distinct roles in the cluster’s management.
In order to communicate with the Kubernetes cluster, users send requests to the master node via a Command Line Interface (CLI) tool, a Web User-Interface (Web UI) Dashboard, or Application Programming Interface (API).
It is important to keep the control plane running at all costs. Losing the control plane may introduce downtimes, causing service disruption to clients, with possible loss of business.
To ensure the control plane’s fault tolerance, master node replicas are added to the cluster, configured in High-Availability (HA) mode.
While only one of the master node replicas actively manages the cluster, the control plane components stay in sync across the master node replicas.
This type of configuration adds resiliency to the cluster’s control plane, should the active master node replica fail.
To persist the Kubernetes cluster’s state, all cluster configuration data is saved to etcd.
However, etcd is a distributed key-value store which only holds cluster state related data, no client workload data. etcd is configured on the master node (stacked) or on its dedicated host (external) to reduce the chances of data store loss by decoupling it from the control plane agents.
When stacked, HA master node replicas ensure etcd resiliency as well. Unfortunately, that is not the case of external etcds, when the etcd hosts have to be separately replicated for HA mode configuration.
Master Node Components
A master node has the following components:
- API server
- Controller managers
1 API Server
All the administrative tasks are coordinated by the kube-apiserver, a central control plane component running on the master node.
The API server intercepts RESTful calls from users, operators and external agents, then validates and processes them.
During processing the API server reads the Kubernetes cluster’s current state from the etcd, and after a call’s execution, the resulting state of the Kubernetes cluster is saved in the distributed key-value data store for persistence.
The API server is the only master plane component to talk to the etcd data store, both to read and to save Kubernetes cluster state information from/to it – acting as a middle-man interface for any other control plane agent requiring to access the cluster’s data store.
The API server is highly configurable and customizable.
It also supports the addition of custom API servers, when the primary API server becomes a proxy to all secondary custom API servers and routes all incoming RESTful calls to them based on custom defined rules.
The role of the kube-scheduler is to assign new objects, such as pods, to nodes. During the scheduling process, decisions are made based on current Kubernetes cluster state and new object’s requirements.
The scheduler obtains from etcd, via the API server, resource usage data for each worker node in the cluster. The scheduler also receives from the API server the new object’s requirements which are part of its configuration data.
Requirements may include constraints that users and operators set, such as scheduling work on a node labelled with disk==ssd key/value pair.
The scheduler also takes into account Quality of Service (QoS) requirements, data locality, affinity, anti-affinity, taints, toleration, etc.
The scheduler is highly configurable and customizable.
Additional custom schedulers are supported, then the object’s configuration data should include the name of the custom scheduler expected to make the scheduling decision for that particular object; if no such data is included, the default scheduler is selected instead.
A scheduler is extremely important and quite complex in a multi-node Kubernetes cluster. In a single-node Kubernetes cluster, such as the one explored later in this course, the scheduler’s job is quite simple.
3 Controller Manager
The controller managers are control plane components on the master node running controllers to regulate the state of the Kubernetes cluster.
Controllers are watch-loops continuously running and comparing the cluster’s desired state (provided by objects’ configuration data) with its current state (obtained from etcd data store via the API server).
In case of a mismatch corrective action is taken in the cluster until its current state matches the desired state.
The kube-controller-manager runs controllers responsible to act when nodes become unavailable, to ensure pod counts are as expected, to create endpoints, service accounts, and API access tokens.
The cloud-controller-manager runs controllers responsible to interact with the underlying infrastructure of a cloud provider when nodes become unavailable, to manage storage volumes when provided by a cloud service, and to manage load balancing and routing.
etcd is a distributed key-value data store used to persist a Kubernetes cluster’s state. New data is written to the data store only by appending to it, data is never replaced in the data store.
Obsolete data is compacted periodically to minimize the size of the data store.
Out of all the control plane components, only the API server is able to communicate with the etcd data store.
etcd’s CLI management tool provides backup, snapshot, and restore capabilities which come in handy especially for a single etcd instance Kubernetes cluster – common in Development and learning environments.
However, in Stage and Production environments, it is extremely important to replicate the data stores in HA mode, for cluster configuration data resiliency.
Some Kubernetes cluster bootstrapping tools, by default, provision stacked etcd master nodes, where the data store runs alongside and shares resources with the other control plane components on the same master node.
For datastore isolation from the control plane components, the bootstrapping process can be configured for an external etcd, where the data store is provisioned on a dedicated separate host, thus reducing the chances of an etcd failure.
Both stacked and external etcd configurations support HA configurations.
etcd is based on the Raft Consensus Algorithm which allows a collection of machines to work as a coherent group that can survive the failures of some of its members.
At any given time, one of the nodes in the group will be the master, and the rest of them will be the followers. Any node can be treated as a master.
etcd is written in the Go programming language. In Kubernetes, besides storing the cluster state, etcd is also used to store configuration details such as subnets, ConfigMaps, Secrets, etc.