Understanding the concept and architecture of
Docker & Kubernetes

Singhdeep

12 min read

·

Oct 16, 2026

--

1

Listen

Share

Let’s start with Containerization
Containerization is the foundational concept behind Docker. At its core, containerization is a method of packaging an application together with all of its dependencies, libraries, and configuration files so that it runs reliably and consistently across any computing environment — whether on a developer’s laptop, a testing server, or in the cloud.

Is it similar to Virtual machines?

Containers vs. Virtual Machines (VMs):
Virtual Machines virtualize the underlying hardware. Each VM includes a full guest operating system (OS), which makes them heavy, slow to boot, and resource-intensive.

Containers virtualize the operating system. They share the host OS kernel and run as isolated processes. This makes them lightweight, fast to start (seconds vs. minutes), and efficient with system resources.
Let’s see below detail now

Feature

Core Components of Containerization

1. Image: A read-only blueprint or template containing the application code, runtime, libraries, environment variables, and configuration files
2. Container: A runnable instance of a container image. You can create, start, stop, move, or delete a container using Docker commands.
3. Engine / Runtime: The underlying software layer (like Docker Engine) responsible for building, running, and managing containers on the host OS.
4. Registry: A repository where container images are stored and shared (e.g., Docker Hub, GitHub Container Registry, AWS ECR).

Docker
Docker is an open-source platform that automates the deployment, scaling, and management of applications using OS-level containerization.

If not understand the just read below 🐻‍❄️
In simple terms, Docker packages an application along with all of its dependencies, libraries, configuration files, and runtime environment into a single lightweight unit called a container. This guarantees that the software will execute identically regardless of the underlying hardware or host operating system — solving the classic “it works on my machine” problem.

Architecture of Docker

First understand
What is a Daemon?
In computing, a daemon (pronounced DEE-mun) is a background process or service that runs continuously without direct user interaction.

Now understand
There are 3 components in Docker architecture:

• Docker client
  The docker client talks to the Docker daemon.
• Docker host
  The Docker daemon listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes.
• Docker registry
  A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use.

Let’s take the “docker run” command as an example.

• Docker pulls the image from the registry.
• Docker creates a new container.
• Docker allocates a read-write filesystem to the container.
• Docker creates a network interface to connect the container to the default network.
• Docker starts the container

More detail understanding of components we we listen in daily use cases

1. The Core Architecture Components

• Docker Client (docker CLI): The primary command-line tool developers use to interact with Docker. It accepts user commands (like docker run or docker build) and sends API requests to the Docker Daemon
• Docker Daemon (dockerd): The persistent background service running on the host OS. It handles heavy lifting like building images, running containers, and managing storage and networking.
• Docker Engine: The core software package containing the Docker Client, Docker Daemon, and the REST API that allows them to communicate.

2. Primary Execution & Storage Artifacts

• Docker Images: Read-only blueprints or templates containing application code, runtime libraries, environment settings, and files necessary to create containers
• Docker Containers: Isolated, lightweight runtime instances created from Docker images.
• Docker Registry: A central service or repository used to store and distribute Docker images. Public examples include Docker Hub, while private registries include AWS ECR, GCP Artifact Registry, or self-hosted registries.

3. Internal System Components

• containerd: High-level container runtime managed by the Docker Daemon that handles image transfer, storage, container execution, and supervision.
• runc: Low-level, lightweight container runtime tool that interacts directly with the Linux kernel (using namespaces and cgroups) to spawn and isolate the actual container processes.

4. Docker Infrastructure Management Components

• Docker Networks: The virtual networking drivers (e.g., bridge, host, overlay) that enable containers to communicate securely with each other, the host system, and external networks.
• Docker Volumes & Binds: The storage components used to persist container data beyond the container’s lifecycle.
• Docker Compose: A tool used to define and manage multi-container Docker applications using a single configuration file (docker-compose.yml).

Some commands which we need
System & Information Commands -
# Display system-wide Docker information and configuration

docker info[cite: 1]
# Display Docker version details (client and server daemon)
docker version[cite: 1]
# Display real-time resource usage statistics for running containers
docker stats# View system-wide disk usage by Docker objects (images, containers, volumes)

docker system df

# Clean up unused data (stopped containers, unused networks, dangling images)

