Why Kubernetes? A Visual Guide to Containers, Pods, and Cluster Architecture

Preface

Recently I started a Kubernetes journey to better understand its internals, and here is a brief introduction.

Containers

Before diving into Kubernetes, let’s clarify what a container is and why it is so popular. Discussing a container orchestrator without understanding containers makes no sense.

容器

is a container that holds everything you put inside it.

It includes your application code, libraries, dependencies, and even the kernel. The key concept is isolation—separating everything from the rest for better control. Containers provide three types of isolation:

Workspace isolation (process, network)

Resource isolation (CPU, memory)

Filesystem isolation (union file system)

Think of containers like lightweight VMs: they are streamlined, fast to start, and small in size, built on Linux constructs such as cgroups and namespaces.

Now that we know what containers are, it’s easy to see why they are popular: they package the entire runtime environment, solving the “works on my machine” problem.

When to use Kubernetes?

Containers make developers’ lives easier, but why need another technology like Kubernetes?

When the number of containers grows beyond manual management, an orchestrator is required.

Q: Where are my frontend containers and how many should I run?

A: Hard to say—use a container orchestrator.

Q: How do frontend containers talk to newly created backend containers?

A: Hard‑code IPs or, better, use an orchestrator.

Q: How to perform rolling upgrades?

A: Manually upgrade each step or use an orchestrator.

Why I prefer Kubernetes

There are several orchestrators such as docker swarm, Mesos and Kubernetes. I choose Kubernetes because it offers a flexible, component‑based architecture similar to LEGO blocks, allowing custom schedulers, CRDs, and a vibrant community.

Kubernetes Architecture

Each Kubernetes cluster has two node types: Master and Node. The Master controls and monitors the cluster, while Nodes run workloads.

Clusters can run with a single master, but three masters are recommended for high availability.

etcd

: a key‑value store that holds all Kubernetes object states and configuration. API Server: a RESTful API exposing endpoints for cluster operations; almost all components communicate through it. Scheduler: decides on which node a workload should run. Controller Manager: runs control loops that monitor cluster state via the API Server and act to reach the desired state. kubelet: the heart of a worker node, communicating with the API Server to start and stop containers on its host. kube-proxy: handles Pod networking using iptables/IPVS and provides Service discovery. Pod: the smallest Kubernetes unit; without Pods you cannot run containers. Pods give containers a shared network namespace and can run multiple containers that see each other as localhost.

A Pod can contain multiple containers that share the same localhost, making it easy to separate application concerns while deploying them together. Different pod patterns such as sidecar, proxy, and ambassador address various needs.

Each Pod receives its own IP address, and kube‑proxy routes traffic to that IP, which is visible only within the cluster.

All containers can also see attached volumes, enabling asynchronous communication. For example, a photo‑upload app could store images in a shared volume that another container monitors to generate thumbnails and upload them to cloud storage.

Controllers

Kubernetes includes many controllers such as ReplicaSet, ReplicationController, Deployment, StatefulSet, and Service, which manage Pods in various ways.

ReplicaSet

A ReplicaSet ensures a specified number of Pod replicas are running; if a Pod dies, it creates a new one.

Deployment

A Deployment is a higher‑level object that uses a ReplicaSet to manage replicas, providing rolling updates and scaling.

Service

A Service acts as a load balancer, distributing network traffic to the appropriate Pods based on labels, eliminating the need to hard‑code Pod IPs.

PS: Services are virtual entities; actual packet routing is handled by iptables/IPVS/CNI plugins, but the Service abstraction simplifies interaction within the Kubernetes ecosystem.

Ingress

Ingress provides a single entry point for external traffic to reach services inside the cluster, enabling centralized security policies, monitoring, and logging.

PS: Kubernetes also includes other controller objects such as DaemonSet , StatefulSet , Job , as well as Secret and ConfigMap for storing sensitive data and configuration.

Article Source

Author: Sudhakar Rayavaram Original: https://medium.com/tarkalabs/know-kubernetes-pictorially-f6e6a0052dd0