Kubernetes Architecture

Kubernetes Architecture Explained

This document explains the key components that make up the architecture of a Kubernetes cluster, in simple terms.

Table of Contents

⦁ Control Plane (Master Node Components)

⦁ Worker Node Components

⦁ Other Components

Kubernetes Architecture Diagram

Control Plane (Master Node Components)

API Server

⦁ This is the "front desk" of Kubernetes. Whenever you want to interact with your cluster, your request goes through the API Server. It validates and processes these requests to the backend components.

⦁ All commands from users or tools (like kubectl) go through the API server.

⦁ Example: Admins deploy a new "Product Catalog" service through the API server.

etcd

⦁ Think of this as the "database" of Kubernetes. It stores all the information about your cluster—what nodes are part of the cluster, what pods are running, what their statuses are, and more.

⦁ Keeps track of service discovery data, such as which node hosts the "Payment Gateway" pod.

Scheduler

⦁ The "event planner" for your containers. When you ask for a container to be run, the Scheduler decides which machine (Node) in your cluster should run it. It considers resource availability and other constraints while making this decision.

⦁ Assigns pods (containers) to worker nodes based on resource availability.

⦁ If the "Search Service" pod requires high memory, the scheduler places it on a node with sufficient RAM.

Controller Manager

⦁ Imagine a bunch of small robots that continuously monitor the cluster to make sure everything is running smoothly. If something goes wrong (e.g., a Pod crashes), they work to fix it, ensuring the cluster state matches your desired state.

⦁ Example: Ensures that 3 replicas of the "Order Service" pod are always running

Cloud Controller Manager

⦁ This is a specialized component that allows Kubernetes to interact with the underlying cloud provider, like AWS or Azure. It helps in tasks like setting up load balancers and persistent storage.

Worker Node Components

kubelet

⦁ This is the "manager" for each worker node. It ensures all containers on the node are healthy and running as they should be.

⦁ Ensures pods assigned to the node are running and healthy.

⦁ Example: Kubelet ensures that the "Cart Service" pod on a worker node is always running.

kube-proxy

⦁ Think of this as the "traffic cop" for network communication either between Pods or from external clients to Pods. It helps in routing the network traffic appropriately.

⦁ Example: Routes customer search queries to the "Search Service" pod

Container Runtime

⦁ This is the software used to run containers. Docker is commonly used, but other runtimes like containerd can also be used.

⦁ Example: Runs the container for the "Recommendation Engine" service.

Other Components

Pod

⦁ The smallest unit in Kubernetes, a Pod is a group of one or more containers. Think of it like an apartment in an apartment building.

⦁ Example: The "User Authentication" pod contains containers for backend logic and logging.

Service

⦁ This is like a phone directory for Pods. Since Pods can come and go, a Service provides a stable "address" so that other parts of your application can find them.

⦁ Example: The "Product Catalog" service has a ClusterIP service to allow internal communication with the "Recommendation Engine.

Persistent Volumes (PV) and Persistent Volume Claims (PVC):

⦁ Provide long-term storage for pods.

⦁ This is like an external hard-drive that can be attached to a Pod to store data.

⦁ Example: Store user profiles, order history, and product data in a database backed by persistent volumes.

Namespace

⦁ A way to divide cluster resources among multiple users or teams. Think of it as having different folders on a shared computer, where each team can only see their own folder.

Ingress

⦁ Think of this as the "front door" for external access to your applications, controlling how HTTP and HTTPS traffic should be routed to your services.

Real-Time Workflow Example

Scenario: Customer Places an Order

Customer Browses Products:

⦁ Requests are routed through an Ingress to the Frontend Service.

⦁ Frontend communicates with the Product Catalog service via a ClusterIP service.

⦁ Pods for these services run on worker nodes.

Customer Adds to Cart:

⦁ Cart data is stored in a database (using Persistent Volumes).

⦁ The Cart Service pod communicates with the database using a PVC.

Customer Proceeds to Checkout:

⦁ The Order Service pod communicates with the Payment Service to process payments securely using a Secret for the payment API key.

Order Confirmation:

⦁ The Notification Service pod sends a confirmation email via an email API.

Scaling During High Demand:

⦁ The Horizontal Pod Autoscaler automatically scales up the "Order Service" pod replicas during a sale.

Conclusion

Kubernetes architecture effectively handles complex, scalable applications. The e-commerce website example demonstrates how each component contributes to ensuring seamless functionality, high availability, and reliable scaling of the system