Kuberentes Architecture

Very Basic view of Kubernetes Architecture

In simple terms, Kubernetes system has a master node and cluster of worker nodes. Developer writes application definition (or) application descriptor file, which has information about containers, images, replicas, deployment strategies etc., and submit this file to the master node. Master node process this descriptor file and deploy the application on these cluster of worker nodes.

 

Master Node

Master Node is responsible for managing the entire Kubernetes System.

 

Worker Nodes

These are the nodes, where the application deploys.

 

Different components of Master Node

Kubernetes Master node owns ‘Kubernetes Control Plane’ which is responsible for controlling and managing of entire Kubernetes system.

Control Plane consists of the below components.

a.   API Server (Kube-apiserver)

b.   etcd

c.    kube-scheduler

d.   kube controller manager

e.   Cloud Controller Manager

 

Control Plane components can run on a single machine or can run on a cluster to achieve high availability. Control pane components talk to API Server and do not talk to each other directly.

 

API Server

It exposes the Kubernetes API and designed to scale horizontally. Using API server, you can configure data for API objects like Pods, Replication Sets, Deployments, Jobs, etc.,

 

etcd

It is a distributed key-value storage used by Kubernetes to persist the data. You can go through the below link to know more information about etcd.

https://etcd.io/docs/

 

kube-scheduler

It watches for new Pod requests and selects a node for them to run on. It considers multiple factors (individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines) for scheduling decisions.

 

Kube-Controller-Manager

This component is responsible to run Controller processes.

 

Following are the controller processes.

a.   Node Controller: Notice and respond when a node goes down

b.   Replication Controller: Responsible to maintain the desired number of Pods for every Replication controller object.

c.    Endpoints Controller: Populate Endpoint object (endpoint object joins services and Pods)

d.   Service Account and Token Controller: Create a default service account and API access tokens for namespaces.

 

Cloud Controller Manager

This component embeds cloud-specific control logic. It is used to link Kubernetes cluster into a specific Cloud Provider’s API.

 

Following controllers have Cloud Provider dependencies.

 

a.   Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding

b.   Route controller: For setting up routes in the underlying cloud infrastructure

c.    Service controller: For creating, updating and deleting cloud provider load balancers

 

How to check the status of Control Pane Components?

'kubectl get componentstatuses' command is used to get the status of Control Pane Components.

$kubectl get componentstatuses
NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok                  
controller-manager   Healthy   ok                  
etcd-0               Healthy   {"health":"true"}

Different Components of Worker Node

Worker Node has three components.

a.   kubelet

b.   kube-proxy

c.    Container Runtime

These components run on every worker node.

 

kubelet

Kubelet is an agent that runs on every worker node in the cluster. It talks and API Server and makes sure that containers running on a Pod.

 

kube-proxy

It is a network proxy that runs on every worker node in the cluster and load balance the network traffic between application components. It maintains network rules on the nodes, which allow network communication to your Pods from network sessions inside or outside of your cluster.

 

Container Runtime

It is responsible for running containers. It can be Docker, rkt, or any other container runtime.

 

Complete architecture looks like below.

How the process flow happen?

a. Create an Application Description file and submit it to Api Server. This description file contains  information about images, number of replicas, deployment strategy, volume mounts, secrets, how to expose these applications etc.,

 

b. Once the Api Server receives this description file, ‘Kube Scheduler’ look into these new Pod requests and select a node for them to run on.

 

c. ‘kubelet’ agent on the worker node gives an instruction to ‘Container Runtime’ to pull the image and start the containers.

 

d. When a user request for container logs, API server receives the request and send the request to kubelet which will get the logs.

 

Note

a. Will a master node run Pods?

No

Previous                                                    Next                                                    Home