Pod, Deployment, Service, Namespace: the trinity +1
Summary: these four words come up again and again in any Kubernetes discussion. They must be clearly distinguished. A Pod is the smallest deployable unit (one or more containers). A Deployment manages several identical Pods with progressive updates. A Service gives these Pods a stable address in the cluster. A Namespace logically isolates several teams or environments within the same cluster.
1. The pyramid of Kubernetes objects
Kubernetes has more than 50 native object types. But 95% of what you will encounter at first fits into this pyramid.
Read the pyramid from top to bottom: a Namespace contains Deployments that manage ReplicaSets that contain Pods that contain Containers. A Service is transverse — it routes traffic to the Pods.
2. The Pod — the smallest deployable unit
A Pod is Kubernetes' atomic unit. It is what the cluster deploys, restarts, migrates.
2.1 · Anatomy of a Pod
2.2 · What a Pod looks like in YAML
Here is the simplest possible manifest for a Pod.
apiVersion: v1
kind: Pod
metadata:
name: my-web-server
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
Quick decoding:
| Field | What it tells Kubernetes |
|---|---|
kind: Pod | We are declaring a Pod |
metadata.name | A unique name within the Namespace |
metadata.labels | Labels used for routing |
spec.containers | The list of the Pod's containers |
image: nginx:1.27 | The Docker image to launch |
containerPort: 80 | The port exposed by the container |
BUT BEWARE: in real life, you never create a Pod directly. You always create a Deployment that manages the Pods for you. Why? Because a Pod is not resilient — if it dies, nobody replaces it.
2.3 · Why the Pod concept (and not just container)?
Frequent question: why does Kubernetes add a "Pod" layer on top of the container?
Answer: because in some cases, you want several containers working together as a single unit — the sidecar, ambassador, adapter patterns.
In practice, 80% of Pods in production contain a single container. The multi-container patterns are used in advanced cases (mesh, observability).
3. The Deployment — the real unit you manipulate
A Deployment is the object you create on a daily basis to deploy your application. It manages the Pods for you with two superpowers: scaling and progressive updates.
3.1 · What a Deployment does
3.2 · A Deployment in YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app:v2.5
ports:
- containerPort: 8080
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
Quick decoding:
replicas: 3— Kubernetes maintains 3 Pods permanently.selector.matchLabels— how the Deployment identifies its Pods.template— the template used to create each Pod.resources— the CPU/RAM requests and limits (essential in prod).
One kubectl apply -f deployment.yaml immediately launches the 3 Pods. If one dies, Kubernetes recreates it within 5 seconds.
3.3 · The rolling update workflow
When you change the image from v2.5 to v2.6, here is what happens.
Zero downtime, rollback in one command. That is the magic of a Deployment.
Note: this rolling update is the most common. Kubernetes also supports blue-green, canary, and other more advanced strategies.
4. The Service — the stable address in an ephemeral world
Problem: Pods are disposable and immutable. They change IP at every restart. How does a client reliably find the application?
Solution: the Service.
A Service offers:
- A stable IP address within the cluster.
- A DNS name (
my-app.production.svc.cluster.local). - Native load balancing between the Pods.
- Resilience — if a Pod dies, the traffic is automatically redirected to the living ones.
4.1 · The 4 types of Services
4.2 · The Ingress — the boss of HTTP Services
For a public web application, you generally do not use a direct LoadBalancer — you use an Ingress.
A single Ingress manages all the cluster's HTTP Services, with routing by domain name and by URL path. It is Kubernetes' native reverse proxy.
5. The Namespace — partitioning a cluster
A Namespace is a virtual folder in a Kubernetes cluster. It allows you to partition several teams, environments, or applications within the same cluster.
What a Namespace enables:
- Logical isolation — the same resource names are possible in two different Namespaces.
- Resource quotas — limiting each team to 10 CPUs and 50 GB RAM for example.
- Targeted RBAC — team A has rights on namespace-A only.
- Network policies — filtering who can talk to whom between Namespaces.
2026 best practice: never deploy in default. Always create an explicit Namespace per team, environment or functional domain.
6. Other objects to know (quick overview)
These objects complete the essential Kubernetes palette — explored in depth in the Premium Kubernetes Course.
These objects represent 95% of what you will encounter in production. Kubernetes offers more than 50 in total, but the others are either technical details or specialized extensions.
7. How it all fits together — a complete web application
Here is how these objects fit together in a complete web application.
A real production stack in Kubernetes looks like this: a Namespace containing an application's Deployments, StatefulSets, Services, ConfigMaps and Secrets. All of it described in YAML and versioned in Git.
Remember in 30 seconds
- Pod = the smallest deployable unit — one or more containers sharing an IP and a lifecycle.
- Deployment = the real working unit — manages N identical Pods + rolling updates + rollback.
- Service = stable network address pointing at the Pods (4 types: ClusterIP, NodePort, LoadBalancer, ExternalName).
- Ingress = native HTTP reverse proxy to expose several services on the Internet.
- Namespace = logical partitioning of a cluster between teams or environments.
- ConfigMap / Secret = non-sensitive / sensitive configuration injected into the Pods.
- 95% of use cases fit into these 6 objects.