Explain Kubernetes Physical Architecture #

Kubernetes Physical View

  • Types of nodes: Architecture is divided into Master Nodes (Control Plane Nodes) & Worker Nodes (Data Plane Nodes)

    • Master Node: Responsible for managing the Kubernetes cluster & orchestrating the workloads
    • Worker Node: Machines where the actual application workloads (containers) run
      • Receives instructions from the Master Node

  • Common Components: (present on EVERY node - Master & Worker)

    • Container Runtime: Responsible for running containers on all nodes
    • Kubelet: Ensures the containers in Pods are running and healthy as defined
    • Kube-Proxy: Facilitates load balancing and service discovery within the cluster

  • Master Nodes Components: (present only on Master Nodes)

    • API Server: Central control point for the cluster, handling all REST API requests to manage Kubernetes objects
    • Scheduler: Allocates Pods to nodes based on current resource metrics and constraints
    • Controller Manager: Runs core controllers (e.g., Node Controller, Replication Controller) to maintain desired state.
      • Node Controller: Monitors the health of nodes
      • Replication Controller: Ensures the specified number of pod replicas are running at all times
      • Deployment Controller: Handles rolling updates, rollbacks
      • DaemonSet Controller, StatefulSet Controller, Job Controller, ...
    • Etcd: A distributed key-value store that stores all cluster state data
    • Cloud Controller Manager: Interfaces with cloud provider APIs to handle cloud-specific resources like persistent disks and external load balancers

What is the role of Deployment, ReplicaSet and a Pod? #

Let's consider deploying two version of a microservice v1 and v2:

kubectl create deployment currency-exchange \ 
    --image=in28min/currency-exchange:0.0.1-RELEASE

# Step 2: Scale it to 16 replicas
kubectl scale deployment currency-exchange --replicas=16

# Step 3: (Optional) Update to a new version (e.g., newer tag)
kubectl set image deployment/currency-exchange \
     currency-exchange=in28min/currency-exchange:0.0.2-RELEASE

Pod

  • Smallest deployable unit in Kubernetes
  • 1 or more containers: Runs one or more containers (typically one microservice version instance)
  • Ephemeral: Pods can be created, destroyed, and replaced automatically
  • Example:
    • v1 pod → runs microservice:1.0 image
    • v2 pod → runs microservice:2.0 image

ReplicaSet

  • Ensures a specified number of pod replicas are running at any times
  • Watches over pods and recreates them if they crash or are deleted
  • Tied to a specific version of a microservice
  • When you have two versions of a microservice, you will have two different ReplicaSet's - v1 ReplicaSet, v2 ReplicaSet

Deployment

  • High-level abstraction that manages ReplicaSets
  • Enables Rolling updates and Rollbacks
  • Manages ReplicaSets and creates new ReplicaSets as needed (e.g., during updates)

Example: Single Deployment with Rolling Update

  • Update the deployment from image v1 to v2
  • Kubernetes:
    • Creates a v2 ReplicaSet
    • Gradually scales down the v1 ReplicaSet
      • v1 ReplicaSet(16), v2 ReplicaSet(4)
      • v1 ReplicaSet(12), v2 ReplicaSet(8)
      • v1 ReplicaSet(8), v2 ReplicaSet(12)
      • v1 ReplicaSet(4), v2 ReplicaSet(16)
      • v1 ReplicaSet(0), v2 ReplicaSet(16)
Deployment
 ├── manages ReplicaSet (1 or more)
 │    ├── maintains a set of Pods (single version)
 └── enables rolling updates between versions

Explain Kubernetes Logical View when a Microservice is Deployed #

Kubernetes Logical View

Kubernetes helps you manage multiple versions of a microservice using Deployments, ReplicaSets, and Pods, with a Service acting as the gateway between users and the running versions of a microservice.

Application User

  • The end user interacts with the application through a stable endpoint.
  • They do not know or care about internals of your Kubernetes architecture!

Service

  • This acts as a stable IP and DNS name that routes traffic to the microservice versions
  • In this case, the Service is:
    • Receiving requests from the user
    • Distributing them to Pods of the microservice

Deployment

  • This is the high-level configuration that:
    • Creates and manages ReplicaSets
    • Manages the rollout and rollback process

ReplicaSet: v1 and v2

  • Each ReplicaSet ensures a fixed number of Pods are running for a specific version.
  • v1 → represents older version (image: app:1.0)
  • v2 → newer version (image: app:2.0)

Pods

  • Actual units of deployment that:
    • Run the application containers

Deployment creates ReplicaSets. ReplicaSets maintain Pods. The Service exposes Pods to users.

You can deploy multiple versions side-by-side and control which version users hit—all while maintaining zero downtime.

What happens in the background when you create a Deployment? #

