Pod Fundamentals

The smallest deployable unit in Kubernetes. Understanding Pods is foundational — everything in K8s (Deployments, ReplicaSets, DaemonSets) ultimately manages Pods. Source: CKA Day 25

Source: CKA Day 7 — Pod Explained

What is a Pod?

A Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in your cluster.

Multi-Container Pods

A Pod can contain one or more containers that share:

• Network namespace (same IP address and port space)
• Storage volumes (shared filesystems)
• Linux namespaces (ipc, uts)

Containers in the same Pod are always co-located and co-scheduled on the same node.

Best practice: Use 1 container per Pod, except for sidecar patterns (logging, proxy, git sync).

Imperative vs Declarative

Imperative (kubectl commands)

Directly manage resources via CLI — fast for experiments, not reproducible.

Command	Purpose
kubectl run nginx --image=nginx	Create a Pod
kubectl get pods	List pods
kubectl get pods -o wide	List with node/IP details
kubectl describe pod nginx	Detailed pod info
kubectl delete pod nginx	Delete a pod
kubectl exec -it nginx -- /bin/sh	Interactive shell
kubectl logs nginx	View logs
kubectl logs nginx --previous	View logs from previous container instance (post-crash)
kubectl logs nginx -c sidecar	View logs from a specific container in a multi-container Pod

Declarative (YAML manifests)

Define desired state in YAML — version controlled, auditable, GitOps-friendly.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: web
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

kubectl apply -f pod.yaml
kubectl delete -f pod.yaml

Key YAML Fields

Field	Description
apiVersion	API version (v1 for Pod)
kind	Object type (Pod, Deployment, Service, etc.)
metadata	Identification data (name, namespace, labels, annotations)
spec	Desired state specification
spec.containers	Containers to run in the Pod
spec.containers[].name	Container name
spec.containers[].image	Docker image
spec.containers[].ports	Exposed ports
spec.containers[].resources	CPU/memory requests and limits for scheduling and runtime guardrails
spec.serviceAccountName	The ServiceAccount identity this Pod uses for API server authentication (defaults to default)
spec.volumes	Volumes available to all containers in the Pod (emptyDir, hostPath, PVC, ConfigMap, Secret)
spec.containers[].volumeMounts	Mounts a named volume into a container filesystem path

Resource Requests and Limits

Each container can declare resource requests and limits. Requests tell the scheduler how much CPU/memory to reserve when placing the Pod on a node. Limits cap runtime consumption; if a container exceeds its memory limit, it is killed with OOMKilled rather than exhausting the whole node. This is why resource settings belong under spec.containers[], not at the Pod root. Source: CKA Day 16

Pod Lifecycle

Phase	Description
Pending	Accepted by cluster, containers not yet running
Running	Bound to node, at least one container running
Succeeded	All containers terminated successfully
Failed	All containers terminated, at least one failed
Unknown	State cannot be determined

Pod IP Ephemerality

Every Pod receives a unique internal IP address. However, this IP is not stable — it changes on every restart, reschedule, or replacement.

# Original Pod IP
kubectl describe pod nginx-deploy-abc123 | grep IP
# IP: 10.244.1.2
 
# Delete and recreate the Pod
kubectl delete pod nginx-deploy-abc123
 
# New Pod gets a different IP
kubectl describe pod nginx-deploy-def456 | grep IP
# IP: 10.244.2.3

This is why Services are critical: they provide a stable virtual IP and DNS name that front a dynamic set of Pod backends. Front-end Pods should talk to back-end Pods via a Service (backend-svc:8080), never by hardcoding Pod IPs. Source: CKA Day 9

Multi-Container Example

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
  - name: sidecar
    image: busybox
    command: ['sh', '-c', 'echo Hello from sidecar && sleep 3600']

YAML Tips

• Indentation matters — use spaces, never tabs
• Validate before applying: kubectl apply --dry-run=client -f file.yaml
• Explore fields: kubectl explain pod.spec

Production Note: You almost never deploy bare Pods in production. Pods are managed by higher-level controllers like Deployments and ReplicaSets, which provide self-healing, scaling, and rolling updates. Source: CKA Day 8

CKA Relevance

The CKA exam heavily tests both imperative speed and declarative reproducibility:

