Overview of Kubernetes Components

Kubernetes Architecture and Components:

A Kubernetes cluster is made up of multiple individual components running on the various machines that are part of the cluster.

There are two types of components,

1. Master Components
2. Node Components

Master Components:

The below four Master components which combines together called as Control Plane.

1. ETCD
2. Kube-apiserver
3. Kube-control-manager
4. Kube-schdeduler

This control plane is responsible for making global decisions about the cluster and they detect and respond to cluster events.

Let’s discuss each individual components and what each of them do.

1. ETCD:

• It acts as cluster datastore.
• Provides consistent and highly available key-value store for persisting cluster state.
• It provides information like what pods, nodes are running in the cluster and much more.
• If you have multiple master nodes then ‘etcd’ will synchronise the data between them.
• If your Kubernetes cluster uses etcd as its backing store, make sure you have a safe back up plan for that data.
• You can easily back up your etcd data using the etcdctl snapshot save command. In case you are running Kubernetes on AWS, you can also back up etcd by taking a snapshot of the EBS volume.
• Etcdctl is the command-line interface tool written in Go that allows manipulating an etcd cluster. It can be used to perform a variety of actions, such as:

Set, update and remove keys.

Verify the cluster health.

Add or remove etcd nodes.

Generating database snapshots

• Etcd also implements a watch feature, which provides an event-based interface for asynchronously monitoring changes to keys. Once a key is changed, its “watchers” get notified. This is a crucial feature in the context of Kubernetes, as the API Server component heavily relies on this to get notified and call the appropriate business logic components to move the current state towards the desired state.

2. Kube-apiserver:

• When you are using kubectl command-line interface, you are actually communicating with Kube-apiserver.
• Kube-apiserver is used to process REST operations, validates them, and updates the corresponding objects in etcd
• The API Server is the only Kubernetes component that connects to etcd; all the other components must go through the API Server to work with the cluster state.
• The API Server contains watch mechanism in it(similar to etcd).
• This Watch feature allows components such as the Kube-Scheduler and Kube-Control-Manager to interact with the API Server and if there is any change in etcd, then it takes that changes and perform its tasks.

Example:

What happened when you create a POD ?

1. kubectl writes to the API Server.
2. API Server validates the request and persists it to etcd.
3. etcd notifies back the API Server.
4. API Server invokes the Scheduler.
5. Scheduler decides where to run the pod on and return that to the API Server.
6. API Server persists it to etcd.
7. etcd notifies back the API Server.
8. API Server invokes the Kubelet in the corresponding node.
9. Kubelet talks to the Docker daemon using the API over the Docker socket to create the container.
10. Kubelet updates the pod status to the API Server.
11. API Server persists the new state in etcd.

3. Kube-controller-manager:

• Kube-control-manager watches the state of the cluster through the API Server watch feature and, when it gets notified, it makes the necessary changes attempting to move the current state towards the desired state.
• In other words, the kube-control-manager watches the shared state of the cluster through the kube-apiserver and makes changes attempting to move the current state towards the desired state.

Example: It handles the node failure, Replicating the components, and maintaining the amount of pods, etc.

• The Kube-controller-manager is not just one service(controller), it includes many services(controllers) in it and we can enable them based on flags.
• To enable the controllers, use below flag parameter while configuring the clusters,

• So, all these services(controllers) acts a single process to reduce the complexity. Examples of controllers that ship with Kubernetes today are,

Node Controller: Responsible for noticing and responding when nodes go down.

Replication Controller: Responsible for maintaining the correct number of pods for every replication controller object in the system.

Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).

Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.

4. Kube-scheduler:

• The kube-scheduler schedules the newly created pods to nodes with enough space to satisfy the pod’s resource needs.
• It basically listens to the kube-apiserver and the kube-controller-manager for newly created pods and then schedule it to an available node on the cluster.
• The Scheduler watches for unscheduled pods and binds them to nodes by using the “/binding” pod subresource API.

Example: If the application needs 1GB of memory and 2 CPU cores, then the pods for that application will be scheduled on a node with at least those resources. The scheduler runs each time there is a need to schedule pods. The scheduler must know the total resources available as well as resources allocated to existing workloads on each node.

Node Components:

The node components are,

1. Kubelet
2. Kube-proxy
3. Container Runtime Interface(CRI)

1. Kubelet:

• Kubelet is an agent which runs on each node in the cluster(including master).
• The Kubelet reports to the kube API server.
• The kubelet service acts as a intermediate between the kube-apiserver and the CRI(Container Runtime Interface)
• Kubelet gets the pod specifications from kube-apiserver and ensures that, pods and their containers are healthy and running in the desired state.
• Kubelet is a service, not an POD.
• The kubelet uses the container runtime to start the pod, monitors its lifecycle, checks for the readiness, etc.

2. Kube-proxy:

• Kube-proxy handles the network traffic by allowing the communications between pods, containers, and nodes.
• Kube-proxy is a pod which runs on Master. If you have 2 client nodes then there will 2 kube-proxy pods running on the master in order to communicate with those nodes.
• Kube-proxy pod watches the kube-apiserver for changes and keeps the network up to date via iptables rules that forward traffic to the correct endpoints.

3. Container Runtime Interface:

• To launch the containers on the nodes we need container runtime software, we can use different container runtime, but widely used is docker.
• The kubelet will be talking to docker and will spin up or stop our containers on demand.
• Kubernetes supports several container runtimes: Docker, containerd,
  cri-o, rktlet.

That’s all Guys. Hope it helps to understand the high level view of Kubernetes components. Please refer the official Kubernetes documents to deep dive into each component.

Happy Learning!!!