Kubernetes Core Architecture: Cluster, Pod, Deployment, and Declarative Management

Lou Chang included in DevOps Kubernetes

2026-02-25 About 1700 words 8 minutes

Contents

DevOps Learning Notes

Using kind to create a local K8s cluster, understanding Cluster, Node, Pod, and Deployment relationships from scratch, and the core mindset of K8s declarative management

Cluster Composition and Node Roles

A K8s cluster consists of two roles:

Control Plane: the brain, responsible for decisions (scheduling, monitoring, storing state)
Worker Node: the hands and feet, responsible for actually running containers

A typical production cluster:

1
2
3
4
5
6
7
8


Cluster
├── Control Plane Node 1  ┐
├── Control Plane Node 2  ├── usually 3 nodes for HA (high availability)
├── Control Plane Node 3  ┘
├── Worker Node 1  ┐
├── Worker Node 2  ├── scales with workload, could be tens to hundreds
├── Worker Node 3  │
└── ...             ┘

Control Plane runs 3 nodes because etcd (the database storing all cluster state) needs an odd number for consensus — if one goes down, the remaining two can still vote for a leader, and the cluster continues operating.

Brain Components

Component	Role
API Server	Entry point for all operations. `kubectl` communicates with it
etcd	Distributed key-value database, stores the entire cluster’s state
Scheduler	Decides which Node a Pod runs on
Controller Manager	Runs various controllers (Deployment, ReplicaSet, etc.)

Workload-Machine Daemons

Component	Role
kubelet	Agent on each Node, ensures Pods are actually running
kube-proxy	Maintains network rules (iptables/ipvs), enables Service routing to Pods
container runtime	What actually runs containers (containerd)

Spinning Up a Test Group Locally

kind (Kubernetes IN Docker) runs the entire K8s cluster inside a Docker container, for learning and testing.

1

kind create cluster --name devops-lab

What this command does:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


kind create cluster
 ├── pull kindest/node Docker image
 ├── start a Docker container (this is your Node)
 ├── run the full K8s stack inside the container:
 │   ├── etcd
 │   ├── API Server
 │   ├── Scheduler
 │   ├── Controller Manager
 │   ├── kubelet
 │   ├── kube-proxy
 │   └── CoreDNS
 └── configure kubectl context

kind’s special feature: one Docker container plays both Control Plane + Worker, so kubectl get nodes will only show one Node.

Connection Target Selection in kubeconfig

kubectl uses context to know which cluster to connect to. After kind create completes, it automatically sets kind-devops-lab as the active context.

1
2


kubectl config current-context
# kind-devops-lab

If you have multiple clusters simultaneously (e.g., kind + AWS EKS), you need to use --context to specify.

Making Local Images Available to the Cluster

The container runtime inside kind (containerd) is isolated from the local Docker daemon. Images built with local docker build are not visible to kind.

1

kind load docker-image go-api:0.0.2 --name devops-lab

1
2
3
4


Local Docker daemon                kind Node's containerd
┌──────────────────┐              ┌──────────────────┐
│  go-api:0.0.2    │ ──transfer─→ │  go-api:0.0.2    │
└──────────────────┘              └──────────────────┘

kind load only transfers the image, it doesn’t start anything. Only when kubectl apply runs will kubelet use this image to create a container.

You can verify the image is in the Node with crictl:

1

docker exec devops-lab-control-plane crictl images | grep go-api

crictl is a CLI for interacting with containerd, just like the docker command is a CLI for interacting with the Docker daemon.

Smallest Schedulable Workload Primitive

A Pod is a wrapper K8s adds on top of containers.

1
2


Docker world:     Container
K8s world:        Pod → wraps 1 or more Containers

Containers in the same Pod share network (same IP, communicate via localhost) and storage. In most cases, it’s one Pod one container.

Why K8s Wraps Containers in Pods

K8s’s smallest management unit is Pod, not container:

Scheduling: Scheduler places the entire Pod onto a Node
IP: Assigned to the Pod, containers within the same Pod share it
Lifecycle: When a Pod dies, all containers inside die together

Workload Specification Sample

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: Pod
metadata:
  name: go-api
  labels:
    app: go-api         # label, used by Service to find this Pod
spec:
  containers:
    - name: go-api
      image: go-api:0.0.2
      ports:
        - containerPort: 8080

1
2


kubectl apply -f k8s/pod.yaml
kubectl describe pod go-api

From kubectl apply to Running Container

The Events section of kubectl describe pod records the complete process:

1
2
3
4
5


Events:
  Scheduled  → default-scheduler  → Successfully assigned default/go-api to devops-lab-control-plane
  Pulled     → kubelet             → Container image "go-api:0.0.2" already present on machine
  Created    → kubelet             → Container created
  Started    → kubelet             → Container started

Mapped to component collaboration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


kubectl apply
 ↓
API Server: receives request, stores in etcd
 ↓
Scheduler: decides which Node → devops-lab-control-plane     ← Scheduled
 ↓
kubelet (on that Node):
 ├── pull image → already present (loaded via kind load)      ← Pulled
 ├── create container                                         ← Created
 └── start container                                          ← Started

Pods Disappear Without a Controller

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


kubectl get pod go-api -o wide
# IP: 10.244.0.5

kubectl delete pod go-api
kubectl get pods
# No resources found — gone forever