• Create, debug, and modify Pods quickly under time pressure
• Write YAML manifests from memory
• Understand Pod networking and multi-container patterns
• Know that Deployments manage ReplicaSets, which manage Pods

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: Create a Basic Nginx Pod You are asked to create a Pod named nginx running image nginx:alpine and exposing port 80. Requirements: Use an imperative command; verify the Pod is Running. Verification: kubectl get pod nginx Solution:

kubectl run nginx --image=nginx:alpine --port=80

Task 2: Multi-Container Pod with Shared Volume You are asked to create a Pod named web-log with two containers: an nginx container and a busybox sidecar. Both must share an emptyDir volume mounted at /var/log/nginx so the sidecar can read nginx logs. Requirements: Use --dry-run=client -o yaml, edit the manifest to add the second container and volume, then apply. Verification: kubectl get pod web-log and kubectl exec web-log -c sidecar -- ls /var/log/nginx Solution:

kubectl run web-log --image=nginx --dry-run=client -o yaml > web-log.yaml
# Edit web-log.yaml to add the busybox sidecar and an emptyDir volume at /var/log/nginx
kubectl apply -f web-log.yaml

Task 3: Fix a Broken Pod Image A Pod named broken-app was created with image nginx:999 and is stuck in ImagePullBackOff. Fix it to use nginx:latest. Requirements: Edit the live object directly; do not delete and recreate. Verification: kubectl get pod broken-app shows Running. Solution:

kubectl set image pod/broken-app broken-app=nginx:latest
# or: kubectl edit pod broken-app

Task 4: Export, Edit, and Re-apply a Pod You are asked to export the running Pod nginx to YAML, change its image to nginx:1.25, and re-apply the manifest. Requirements: Use kubectl get with -o yaml, redirect to a file, edit the image field, then apply. Verification: kubectl get pod nginx -o jsonpath='{.spec.containers[0].image}' Solution:

kubectl get pod nginx -o yaml > nginx-updated.yaml
# Edit the image field to nginx:1.25
kubectl apply -f nginx-updated.yaml --force

Related Pages

• Multi-Container Pods — Deep dive into sidecar, init, adapter, and ambassador patterns
• Init Containers — Setup and validation containers that run before the main app
• Sidecar Pattern — Auxiliary containers for logging, monitoring, and proxying
• Kubernetes Environment Variables — ConfigMap, Secret, and literal injection
• Kubernetes ConfigMaps and Secrets — Decoupling configuration from container images
• Pod Commands and Arguments — Overriding ENTRYPOINT and CMD
• Kubernetes Services — Stable networking for ephemeral Pods
• Kubernetes Service Types — How to expose Pods externally
• Deployment, ReplicaSet & Replication Controller — The controllers that manage Pod lifecycle
• Kubernetes DaemonSet — Node-level Pod placement for agents and monitoring
• Kubernetes Jobs — Finite batch tasks that run Pods to completion
• Kubernetes CronJobs — Scheduled batch workloads
• Kubernetes Namespaces — Scope isolation for Pods and workloads
• Kubernetes Architecture — How kubelet and the scheduler manage Pods
• Kubernetes Static Pods — Node-local Pods managed directly by kubelet
• Kubernetes Manual Scheduling — Bypassing the scheduler with nodeName and nodeSelector
• Kubernetes Taints and Tolerations — Negative scheduling constraints and node isolation
• Kubernetes Node Affinity — Advanced positive scheduling with rich operators and soft/hard constraints
• Kubernetes Labels and Selectors — Metadata and query system for Pods
• Kubernetes Resource Requests and Limits — CPU/memory requests, limits, Metrics Server, and OOMKilled troubleshooting
• Kubernetes Autoscaling — Pods are the unit that HPA and VPA scale
• Horizontal Pod Autoscaler (HPA) — scales Pod replica counts based on utilization
• Vertical Pod Autoscaler (VPA) — adjusts CPU/memory per Pod
• Kubernetes Health Probes — Liveness, readiness, and startup probes for container health
• Kubernetes Logging and Monitoring — kubectl logs, node-level logs, and Metrics Server for Pod troubleshooting
• Kubernetes Application Troubleshooting — systematic debugging of Pod failures, crash loops, and events-first diagnosis
• Kubernetes Service Account — Pod identity, token mounting, and RBAC for in-cluster API access
• Kubernetes Storage — emptyDir, hostPath, and PVC volume mounts
• CKA Certification — Exam structure and domains

---

Tags: kubernetes pod workload yaml cka devops containers