docker system prune -f[cite: 1]

Container Lifecycle Commands
# Run a container from an image in detached (background) mode with port mapping

docker run -d -p <host_port>:<container_port> — name <container_name> <image_name>[cite: 1]

# List running containers

docker ps[cite: 1]

# List all containers (including stopped ones)

docker ps -a[cite: 1]

# Start a stopped container

docker start <container_name_or_id>

# Stop a running container gracefully

docker stop <container_name_or_id>[cite: 1]

# Forcefully stop a running container immediately

docker kill <container_name_or_id>

# Restart a container

docker restart <container_name_or_id>

# Remove a stopped container

docker rm <container_name_or_id>[cite: 1]

# Force remove a running container

docker rm -f <container_name_or_id>

Executing Commands & Debugging Containers
# Fetch and stream real-time logs from a container

docker logs -f <container_name_or_id>[cite: 1]

# Execute an interactive shell session inside a running container

docker exec -it <container_name_or_id> /bin/bash[cite: 1]

# Use /bin/sh if bash is not available (e.g., Alpine images)

docker exec -it <container_name_or_id> /bin/sh[cite: 1]

# Inspect detailed low-level JSON configuration of a container or image

docker inspect <container_or_image_name>
# View active processes running inside a container

docker top <container_name_or_id>

Note: There are many poc’s we can to from basic to advance we will seem them later

Oh finally Kubernetes 🫣

Wait Wait Wait before this let’s understand orchestration
In the context of technology and IT, orchestration refers to the automated management, coordination, and alignment of complex computer systems, middleware, and services.

Think of it like an orchestra conductor:

• Individual software applications, databases, or containers are the musicians.
• The orchestration engine (the conductor) ensures everyone plays the right notes at the right time, at the right volume, without missing a beat or bumping into each other.
• Oh, you it right!😎 If not than check below

Container Orchestration (Kubernetes & Docker Swarm)

When you only have 2 or 3 containers on a single machine, managing them manually is easy. But in enterprise environments running hundreds or thousands of containers across multiple servers, manual management breaks down.

Container Orchestration automates the entire lifecycle of containers across a cluster of servers:

1. Automated Provisioning & Deployment: Deciding which server (node) has enough CPU/RAM to run a new container and deploying it there automatically.
2. Scaling & Load Balancing: Automatically launching extra containers when website traffic surges and distributing incoming network traffic evenly among them.
3. Self-Healing: Continuously monitoring container health — if a container crashes or a server dies, the orchestrator automatically restarts or moves those containers to a healthy machine.
4. Zero-Downtime Updates: Deploying new software updates by replacing old containers with new ones one by one (rolling updates), rolling back automatically if errors are detected.
5. Resource Management: Allocating precise CPU, memory, and storage constraints so applications don’t starve each other of hardware resources.

Oh , finally you got it!!!!!

Let’s go for Kubernetes now:

1. What is Kubernetes?

Kubernetes (often stylized as K8s) is an open-source container orchestration system for automating application deployment, scaling, and management. While Docker packages and runs individual containers, Kubernetes manages large-scale clusters of containers across multiple host machines.

2. Architecture Breakdown

Control Plane (Master Node)

The control plane makes global decisions about the cluster (e.g., scheduling workloads, detecting and responding to cluster events):

• kube-apiserver: The front-end API gateway for the Kubernetes control plane. It processes administrative and internal API request
• etcd: A consistent and highly available key-value store used as Kubernetes’ primary database for all cluster state data.
• kube-scheduler: Watches for newly created Pods with no assigned node and selects a worker node for them to run on based on resource requirements.
• kube-controller-manager: Runs controller processes (like Node Controller, Job Controller, EndpointSlice Controller) that continuously drive current cluster state toward desired state.

Worker Nodes

Worker node components run on every node, maintaining running pods and providing the Kubernetes runtime environment:

• kubelet: An agent that runs on each node in the cluster ensuring containers are running in a Pod as specified by the control plane.
• kube-proxy: A network proxy that runs on each node, maintaining network rules on nodes to allow network communication to your Pods.
• Container Runtime: The software responsible for running containers (e.g., containerd, CRI-O).

Now let’s understand the about configMAP?
A ConfigMap in Kubernetes is an API object used to store non-confidential configuration data in key-value pairs
Parts under ConfigMap