kubectl apply -f k8s/pod.yaml
kubectl get pod go-api -o wide
# IP: 10.244.0.6 — IP changed

Two key observations:

Deleting a Pod, nothing will recreate it for you
Re-applying, the Pod gets a different IP

This is why you don’t use bare Pods in production — you need a Deployment to manage them.

Kubernetes Tenant Scope Versus OS Isolation Primitives

Same name, completely different things:

Linux Namespace (from Phase 1 content): kernel-level isolation mechanism (PID, Network, Mount…)
K8s Namespace: logical grouping, like folders classifying resources in a cluster

1
2
3


kubectl get namespaces
# default        ← your Pod lives here
# kube-system    ← K8s internal components

ReplicaSet Driver: Autonomous Replica Guardian

Deployment solves two problems with bare Pods: they’re gone when deleted, and you can’t do zero-downtime updates.

Owner Chain: Deployment → ReplicaSet → Pod

1
2
3
4
5


Deployment (you define: I want 3 go-api instances)
 └── ReplicaSet (auto-created, maintains the count)
      ├── Pod 1
      ├── Pod 2
      └── Pod 3

You only manage the Deployment. ReplicaSet and Pods are managed automatically.

Pod Manifest Referencing the Registry

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-api
spec:
  replicas: 3                    # always maintain 3 Pods
  selector:
    matchLabels:
      app: go-api                # identifies which Pods belong to this Deployment
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                # at most 1 extra Pod during update
      maxUnavailable: 0          # no Pod downtime allowed (zero-downtime)
  template:                      # Pod template
    metadata:
      labels:
        app: go-api
    spec:
      containers:
        - name: go-api
          image: go-api:0.0.2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 50m           # minimum 0.05 CPU cores
              memory: 32Mi       # minimum 32MB memory
            limits:
              cpu: 100m          # maximum 0.1 CPU cores
              memory: 64Mi       # maximum 64MB memory

Everything under template is the spec from the earlier pod.yaml, now wrapped inside the Deployment.

Auto-Generated Naming Convention

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


kubectl get deployment
# go-api

kubectl get rs
# go-api-668dcc5dd                   ← Deployment name + hash

kubectl get pods
# go-api-668dcc5dd-72s9z             ← ReplicaSet name + random suffix
# go-api-668dcc5dd-fbz2q
# go-api-668dcc5dd-zbk6l

You can see the Deployment → ReplicaSet → Pod hierarchy from the names alone.

Convergence Toward Declared Intent

1
2
3
4
5


kubectl delete pod go-api-668dcc5dd-72s9z
kubectl get pods
# go-api-668dcc5dd-5gcng   ← brand new, AGE is seconds
# go-api-668dcc5dd-fbz2q   ← unchanged
# go-api-668dcc5dd-zbk6l   ← unchanged

Completely different from bare Pods — delete one, a replacement is created immediately:

1
2
3
4
5
6
7


one Pod deleted → actual count = 2
 ↓
ReplicaSet detects: desired=3, actual=2, short by 1
 ↓
auto-creates a new Pod to compensate
 ↓
actual count back to 3

This loop runs continuously. No matter how a Pod dies — manual deletion, crash, Node failure — it will be replaced.

Zero-Downtime Image Changes

When updating the image version, the Deployment manages two ReplicaSets simultaneously:

1
2
3
4
5
6
7


Deployment
 ├── ReplicaSet v1 (old version, scaling down)
 │    └── Pod (old)
 └── ReplicaSet v2 (new version, scaling up)
      ├── Pod (new)
      ├── Pod (new)
      └── Pod (new)

maxSurge: 1, maxUnavailable: 0 means: first create the new Pod and confirm Ready, then kill the old Pod — achieving zero downtime.

Production Workflows Use Deployments Directly

In real work, you write Deployments directly:

1

kubectl apply -f k8s/deployment.yaml

Deployment automatically creates ReplicaSet and Pods. No need to write a separate pod.yaml.

Desired-State Configuration Model

K8s core mindset — you write YAML describing “the state I want”, and K8s makes it happen:

1
2
3
4
5
6
7


write YAML (desired state)
 ↓
kubectl apply
 ↓
K8s continuously ensures actual state = desired state
 ↓
need changes → edit YAML → apply again

This is the same mindset as Terraform and Docker Compose, all belonging to Infrastructure as Code (IaC):

Tool	What It Manages
Terraform	Cloud resources (EC2, RDS, VPC…)
Docker Compose	Local multiple containers
K8s YAML	Application deployment in cluster

YAML files go into git, changes are trackable, all infrastructure is defined and managed through code.

Management Commands for the Test Group

A kind cluster is just a Docker container, manageable directly with Docker:

1
2
3
4
5
6
7
8


# pause (state preserved, resumes on next start)
docker stop devops-lab-control-plane

# resume
docker start devops-lab-control-plane

# destroy completely (everything gone, needs full rebuild)
kind delete cluster --name devops-lab

kind doesn’t use Docker Compose. kind creates containers itself using the Docker API.

References

Kubernetes Documentation — Overview — official K8s concept overview
Kubernetes Documentation — Pods — Pod design philosophy and lifecycle
Kubernetes Documentation — Deployments — complete explanation of Deployment, ReplicaSet, and rolling updates
kind — Quick Start — kind installation and usage guide