Kubernetes Architecture -In-Depth

If you haven’t visited the basic overview of Kubernetes Architecture, click here

• A Kubernetes cluster consists of a set of worker machines, called nodes, that runs containerized applications.
• Kubernetes is an open-source orchestration tool developed by Google for managing microservices or containerized applications.
• Kubernetes provides a highly resilient infrastructure with zero downtime deployment capabilities, automatic rollback, scaling, and self-healing of containers.

Kubernetes Control Plane Components

Below are the main components found on the master node:

Kube API server

• The API server is a component of the Kubernetes control plane that exposes the Kubernetes API.
• Kubernetes API server is the central management entity that receives all requests for modifications of pods, services, replication controllers, deployments, etc.
• The API server is the front end of the Kubernetes control plane.
• This is the only component that communicates with the etcd cluster.

ETCD

• ETCD is a simple, distributed key-value storage that is used to store the Kubernetes cluster data (such as a number of pods, their state, namespace, etc).
• It is only accessible from the API server for security reasons.
• ETCD enables notifications to the cluster about configuration changes with the help of watchers.
• Notifications are API requests on each etcd cluster node to trigger the update of information in the node’s storage.

Kube Controller Manager

• Controllers take care of actually running the cluster, and the Kubernetes controller-manager contains several controller functions in one.
• Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary known as Kube-controller-manager.

Some types of these controllers are:

• Replication controller: Ensures the correct number of pods is in existence for each replicated pod running in the cluster.
• Node Controller: Monitors the health of each node and notifies the cluster when nodes come online or become unresponsive.
• Endpoints controller: Connects Pods and Services to populate the Endpoints object.
• Service Account and Token controllers: Allocates API access tokens and default accounts to new namespaces in the cluster.

Kube Scheduler

• The scheduler is responsible to schedule pods in different nodes based on resource utilization.
• It reads the service’s operational requirements and schedules it on the best fit node.
• For 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.

Kubernetes Worker Components

Kubelet

• It is a Kubernetes agent that runs on each node in the cluster that communicates with the control plane.
• The kubelet takes a set of PodSpecs that are provided by the API server and ensures that the containers described in those PodSpecs are running and healthy.
• This component also reports about the state and health of the containers.

Kube Proxy

• Kube-proxy is a network proxy that runs on each node in your cluster.
• Kube-proxy maintains network rules on nodes.
• It also maintains network rules, allows network communication between services and pods, and is responsible for routing network traffic.
• The Kube-proxy handles network communications inside or outside of your cluster.

Container Runtime Interface

• A container runtime, also known as a container engine, is a software component that is responsible for running containers.
• The kubelet communicates with the container engine through the standard Container Runtime Interface and pulls the docker image from the docker hub.
• Kubernetes also supports container runtimes such as containerd, CRI-O, and any other implementation of the Kubernetes CRI.

How does Kubernetes work?

To understand the flow, we will take an example of Nginx pod deployment.

• A user writes a YAML file for pod specification and submits it to the API server, the API server will check for the authentication of that user, and whether the user is authorized to perform the requested actions or not.
• Once the user validation is passed, the API server will store all the data related to pods and their specifications in the ETCD cluster.
• The schedule continuously watches the new request from the API server and once it gets the request from the API server, the scheduler finds the appropriate healthy worker nodes that match the requirement.
• The kubelet further communicates with the container engine through the standard Container Runtime Interface and pulls the docker image from the Docker hub and deploys the pods.
• Controllers watch and monitor the deployed pods and in case of any failure, it reports to the API server.

Also, check

Kubernetes Tutorials