ConfigMap & Secret

Description

Pod

The smallest deployable computing unit in Kubernetes. Holds one or more tightly coupled containers sharing network and storage resources.

Deployment

Provides declarative updates for Pods and ReplicaSets. Manages scaling, self-healing, rolling updates, and rollbacks.

Service

An abstract way to expose an application running on a set of Pods as a single network service (provides a stable IP and DNS entry).

Namespace

Provides virtual cluster isolation to separate environments or teams (e.g., default, kube-system, dev, prod).

ConfigMap & Secret

Objects used to store non-confidential configuration and sensitive data (passwords, keys) separately from application code.

Control Plane Architecture Modes

Single-Control Plane Mode (Non-HA / Development)

• Structure: 1 Control Plane Node + 1 or more Worker Nodes.
• Characteristics: Simple and low-cost, but has a single point of failure (SPOF). If the master node goes down, the cluster control plane becomes unavailable.
• Best For: Learning, testing, local development, and non-critical environments.

High Availability (HA) Mode (Production)

• Structure: Multiple Control Plane Nodes (typically 3 or 5 for etcd quorum) behind a Load Balancer + multiple Worker Nodes.
• Topologies:

1. Stacked etcd Topology: The etcd key-value store runs on the same nodes as the Control Plane components.
2. External etcd Topology: etcd runs on dedicated, separate machines outside the Control Plane nodes for maximum isolation and performance.

3. Best For: Enterprise production workloads requiring zero downtime

2. Kubernetes Setup Types & Tools

Type A: Local / Lightweight Setups (Single-Node & Dev)

• Minikube: Runs a single-node or multi-node cluster inside a local VM or Docker container. Ideal for learning K8s.
• Kind (Kubernetes in Docker): Runs Kubernetes nodes as Docker containers. Extremely fast and widely used for local testing and CI/CD pipelines.
• MicroK8s: Lightweight, snap-based K8s distribution by Canonical (Ubuntu), suitable for edge devices, IoT, and local workstations.
• K3s: Lightweight K8s distribution created by Rancher, packaged as a single binary with low memory usage. Popular for edge computing, IoT, and lightweight environments.

Type B: Bare Metal / VM Self-Managed (Production)

• kubeadm: The official, standard tool to bootstrap production-ready Kubernetes clusters on physical bare-metal servers or cloud Virtual Machines.
• Kubespray: An Ansible-based tool used to deploy production HA clusters across multiple Linux servers with advanced customization.
• RKE (Rancher Kubernetes Engine): An enterprise-grade K8s distribution that runs entirely inside Docker containers on bare metal or VMs.

Type C: Managed Cloud Kubernetes (KaaS — Kubernetes as a Service)

Cloud providers manage the Control Plane, etcd, patching, and master node upgrades automatically. You only pay for and manage the worker nodes.

• Amazon EKS (Elastic Kubernetes Service)
• Google GKE (Google Kubernetes Engine)
• Microsoft AKS (Azure Kubernetes Service)

Key differences

Press enter or click to view image in full size

Let’s talk about difference between Docker and K8s
Comparing Docker and Kubernetes is not a matter of choosing one over the other; rather, they are complementary technologies that operate at different layers of the container ecosystem.

Core Difference: Single Machine vs. Distributed Cluster

• Docker is a containerization platform used to package, build, and run applications inside individual containers on a single host machine.
• Kubernetes is a container orchestration engine designed to manage, scale, and coordinate thousands of containers across a cluster of multiple connected machines.

Side-by-Side Comparison

Feature

Docker

Kubernetes (K8s)

Primary Focus

Containerizing and running apps on single nodes.

Orchestrating and managing containers at scale.

Scope

Single server / machine.

Multi-node cluster environment.

Basic Unit

Container.

Pod (contains one or more containers).

Scaling

Manual or limited (via Docker Compose/Swarm).

Automatic horizontal scaling based on load.

Self-Healing

Basic auto-restart policies.

Advanced self-healing (replaces dead nodes/pods).

Load Balancing

Basic port mapping and local bridges.

Built-in service discovery, ingress, and load balancing.

Updates

Manual image updates and container recreation.

Automated rolling updates and instant rollbacks.

Analogy

Think of shipping logistics:

