Kubernetes Architecture Terminology in a 3 min read. Professional Friendly.

Kubernetes Architecture Terminology in a 3 min read. Professional Friendly.

MICROBLOG Lessons on Kubernetes. This blog gives a clear understanding of Kubernetes architecture. If you have read the architecture multiple times and still feel lost, here is where you get a bang on it.

Firstly, Kubernetes has a Master-Slave architecture. As in the name, master controls the slave machines. Slave machines perform the task assigned by the Master.

Any cluster in Kubernetes consists of a master machine and a set of worker machines (can be any number, but mandatorily one), these worker machines are shortly called?nodes.

Nodes?contain?Pods,?

Pods?contain?containerized applications?in them.?

The end goal in Kubernetes is to create?POD. Pods are the smallest deployable units of computing that you can create and manage in Kubernetes. Let’s understand the communication between the master node & worker node in order to create a POD — high level.

Below are the Master node components:

No alt text provided for this image


API Server

The?API Server?is the front-end of the control plane and the only component in the control plane that we interact with directly. Internal system components, as well as external user components, all communicate via the same API.

All the?get?commands are fetched from etcd.

All?create?commands go through API server → Scheduler → Worker node → Kubelet.

Key-Value Store (etcd)

The Key-Value Store, also called?etcd, is a database Kubernetes uses to back up all cluster data. It stores the entire configuration and state of the cluster. The Master node queries?etcd?to retrieve parameters for the state of the nodes, pods, and containers.

Controller

The role of the?Controller?is to obtain the desired state from the API Server. It checks the current state of the nodes it is tasked to control, determines if there are any differences, and resolves them if any.

Scheduler

A?Scheduler?watches for new requests coming from the API Server and assigns them to healthy nodes. It ranks the quality of the nodes and deploys pods to the best-suited node. If there are no suitable nodes, the pods are put in a pending state until such a node appears. The scheduler constantly communicates to the API server.

Hope that was helpful, I’ll come up with worker node architecture in my next microblogs of Learning Kubernetes in a fun and easy way.

-Jaswi

Ricardo Ribeiro

Software Developer

1 年

Good explanation?

回复

要查看或添加评论,请登录

Thejaswi B.的更多文章

社区洞察

其他会员也浏览了