Kubernetes Architecture Explained ☸️ : Day 5 of 40daysofkubernetes

Kubernetes Architecture Explained ☸️ : Day 5 of 40daysofkubernetes

Introduction:

In my previous blog, we explored the problems with using standalone containers and how Kubernetes solves these issues. In this blog, we will dive into the architecture of Kubernetes, its components, and how it works. Let's get started!

Kubernetes Architecture

A Kubernetes cluster consists of two main components: the Control Plane (Master Node) and Node (Worker Nodes) . The Control Plane manages the Worker Nodes and the Pods in the cluster, while the Worker Nodes host the Pods that are the components of the application workload.

In production environments, the Control Plane usually runs across multiple machines, and a cluster typically runs multiple nodes, providing fault tolerance and high availability.

Note: A node can be a virtual or physical machine, depending on the cluster configuration.

Control Plane Components

  1. kube-apiserver:

    The API server is a key component of the Kubernetes Control Plane that exposes the Kubernetes API. It acts as the initial gateway to the cluster, listening for updates or queries via CLI tools like kubectl. The kubectl tool communicates with the API Server to perform actions like creating or deleting Pods. The API Server validates requests and then forwards them to other processes. All requests to the cluster must pass through the API Server.

  2. etcd:

    etcd is the key-value store for the cluster. It stores all cluster state data and acts as the cluster's brain, informing the Scheduler and other processes about resource availability and state changes.

  3. kube-Scheduler:

    The Scheduler assigns Pods to nodes. When the API Server receives a request to schedule Pods, it passes this request to the Scheduler, which decides the most efficient node for each Pod.

  4. kube-control-manager:

    This component runs various controllers that handle the cluster's control loop. Examples include:

    • Node Controller: Manages node status and response when nodes go down.

    • Job Controller: Manages Job objects that represent one-off tasks, creating Pods to run these tasks to completion.

    • EndpointSlice Controller: Links Services and Pods via EndpointSlice objects.

    • ServiceAccount Controller: Creates default ServiceAccounts for new namespaces.

  5. cloud-control-manager

    This component embeds cloud-specific control logic, allowing the cluster to interact with the cloud provider's API. It separates components that interact with the cloud platform from those that only interact with the cluster. If running Kubernetes on-premises or in a local environment, the cluster does not have a cloud-controller-manager.

Node Component

  1. kublet:

    The kubelet interacts with both the container runtime and the node. It is responsible for starting Pods with containers inside them.

  2. kube-proxy:

    kube-proxy manages network routing for forwarding requests from Services to Pods. It uses intelligent routing logic to direct requests to the appropriate Pod on the worker node.

  3. container runtime:

    The container runtime is crucial for running containers within Kubernetes. It manages the execution and lifecycle of containers in the Kubernetes environment.

What is a Pod in Kubernetes?

In Kubernetes, a Pod is the basic unit of deployment. When you create a Deployment or a Job, you are actually creating Pods. Pods can contain multiple containers that share resources like network and storage. These containers within a Pod share the same network namespace (IP address) and can communicate with each other using localhost.

Pods have their own lifecycle, and Kubernetes manages the scheduling, scaling, and lifecycle of Pods. Pods can be created, replicated, and scheduled on nodes within the Kubernetes cluster.

End-to-End Flow: Running a kubectl Command

  1. User Input (kubectl Command Execution)

    • The user types a kubectl command in the terminal (e.g., kubectl get pods).

    • kubectl is a command-line tool that interacts with the Kubernetes API server.

  2. kubectl Client Initialization

    • kubectl reads the configuration from the kubeconfig file, which contains information about the clusters, contexts, users, and namespaces.

    • It authenticates the user using the credentials specified in the kubeconfig file.

  3. API Request Creation

    • Based on the command, kubectl constructs an HTTP request to be sent to the Kubernetes API server.

    • This request includes the method (GET, POST, DELETE, etc.), URL, headers, and any necessary data payload.

  4. API Request Transmission

    • kubectl sends the HTTP request to the Kubernetes API server endpoint.

    • The request travels over the network to reach the API server.

  5. API Server Authentication and Authorization

    • The API server receives the request and authenticates it using the provided credentials.

    • The API server then checks if the authenticated user is authorized to perform the requested action (e.g., list pods in a namespace).

  6. Admission Control

    • The API server processes the request through a series of admission controllers that validate and potentially mutate the request.

    • Admission controllers enforce policies such as resource quotas, security policies, and more.

  7. Request Processing

    • The API server processes the request and interacts with the etcd datastore if necessary to read or write cluster state information.

    • For a GET request (e.g., kubectl get pods), the API server retrieves the requested information from etcd.

  8. Response Transmission

    • The API server sends the HTTP response back to the kubectl client.

    • The response contains the requested data or an error message if the request failed.

  9. kubectl Client Response Handling

    • kubectl receives the response from the API server.

    • It parses the response and formats the output according to the command options (e.g., table, JSON, YAML).

  10. User Output

    • kubectl displays the formatted output to the user in the terminal.

    • The user can see the result of their command, such as a list of pods or details of a specific resource.

Thank you for reading!

Resources I used:

Video-

Docs:

https://kubernetes.io/docs/concepts/overview/components/

https://www.geeksforgeeks.org/kubernetes-architecture/#kubernetes-components