Understanding Concepts on Advanced Beginner

Architecture

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to understand Kubernetes structure Prerequisites: Basic Docker concepts After reading this: You will understand Kubernetes cluster components and their roles

TL;DR

Kubernetes cluster consists of Control Plane (brain) and Worker Nodes (muscle)

Control Plane manages cluster state, Worker Nodes execute actual workloads

kubectl commands communicate with the cluster through API Server

Overall Cluster Structure#

A Kubernetes cluster is broadly divided into two parts.

Pod

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to understand Kubernetes Pod concept Prerequisites: Basic Docker container concepts After reading this: You will understand what Pods are and why we use Pods instead of containers

TL;DR

Pod is the smallest deployable unit in Kubernetes

A Pod contains one or more containers that share network and storage

Most Pods contain only a single container

What is a Pod?#

A Pod is the smallest deployable unit that can be created and managed in Kubernetes. While containers are the smallest unit in Docker, Pods are the smallest unit in Kubernetes.

Deployment

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to deploy applications in Kubernetes Prerequisites: Pod concepts After reading this: You will understand how to deploy and update applications with Deployments

TL;DR

Deployment manages declarative updates of Pods

Rolling updates enable zero-downtime deployment

Can rollback to previous version when problems occur

What is Deployment?#

Deployment is a resource that manages Pod deployment and updates. Using Deployment instead of directly managing Pods offers several benefits.

Service

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to configure network access in Kubernetes Prerequisites: Pod, Deployment concepts After reading this: You will understand how to reliably access Pods with Services

TL;DR

Service provides a stable network endpoint for a set of Pods

Pod IPs change but Service IP (ClusterIP) is fixed

Three types exist: ClusterIP, NodePort, LoadBalancer

Why Service is Needed#

Pod IPs change whenever Pods are recreated. How can we communicate reliably in this situation?

ConfigMap and Secret

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to manage application configuration in Kubernetes Prerequisites: Pod concepts After reading this: You will understand how to separate and manage configuration and sensitive information with ConfigMap and Secret

TL;DR

ConfigMap stores general configuration (DB host, log level, etc.)

Secret stores sensitive information (passwords, API keys, etc.)

Both can be injected into Pods as environment variables or files

Overall Flow#

Let’s first examine the flow of ConfigMap and Secret injection into Pods.

Volume and Storage

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to persist data in Kubernetes Prerequisites: Pod concepts After reading this: You will understand Volume, PersistentVolume, and PersistentVolumeClaim concepts and usage

TL;DR

Pods are ephemeral by default, data disappears on termination

Volumes allow data sharing between containers within a Pod

PersistentVolume (PV) and PersistentVolumeClaim (PVC) maintain data independently of Pod lifecycle

Why Volumes are Needed?#

Container filesystems are ephemeral by default.

Problem	Volume Solution
Data loss on container restart	Preserve data with Volume
Cannot share files between containers in same Pod	Mount shared Volume
All data lost on Pod termination	Persist with PersistentVolume

Volume Types Overview#

Kubernetes provides various Volume types.

Networking

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to understand Kubernetes network structure Prerequisites: Service concepts, basic networking knowledge (IP, ports, DNS) After reading this: You will understand Kubernetes network model and Ingress

TL;DR

All Pods have unique IPs and can communicate directly with other Pods

Service provides stable access point for a set of Pods

Ingress routes HTTP/HTTPS traffic from outside the cluster

Kubernetes Network Model#

Kubernetes networking follows three basic principles.

Resource Management

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to efficiently manage resources in Kubernetes Prerequisites: Pod, Deployment concepts After reading this: You will understand the difference between requests and limits, and how to configure appropriate resources

TL;DR

requests: Minimum guaranteed resources used for scheduling

limits: Maximum usable resources

CPU excess causes throttling, memory excess causes OOMKilled

Why Resource Configuration is Needed?#

Running Pods without resource configuration causes several problems.

Problem	After Resource Configuration
One Pod monopolizes node resources	Limit max usage with limits
Resources not considered during scheduling	Schedule based on requests
Random Pod termination on memory shortage	Priority based on QoS class
Unpredictable resource usage	Explicit resource allocation

requests and limits#

Kubernetes provides two resource control methods.

Scaling

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to configure auto-scaling in Kubernetes Prerequisites: Deployment, resource management concepts After reading this: You will understand auto-scaling methods using HPA and VPA

TL;DR

HPA (Horizontal Pod Autoscaler) automatically adjusts Pod count

VPA (Vertical Pod Autoscaler) automatically adjusts Pod resource requests

In most cases, consider HPA first

Scaling Methods Comparison#

Kubernetes provides two scaling methods.

Method	Description	Suitable For
Horizontal scaling (HPA)	Adjust Pod count	Stateless applications
Vertical scaling (VPA)	Adjust Pod resources	Stateful, resource optimization

