KCNA — Pods & Containers
Pods & Containers
A Pod is the smallest deployable unit in Kubernetes. It represents a single instance of a running process in your cluster.
What Is a Pod?
| Aspect | Details |
|---|---|
| Definition | A group of one or more containers that share storage and network |
| IP address | Each pod gets its own unique IP address |
| Lifecycle | Pods are ephemeral — they are created, run, and eventually die |
| Managed by | Usually managed by a Deployment or other controller (not created directly) |
Pod vs Container
| Concept | Pod | Container |
|---|---|---|
| What it is | A K8s abstraction — wrapper around containers | A running process with its own filesystem |
| IP address | Gets its own IP | Shares the pod’s IP |
| Managed by | Kubernetes (kubelet) | Container runtime (containerd) |
| Can run alone? | Yes, but not recommended | Must run inside a pod in K8s |
Single-Container Pods (Most Common)
The most common pattern is one container per pod:
apiVersion: v1
kind: Pod
metadata:
name: web-server
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
Best practice: Use one container per pod unless containers absolutely need to share resources. This is the pattern you’ll see in ~95% of real-world deployments.
Multi-Container Pods
Sometimes two or more containers need to work together closely:
┌────────── Pod ──────────┐
│ │
│ ┌──────────┐ ┌────────┐│
│ │ App │ │ Log ││
│ │ Container│ │ Sidecar││
│ │ :8080 │ │ ││
│ └──────────┘ └────────┘│
│ │
│ Shared: IP, volumes │
└──────────────────────────┘
Common Multi-Container Patterns
| Pattern | Description | Example |
|---|---|---|
| Sidecar | Helper container alongside the main container | Log collector, monitoring agent |
| Ambassador | Proxy container that handles external communication | Local proxy to a remote database |
| Init Container | Runs before the main container starts | Database migration, config download |
| Adapter | Transforms output from the main container | Format converter for monitoring data |
Init Containers
| Aspect | Details |
|---|---|
| When they run | Before all regular containers start |
| Success required | All init containers must succeed before regular containers start |
| Run sequentially | Each init container must complete before the next one starts |
| Use cases | Wait for a dependency, download config, run database migrations |
Pod Lifecycle
| Phase | Meaning |
|---|---|
| Pending | Pod accepted but not yet scheduled or image not pulled |
| Running | At least one container is running |
| Succeeded | All containers exited with code 0 (success) |
| Failed | At least one container exited with a non-zero code |
| Unknown | Pod status can’t be determined (usually node communication issue) |
Pending → Running → Succeeded/Failed
│
└──► (if container crashes → restarts within Running phase)
Health Probes
Kubernetes uses probes to check if containers are healthy:
| Probe | What It Checks | What Happens on Failure |
|---|---|---|
| Liveness Probe | Is the container alive? | Container is restarted |
| Readiness Probe | Is the container ready to serve traffic? | Pod is removed from Service endpoints (no traffic) |
| Startup Probe | Has the container started? | Liveness/readiness probes are delayed until startup succeeds |
Probe Methods
| Method | How It Works |
|---|---|
| HTTP GET | Sends HTTP request — success if status code is 200-399 |
| TCP Socket | Tries to open a TCP connection — success if port is open |
| Exec | Runs a command inside the container — success if exit code is 0 |
Resource Requests and Limits
Pods can specify how much CPU and memory they need:
| Setting | What It Does |
|---|---|
| Request | Minimum resources guaranteed to the container. Used by scheduler for placement. |
| Limit | Maximum resources the container can use. Container is throttled (CPU) or killed (memory) if exceeded. |
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Exam tip: Requests affect scheduling (which node the pod lands on). Limits affect runtime (what happens if the container uses too much).
Key Takeaways for the Exam
- A Pod is the smallest deployable unit — not a container
- Each pod gets its own IP address
- Pods are ephemeral — they can be created, destroyed, and replaced at any time
- Single-container pods are the most common pattern
- Multi-container pods share network and storage — containers communicate via localhost
- Init containers run before regular containers and must succeed
- Three health probes: liveness (alive?), readiness (ready for traffic?), startup (started yet?)
- Requests affect scheduling; limits affect runtime behavior
What’s Next?
Pods alone are fragile. Let’s learn how Deployments manage pods at scale.