• Docker is like the standardized shipping container: it packages goods safely so they can be transported anywhere easily.
• Kubernetes is like the cargo ship & port authority: it manages thousands of shipping containers, decides which ship carries which container, replaces damaged containers, and ensures smooth arrival and offloading.

How They Work Together

In modern cloud infrastructure, Docker and Kubernetes work together in a unified workflow:

1. Build: You use Docker to package application code into a container image using a Dockerfile.
2. Ship: You push that Docker image to a container registry like Docker Hub or AWS ECR.
3. Run & Scale: You deploy the Docker image onto a Kubernetes cluster using YAML manifests. Kubernetes pulls the Docker image and manages its lifecycle across hundreds of servers.

Commands use used on daily cases
# Display cluster endpoints and master services status

kubectl cluster-info

# List all nodes in the cluster with status, roles, age, and version

kubectl get nodes

# Show detailed information about cluster nodes (CPU, memory, kernel, OS)

kubectl describe node <node-name>

# Display current context (active cluster and user)

kubectl config current-context

# List all available contexts in kubeconfig

kubectl config get-contexts

# Switch active context

kubectl config use-context <context-name>

Workload & Pod Operations
# List pods in current namespace

kubectl get pods

# List pods across ALL namespaces with wide output (IPs, Node assignments)

kubectl get pods -A -o wide

# Run a temporary standalone pod

kubectl run my-pod — image=nginx:alpine

# Create a deployment

kubectl create deployment my-deploy — image=nginx:alpine

# Scale a deployment to a specific number of replicas

kubectl scale deployment my-deploy — replicas=5

# View deployment rollout status

kubectl rollout status deployment/my-deploy

# Pause or resume a deployment rollout

kubectl rollout pause deployment/my-deploy

kubectl rollout resume deployment/my-deploy

# Undo/Rollback a deployment to the previous revision

kubectl rollout undo deployment/my-deploy

Services, Networking & Exposing Workloads

# List all services

kubectl get services (or kubectl get svc)

# Expose a deployment as a ClusterIP, NodePort, or LoadBalancer service

kubectl expose deployment my-deploy — port=80 — target-port=8080 — type=NodePort

# Forward a local port to a pod port for quick local testing

kubectl port-forward pod/<pod-name> 8080:80

# List all Ingress rules

kubectl get ingress

Manifest Application & Declarative Management
# Create or update resources defined in a YAML or JSON file

kubectl apply -f manifest.yaml

# Apply all manifest files in a directory recursively

kubectl apply -f ./my-manifests/

# Delete resources defined in a manifest file

kubectl delete -f manifest.yaml

# Generate YAML template without applying (Dry Run)

kubectl create deployment my-app — image=nginx — dry-run=client -o yaml > deployment.yaml

ConfigMaps & Secrets
# List ConfigMaps and Secrets

kubectl get configmaps

kubectl get secrets

# Create ConfigMap from key-value literals

kubectl create configmap my-config — from-literal=KEY1=VALUE1 — from-literal=KEY2=VALUE2

# Create Secret from key-value literals

kubectl create secret generic my-secret — from-literal=password=SuperSecret123

# Inspect a ConfigMap or Secret details

kubectl describe configmap my-config

kubectl get secret my-secret -o yaml

Troubleshooting & Debugging
# Show detailed events and operational history of a resource

kubectl describe pod <pod-name>

# Stream logs from a container in a pod

kubectl logs -f <pod-name>

# Stream logs from a specific container inside a multi-container pod

kubectl logs -f <pod-name> -c <container-name>

# Stream logs from ALL pods with a specific label selector

kubectl logs -f -l app=web-app

# Execute an interactive terminal inside a pod container

kubectl exec -it <pod-name> — /bin/sh

# Display resource usage (CPU/Memory) for nodes and pods (requires Metrics Server)

kubectl top nodes

kubectl top pods

Resource Cleanup & Deletion
# Delete a specific pod

kubectl delete pod <pod-name>

# Delete a deployment (removes underlying pods as well)

kubectl delete deployment my-deploy

# Delete a service

kubectl delete service my-service

# Delete all resources matching a specific label

kubectl delete pods,services -l app=web-app

For more details we can understand at
https://kubernetes.io/docs/concepts/architecture/nodes/