5.3Kubernetes in 20 minutes: Pod, Deployment, Service
The essentials in 30 seconds
- Three objects, one principle: the Pod wraps containers, the Deployment keeps N identical Pods and updates them, the Service gives a stable address in front of interchangeable Pods.
- You declare, kubectl applies: manifests in YAML, a single apply command — the cluster maintains the desired state (missing Pod = recreated Pod).
- Local lab first: a single local cluster is enough to learn — immutable image tags, never DIY self-hosting in production without a team.
Running mini-case — Idir tries Kubernetes locally
Idir, junior DevOps in Algiers, wants to understand Kubernetes with no cloud and no bill: he creates a local cluster in one command on his machine, applies a Deployment (3 replicas) and a Service there, reaches his app locally, then kills a Pod to watch the Deployment recreate it. Continued from case 5.2 — Idir moves from the Swarm stack to the first Kubernetes deployment.
Continued from case 5.2 — Idir learns on a local cluster before any production idea.
1. Three objects, one principle
The Pod is the envelope of one or more co-located containers; the Deployment keeps N identical Pods and manages their updates; the Service gives a stable address in front of interchangeable Pods that are born and die. Idir remembers the sentence: you reach the stable (Service), not the moving (Pods).
You declare the desired state in YAML (replicas, image, selectors, ports), you apply it with the kubectl client, and the cluster maintains that state: that is the declarative principle.
2. The local lab
No cloud to start: a local cluster created in one command is enough, with kubectl configured on it. Idir applies his manifests there, checks his 3 Pods, reaches the Service locally (port forwarding for dev) — dashboard optional.
In real production, aim for a managed cluster: operating a cluster yourself requires a team. The rule: learn locally, produce managed.
3. Apply, see, expose
Apply the file, list Pods, Deployments and Services, reach locally. Updating = changing the image tag + re-applying: automatic rolling update with possible rollback. Idir kills a Pod and watches its resurrection: the orchestrator maintains the declared state.
Image discipline: immutable tags in YAML, never a moving tag in deployment — otherwise you no longer know what is really running.
🔎 Concrete example — Idir's app with 3 replicas on a local cluster
Declare, apply, reach.
kubectl apply -f deploy.yaml
kubectl get pods
kubectl get deploy
kubectl get svc
kubectl port-forward svc/web 8080:80Reading: 3 Pods behind a stable address, reached locally.
Lesson: killing a Pod makes it reborn — the desired state is maintained.
Section vocabulary
- Pod
- The smallest unit: the ephemeral envelope of one or more containers.
Simple example: Idir watches his Pods born, die and reborn on his local cluster.
What it is not: a stable address to reach durably.
Reflex: am I reaching a Pod or a Service?
- Deployment
- The controller keeping N identical Pods and managing their updates.
Simple example: Idir declares 3 replicas: a killed Pod is recreated.
What it is not: a container launched by hand with no controller.
Reflex: how many replicas have I declared?
- Service
- The stable address in front of interchangeable Pods.
Simple example: Idir reaches the Service, not the moving Pods.
What it is not: the direct address of an ephemeral Pod.
Reflex: what stays stable when Pods move?
- kubectl
- The command-line client driving the cluster.
Simple example: Idir applies, lists and inspects with kubectl.
What it is not: a manual action on each container.
Reflex: is my kubectl pointing at the right cluster?
- Immutable tag
- A fixed image label designating exactly one version.
Simple example: Idir updates by changing tag then re-applying.
What it is not: a moving tag changing content without warning.
Reflex: do I know exactly which version is running?
In practice — Kubernetes locally
- Create a local cluster (one command).
- Apply the Deployment + Service from the template below.
- Check the 3 Pods, reach via port forwarding.
- Kill a Pod and watch its resurrection.
Ready-to-say script — proposing the Kubernetes lab
“To understand Kubernetes without risk, I suggest a local lab in Algiers: one cluster on my machine, one Deployment with 3 replicas and an immutable tag, one Service reached locally. We will see self-healing by killing a Pod — no production touched, no cloud bill.”
Say to the mentor to approve learning locally before any cluster project.
Copy-paste template — generic Deployment + Service
K8S GENERIQUE — fichier deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: mon-registre/mon-app:stable
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 80
COMMANDES : kubectl apply -f deploy.yaml · kubectl get pods · kubectl port-forward svc/web 8080:80Solo / small budget
Idir alone: a free local cluster is enough — 3 replicas, local reach.
Small company / small team
Shared demo: one kills a Pod, the other watches the resurrection.
SME in Algiers
Idir books a workshop in Algiers: everyone applies the manifest on their machine.
Starting team
Pair: one writes the YAML, the other checks selectors and tags before apply.
✓ Best practices
- Learn on a local cluster, produce managed.
- Immutable image tags in YAML.
- Port forwarding for dev, real exposure in production.
✗ Common pitfalls
- Moving tag in a Deployment (you no longer know what is running).
- Tinkered cluster in prod with no team to operate it.
- Confusing ephemeral Pod and stable Service.
Key takeaways
- Pod = ephemeral envelope, Deployment = replicas, Service = stable address.
- You declare in YAML, kubectl applies, the cluster maintains.
- Updating = new tag + re-apply, rollback possible.
- Learn locally, immutable tags, production managed.
48h challenge — apply tomorrow
Apply the generic Deployment + Service (template above) on a local cluster: 3 visible Pods, local reach OK, resurrection after deleting a Pod.
- I can describe Pod, Deployment and Service in one sentence each.
- My local deployment shows 3 Pods behind a Service.
- I know how to update via new tag + re-apply.
Frequently asked questions
Should everything be migrated to Kubernetes after this guide?
No: this level gives the keys to understand and decide. Many apps stay very well on Compose or Swarm — Kubernetes only pays off if the fleet, teams and requirements (autoscaling, multi-teams) justify it.
Which certification to start with after this guide?
Generically: first a Docker-centred certification crowning this guide (images, networks, volumes, Compose, Swarm, security), then a Kubernetes certification if Kubernetes is your target. Both are prepared through hands-on labs, not by heart.
A Pod dies. What does the Deployment do?