flowchart LR
 subgraph Horizontal[Horizontal Scaling]
 H1[Pod] --> H2[Pod]
 H2 --> H3[Pod]
 end
 subgraph Vertical[Vertical Scaling]
 V1[Pod<br>256Mi] --> V2[Pod<br>512Mi]
 end

HPA (Horizontal Pod Autoscaler)#

HPA automatically adjusts Pod count based on metrics (CPU, memory, custom).

Health Checks

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Target Audience: Backend developers who want to monitor application status in Kubernetes Prerequisites: Pod, Deployment concepts After reading this: You will understand the differences between Liveness, Readiness, and Startup Probes and how to configure them

TL;DR

Liveness Probe: Check if container is alive, restart on failure

Readiness Probe: Check if ready to receive traffic, remove from service on failure

Startup Probe: Check startup completion, other Probes disabled until completion

Why Health Checks are Needed?#

A Running container doesn’t mean the application is healthy.

Namespace

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Overall Analogy: Building Wings in an Apartment Complex#

Namespaces are easy to understand when compared to building wings in an apartment complex:

Apartment Complex Analogy	Kubernetes Namespace	Role
Wing 101, Wing 102 separation	Namespace	Logically isolate resources
Per-wing maintenance budget	ResourceQuota	Limit total resources per namespace
Per-unit electricity/water limit	LimitRange	Default resources per Pod/container
Management office restricted area	kube-system	Dedicated space for system components
Public bulletin board area	kube-public	Space accessible to all users
Per-wing access card	RBAC + Namespace	Separate access permissions

In this way, a Namespace is like “dividing management areas by building wing within a single apartment complex.”

StatefulSet

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Overall Analogy: A Restaurant with Reserved Seats#

StatefulSets are easy to understand when compared to a restaurant with reserved seats:

Restaurant Analogy	Kubernetes StatefulSet	Role
Reserved seat numbers (Seat 1, 2, 3)	Pod names (app-0, app-1, app-2)	Stable and unique identifiers
Personal locker for each guest	PersistentVolumeClaim	Dedicated persistent storage per Pod
Seated/unseated in order	Sequential creation/deletion	Created from 0, deleted in reverse
Name plate reservation	Stable network ID	Same hostname preserved after Pod restart
Open seating restaurant	Deployment	Sit anywhere, seats may change

In this way, a StatefulSet is like “having reserved seats and personal lockers so you always use the same seat and the same belongings.”

RBAC

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Overall Analogy: Building Access Card System#

RBAC is easy to understand when compared to a building access card system:

Building Access Analogy	Kubernetes RBAC	Role
Access permission set (3rd floor server room access)	Role	Define allowed operations within a specific Namespace
Master key for all buildings	ClusterRole	Define allowed operations across the entire cluster
Grant permission to employee badge	RoleBinding	Assign a Role to a user
Grant access to all branches	ClusterRoleBinding	Assign a ClusterRole to a user
Employee badge	ServiceAccount	Authentication identity used by Pods
“Access only necessary areas” principle	Principle of Least Privilege	Grant only required permissions

In this way, RBAC is like systematically managing “who can do what and where.”

Jobs and CronJobs

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Overall Analogy: Part-Time Work and Scheduled Cleaning#

Jobs and CronJobs are easy to understand when compared to part-time work and scheduled cleaning:

Analogy	Kubernetes	Role
One-time part-time work	Job	A task that runs once and finishes
Scheduled cleaning routine	CronJob	A task that runs periodically on a schedule
Hire 3 workers	completions: 3	Number of successful completions required
Deploy 2 workers at once	parallelism: 2	Number of Pods to run simultaneously
Maximum retry attempts	backoffLimit	Retry limit on failure
Work deadline	activeDeadlineSeconds	Overall time limit for the task

In this way, a Job is “a task that finishes once the assigned work is done,” and a CronJob is “a scheduled task that runs repeatedly at set times.”

NetworkPolicy

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Overall Analogy: Apartment Complex Firewall#

NetworkPolicy is easy to understand when compared to an apartment complex access control system:

Apartment Complex Analogy	Kubernetes NetworkPolicy	Role
Per-wing access control rules	NetworkPolicy	Define traffic allow/block between Pods
“Only Wing 101 residents allowed”	podSelector	Select target Pods for the policy
“Delivery person only to lobby”	Ingress rules	Control incoming traffic
“Packages sent through security”	Egress rules	Control outgoing traffic
Security system (CCTV, key cards)	CNI plugin	Network engine that enforces policies
No rules means free access	Default Allow All	All traffic allowed when no NetworkPolicy is set

In this way, NetworkPolicy is like firewall rules that control “which Pods can communicate with which Pods.”