Master Docker and Kubernetes: Core Concepts Explained for Cloud‑Native Beginners

Background

This document was created to share basic concepts of cloud‑native container technologies with colleagues working on the HWL online school cloud business line.

1. Docker Core Concepts

Why Docker?

Traditional virtual machines require a hypervisor, a full guest OS, and large disk, CPU, and memory footprints. Docker replaces the hypervisor with a lightweight daemon that runs directly on the host OS, packaging applications and all their dependencies into images, which are instantiated as isolated containers.

Compared with VMs, Docker containers start in milliseconds, consume far less disk space, and share the host kernel.

Docker Architecture

Docker follows a client‑server model. The Docker client communicates with the Docker daemon via REST API (UNIX socket or network). The daemon manages images, containers, networks, and volumes. Docker can run locally or connect to a remote daemon.

Key components:

Docker Daemon – background process that creates and manages containers.

Docker Client – CLI that sends commands to the daemon.

Docker Host – the physical or virtual machine where the daemon runs.

Docker Registry – storage for images (public Docker Hub or private registries).

Docker Image – read‑only template containing the filesystem, libraries, and metadata needed to run a container.

Docker Container – a running instance of an image, isolated from other containers.

Docker CLI, Dockerfile, Docker Compose, Docker Swarm

The Docker CLI provides commands to build images, run containers, and manage resources.

A Dockerfile defines how to build an image.

Docker Compose uses a YAML file to define and run multi‑container applications with a single command.

Docker Swarm is Docker’s native clustering and orchestration tool, suitable for simple, fast‑development environments, while Kubernetes is preferred for larger, more complex clusters.

2. What Is Kubernetes and Its Architecture

Kubernetes (k8s) is an open‑source system for automating deployment, scaling, and management of containerized applications. Its name means “pilot” or “steersman,” reflecting its role in navigating containers (the “cargo”) across a cluster.

Key Capabilities

Service discovery and load balancing.

Automatic scheduling of containers onto nodes.

Self‑healing of failed containers.

Automated rollouts and rollbacks.

Batch job execution.

Horizontal pod autoscaling.

Architecture Overview

Kubernetes follows a master‑node (control‑plane) design.

Master components: API Server, Controller Manager, Scheduler, etcd (distributed key‑value store).

Node components: kubelet (agent), container runtime (e.g., Docker, containerd), kube‑proxy (service networking), and optional storage/network plugins.

Control Plane Details

The API Server is the single entry point for all RESTful operations, handling authentication, authorization, and request routing. Controllers maintain desired state (e.g., replication, rolling updates). The Scheduler assigns pods to nodes based on resource requests. etcd stores the entire cluster state.

Node Details

kubelet watches the API Server for pod specifications and ensures containers are running as described. The container runtime actually pulls images and runs containers. kube‑proxy implements service networking using iptables or IPVS.

3. Kubernetes Core Concepts

Pod

The smallest deployable unit; a pod encapsulates one or more tightly coupled containers that share storage, network, and a specification for how to run the containers.

Volume

Abstracts storage resources that can be mounted into pods. Volumes support many back‑ends, including local disks, distributed systems (Ceph, GlusterFS), and cloud provider disks.

Deployment

Manages a set of identical pods, handling replica scaling, rolling updates, and rollbacks through a controller.

Service

Provides a stable network endpoint (ClusterIP, NodePort, LoadBalancer, or ExternalName) for accessing a group of pods, handling load balancing and service discovery.

Namespace

Logical partition of a cluster for isolating resources, access control, and naming.

Kubernetes API

Exposes resources via HTTP+JSON. Users interact with the API using kubectl, UI, or curl, sending and receiving JSON or YAML representations of objects such as Pods, Deployments, and Services.

Labels (key‑value pairs) enable selection of objects (e.g., pods) via selectors, similar to SQL WHERE clauses, facilitating grouping for Deployments and Services.