CKAD — Understanding Pods

What is a Pod?

A Pod is the smallest deployable unit in Kubernetes. You don’t run containers directly in Kubernetes — you run Pods, and each Pod wraps one or more containers that share the same network namespace and storage volumes.

Think of a Pod as a logical host. Containers inside the same Pod can talk to each other via localhost and share files through volumes. Containers in different Pods communicate over the cluster network.

Why Pods Matter for CKAD

The CKAD exam tests your ability to design, build, and deploy applications on Kubernetes. Pods are the foundation of every workload. This chapter falls under the Application Design and Build domain (20% of the exam).

You need to be fast at:

• Creating Pods imperatively and declaratively
• Attaching labels, selectors, and annotations
• Understanding the Pod lifecycle
• Debugging Pods that are stuck or crashing
• Using ephemeral volumes for data sharing

Single-Container Pods

The most common pattern is a Pod with a single container. This is the standard deployment unit for most applications.

Creating Pods Imperatively

# Create a simple Pod
kubectl run web --image=nginx:1.27

# Create a Pod with a custom port
kubectl run web --image=nginx:1.27 --port=80

# Create a Pod and expose it as a service
kubectl run web --image=nginx:1.27 --port=80 --expose

# Generate YAML without creating the Pod
kubectl run web --image=nginx:1.27 --dry-run=client -o yaml

Creating Pods Declaratively

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80

kubectl apply -f pod.yaml

Basic Pod Operations

# List Pods
kubectl get pods

# Get Pod details
kubectl describe pod web

# Get Pod YAML
kubectl get pod web -o yaml

# Delete a Pod
kubectl delete pod web

# Delete a Pod immediately (force)
kubectl delete pod web --grace-period=0 --force

Multi-Container Pods (Preview)

Some workloads need multiple containers working together inside the same Pod. Kubernetes supports several multi-container design patterns:

Pattern	Purpose	Example
Sidecar	Adds functionality alongside the main container	Log shipper, proxy, config reloader
Init	Runs setup tasks before the main container starts	Database migration, config download
Ambassador	Proxies network connections from the main container	Service mesh proxy, API gateway
Adapter	Transforms output from the main container	Log format converter, metrics adapter

We cover multi-container patterns in detail in Chapter 4: Multi-Container Pods.

Pod vs Deployment

In practice, you rarely create standalone Pods. Instead, you use a Deployment (or Job, CronJob, DaemonSet) to manage Pods.

Feature	Pod	Deployment
Self-healing	No — if a Pod dies, it stays dead	Yes — automatically replaces failed Pods
Scaling	Manual only	Built-in scaling (replicas, HPA)
Rolling updates	Not supported	Built-in rolling updates and rollbacks
Use case	Quick tests, debugging	Production workloads

Exam tip: The CKAD exam often asks you to create standalone Pods for quick tasks. Use kubectl run for speed. For anything that needs to survive failures, use a Deployment.

Pod Networking Basics

Every Pod gets its own IP address. Containers within the same Pod share that IP and can reach each other on localhost.

Pod (10.244.1.5)
├── Container A (port 8080)
├── Container B (port 9090)   ← can reach A via localhost:8080
└── Shared network namespace

Key networking facts for the exam:

• Every Pod gets a unique IP within the cluster
• Containers in the same Pod share the network namespace
• Containers in the same Pod communicate via localhost
• Pods on different nodes communicate via the cluster network (CNI plugin)
• Pod IPs are ephemeral — they change when Pods are recreated

---

Next: Learn how to organize and select Pods using Labels and Selectors →