DEV Community

Cover image for Kubernetes Components and Architecture
Gitlab Meetup Community
Gitlab Meetup Community

Posted on

Kubernetes Components and Architecture

Most of us are well aware that Kubernetes is a 'Container Orchestration Tool'. Naturally, it shoulders the responsibility of learning Kubernetes components and architecture, adhering to its working. This open-source platform that deploys and manages the containers is of great help during your productivity that is economical and undoubtedly a future proof solution. But how does the architecture help in achieving all these goals?

To make our understanding better, let us consider an analogy for the Kubernetes - "The Kubernetes Kingdom"!

Alt Text

Feel like catching a fleeting glance of Kube? Then you ought to check his out.

As we are all aware, the purpose of using Kube is to host your application in the form of containers to automatically deploy your application's instances as many as you require. Here in the Kube Kingdom follows the working principle according to the 'Master-Slave Architecture'. On the Slave side, we have the hard-working Labourers and the monitoring Supervisors forming the Worker Nodes which deploy the applications and carrying the containers with the consent of the Master node.

On the other side of the architecture, we have the King playing the role of master, who guides and is the prime decision-maker for all the deployments. The Master node manages the Kubernetes cluster concerning different nodes and the destination of the containers. Let's get into the detail of the components of the master node.

  • kube-apiserver: This API Server plays the role of Chief Minister who primarily is the component that manages and establishes communication among all the elements in the Master node. The kube-apiserver is responsible for operational orchestration of all the components. Exposing the Kubernetes API, kube-apiserver is the frontend of Kubernetes control plane, thus managing and deploying more instances.

  • etcd: As a Chief Administrator in the kingdom etcd holds the back-up(database) of all the cluster data in the form of Key-Value pairs. They're highly consistent and maintain even the smallest data of the worker nodes.

  • Kube-scheduler: The kube-scheduler guides the juvenile pods to its new node to run them, thus qualifying to be a Manager for the Supervisors. It schedules the pods considering the availability of the space, its destination and the capacity.

  • Control Manager: Now since we have a Kingdom, we are bound to have different Provincial Administrators, which in this case are: Node Controller, Replication Controller, Endpoint Controller and Service Account & Token controllers. Though logically different, they run as a single process.

  • Kubelet: Kublet works as a Secretary who directly report to the Chief-Minister-kube apiserver. It runs on the node of every cluster monitoring the cluster's functionality on every pod.

Takeaway notice points:

  • A network proxy called kube-proxy works on every node of your cluster that executes Kubernetes Service Concept.
  • The software responsible for running the containers is Dockers. A few other container runtime software is CRI-O and Containerd.
  • Looking out for Kube Cheatsheet? Check out this blog
Alt Text Alt Text Alt Text Alt Text
Alt Text

Top comments (0)