Pods and Deployments

6 pages · ~4 min✓ Reviewed

Start here. Next up: Services and Ingress.

KubernetesPage 1

Cluster Architecture: Control Plane and Nodes

1. Components

Where	Component	Job
Control plane	`kube-apiserver`	only front door; all talk through it
Control plane	`etcd`	key-value store of all cluster state
Control plane	`kube-scheduler`	picks a node for unassigned Pods
Control plane	`kube-controller-manager`	control loops: actual → desired
Node	`kubelet`	keeps assigned Pods' containers running
Node	`kube-proxy`	programs Service routing rules
Node	container runtime	containerd or CRI-O runs containers

2. The declarative loop

Submitdesired state to API
Storein etcd
Watchcontrollers fix drift
Bindscheduler picks node
Startkubelet runs Pod

Control plane decides and stores; workers run app Pods
Only the API server reads and writes etcd
kubelet reports node and Pod status to the API server

3. Check and gotcha

bash

kubectl get nodes
kubectl get pods -n kube-system

No etcd backup

Lose etcd, lose all cluster state. Running Pods keep running until their node fails.

KubernetesPage 2

Pods: The Smallest Deployable Unit

1. What a Pod is

A Pod wraps 1+ containers with one Pod IP
Containers talk over localhost, can share volumes
Multi-container: coupled helpers (sidecars)
You schedule Pods, not containers
Ephemeral: replaced Pod = new name, new IP
Never depend on a Pod IP

2. Lifecycle

Pending: awaiting node or pulling images
Running: containers started
Succeeded / Failed: finished OK / error
restartPolicy: Always, OnFailure, Never

3. Minimal manifest

yaml

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
  - name: web
    image: nginx

add ports: [{containerPort: 80}] under the container

Apply: kubectl apply -f pod.yaml
Quick: kubectl run web --image=nginx

4. Common mistakes

Bare Pods in production: nothing recreates them if the node dies
No resource requests or limits
Using the latest tag

Failure states

ImagePullBackOff, CrashLoopBackOff, Pending: run kubectl describe pod and read the Events.

KubernetesPage 3

ReplicaSets and Deployments

1. Chain of Control

ReplicaSet: keeps spec.replicas identical Pods running
Matches Pods by selector.matchLabels
Deployment adds rolling updates and rollback
Pod template change = new ReplicaSet; old ones kept

Deploymentupdates, rollback
ReplicaSetkeeps N Pods
Podsrun the app

2. Bare Pod vs ReplicaSet vs Deployment

	Self-healing	Scaling	Rolling update	History
Bare Pod	No	No	No	No
ReplicaSet	Yes	Yes	No	No
Deployment	Yes	Yes	Yes	Yes

Stateless apps: use Deployments

3. Manifest and Scaling

yaml

apiVersion: apps/v1
kind: Deployment
metadata: {name: web}
spec:
  replicas: 3
  selector: {matchLabels: {app: web}}
  template:
    {metadata: {labels: {app: web}}, spec: {containers: [{name: nginx, image: nginx}]}}

metadata.name is required

kubectl create deployment web --image=nginx --replicas=3
kubectl scale deploy web --replicas=5
Set replicas in Git, not by hand-editing live objects

Selector must match

selector.matchLabels must equal template.metadata.labels, or the API rejects it. The selector is immutable.

KubernetesPage 4

Rolling Updates, Rollbacks and kubectl Essentials

1. Rolling Update vs Recreate

New ReplicaSet scales up, old one scales down
maxSurge: extra Pods allowed, default 25%
maxUnavailable: Pods allowed down, default 25%
Only a Pod template change rolls out; scaling doesn't

	RollingUpdate	Recreate
Downtime	none	yes
Versions	both at once	old killed first
Use for	default	apps needing one version

2. Update, Watch, Roll Back

Update: set image or apply -f, then rollout status
history lists revisions; undo goes back one, --to-revision=N picks
rollout pause / resume batch changes
revisionHistoryLimit default 10 old ReplicaSets

bash

kubectl set image deploy/web nginx=nginx:1.27
kubectl rollout status deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web --to-revision=2

3. Mistakes and Debug Order

No readiness probe: bad image still looks successful
Forgot -n <namespace>: wrong namespace
Debugging out of order

getkubectl get
describeEvents
logs--previous after crash
exec-it pod -- sh

KubernetesPage 5

Kubernetes Core Cheat Sheet

1. Architecture

Part	Runs
Control plane	apiserver, etcd, scheduler, controller-manager
Node	kubelet, kube-proxy, container runtime

Deployment
ReplicaSet
Pod

2. Daily kubectl

bash

kubectl get pods -o wide
kubectl describe pod <p>
kubectl logs <p> -f
kubectl exec -it <p> -- sh
kubectl get all -n <ns>
kubectl apply -f file.yaml
kubectl create deploy web --image=nginx
kubectl scale deploy web --replicas=5

bash

kubectl set image deploy/web nginx=nginx:1.27
kubectl delete -f file.yaml
kubectl rollout status|history|undo|pause|resume deploy/web
kubectl rollout undo deploy/web --to-revision=N

Rollout trigger

Only a Pod template change starts a rollout.

3. Defaults and Troubleshooting

State	Cause
Pending	no node fits, or not scheduled yet
ImagePullBackOff	wrong image or registry credentials
CrashLoopBackOff	app crashes: `logs --previous`

maxSurge 25%, maxUnavailable 25%, revisionHistoryLimit 10
Add -n <ns> or -A to every query
kubectl explain <resource>.spec shows field docs
Deployment YAML needs metadata.name

KubernetesPage 6

Check yourself

A Deployment has selector.matchLabels: {app: web} but its template labels are {app: api}. What happens on apply?

The API rejects it.
The selector must match the template labels, or the ReplicaSet could never own its Pods.

You run kubectl scale deploy web --replicas=5. Does rollout history gain a revision?

No.
Only a Pod template change triggers a rollout; the same ReplicaSet just scales to 5.

A Pod is in CrashLoopBackOff. Which command shows why the last run died?

kubectl logs <pod> --previous
Plain logs may show only the fresh restart; describe pod adds the Events.