kubectl create deployment currency-exchange \ 
    --image=in28min/currency-exchange:0.0.1-RELEASE
  • COMMAND EXECUTION: The user runs the kubectl create deployment command with the name currency-exchange and a specified image
  • API SERVER INTERACTION: The kubectl client sends a Deployment object to the Kubernetes API Server via a REST call
  • VALIDATION AND STORAGE: The API Server authenticates the request, validates the Deployment spec, and stores it in etcd, the cluster’s key-value store
  • DEPLOYMENT CONTROLLER TRIGGERED: The Deployment Controller (part of the control plane) detects the new Deployment by watching for changes
  • REPLICASET CREATION: The Deployment Controller creates a ReplicaSet that defines a Pod using the image in28min/currency-exchange:0.0.1-RELEASE
  • POD CREATION INITIATED: The ReplicaSet requests the creation of 1 Pod (default) as specified in the template
  • SCHEDULER ASSIGNMENT: The Scheduler assigns the Pod to an available Node in the cluster based on scheduling criteria
  • KUBELET AND CONTAINER START: The kubelet on the selected Node receives the Pod spec, pulls the image, and starts the container via the container runtime
  • POD STATE: RUNNING: Once the container is up, the Pod transitions to the Running state
  • DEPLOYMENT READY: The Deployment is marked ready once the desired state (1 Pod running) is met

What happens in the background when you Scale your Deployment? #

# Step 2: Scale it to 16 replicas
kubectl scale deployment currency-exchange --replicas=16
  • COMMAND EXECUTION: The user runs the kubectl scale command to update the currency-exchange Deployment and increase the replica count to 16
  • API SERVER INTERACTION: kubectl sends a PATCH request to the Kubernetes API Server. The request updates the .replicas field of the Deployment object to 16
  • VALIDATION AND STORAGE: The API Server authenticates the request, validates the update, and persists the modified Deployment object in etcd
  • DEPLOYMENT CONTROLLER TRIGGERED: The Deployment Controller detects the change in the desired replica count and initiates reconciliation to meet the new target (16 Pods)
  • REPLICASET SCALING: The existing ReplicaSet (associated with the Deployment) is scaled up from 1 to 16 replicas
  • POD CREATION INITIATED: 15 additional Pods are requested to match the new desired state. Each Pod uses the same image and configuration as defined in the ReplicaSet.
  • SCHEDULER ASSIGNMENT: The Scheduler assigns the new Pods to appropriate Nodes in the cluster, based on resource availability and other configuration
  • KUBELET AND CONTAINER START: On each selected Node, the kubelet receives the Pod spec, pulls the container image (if not cached), and starts the container using the container runtime
  • PODS LIFECYCLE: Each Pod transitions through its lifecycle phases: Pending → ContainerCreating → Running
  • DEPLOYMENT STATUS UPDATED: Once all 16 Pods are running and pass readiness checks, the Deployment Controller updates the Deployment status to reflect the successful scaling.

What happens in the background when you update the image in a Deployment? #

kubectl set image deployment/currency-exchange \
    currency-exchange=in28min/currency-exchange:0.0.2-RELEASE
  • COMMAND EXECUTION: The user runs the kubectl set image command to update the image of the container named currency-exchange inside the Deployment currency-exchange, changing it to in28min/currency-exchange:0.0.2-RELEASE
  • API SERVER INTERACTION: kubectl sends a PATCH request to the Kubernetes API Server to update the Pod template in the Deployment spec with the new image
  • VALIDATION AND STORAGE: The API Server authenticates and validates the update, then stores the modified Deployment object in etcd
  • DEPLOYMENT CONTROLLER TRIGGERED: The Deployment Controller detects that the Pod template has changed (because the container image is different). This triggers a rolling update (default) process.
  • NEW REPLICASET CREATED: The Deployment Controller creates a new ReplicaSet corresponding to the new Pod template using the 0.0.2-RELEASE image
  • GRADUAL POD REPLACEMENT (Rolling Update): The Deployment Controller begins replacing Pods from the old ReplicaSet (running 0.0.1-RELEASE) with Pods from the new ReplicaSet:
    • A few new Pods are created with the new image
    • Once they are healthy and Ready, an equal number of old Pods are terminated
    • This continues until all old Pods are replaced
  • SCHEDULER ASSIGNMENT: As new Pods are created, the Scheduler assigns them to Nodes in the cluster based on availability
  • KUBELET AND CONTAINER START: For each new Pod, the kubelet on the assigned Node pulls the new image (if not cached) and starts the container
  • ROLLING UPDATE STATUS MONITORING: The Deployment Controller continuously monitors rollout status
  • DEPLOYMENT STABILIZATION: Once all Pods are updated to the new image and marked Ready, the Deployment is considered successfully rolled out
  • OLD REPLICASET RETAINED (BY DEFAULT): Kubernetes keeps the old ReplicaSet (scaled to zero) for rollback purposes, unless explicitly deleted.