1.1 Chapter 1 · Pods & Containers

What is a Pod?

The smallest thing Kubernetes knows about. Everything starts here.

5 min read Beginner CKA · CKAD

Before you can understand Kubernetes, you need to understand Pods. Not because they are complicated they are not but because they are the atomic unit of everything. When you ask Kubernetes to run something, it always runs it inside a Pod.

Think of Kubernetes as a city. Containers are people. And Pods are apartments. A person does not just wander the city they live somewhere. That somewhere gives them an address, shared walls, shared utilities. Containers in Kubernetes work the same way: they live inside Pods, and the Pod gives them a shared network and shared storage.

🐳

Container

Your application.
Runs one process.

⊂

📦

Pod

The wrapper.
Gives containers a home.

Here is the key insight that trips people up early: you almost never create containers directly in Kubernetes. You create Pods. The Pod creates the containers. This indirection is intentional it lets Kubernetes manage scheduling, networking, and restarts at the Pod level without caring what is inside.

Think about it this way

When you run kubectl get pods, you are seeing a list of apartments. Each apartment might have one tenant (most common) or several (multi-container pods). But you never see the tenants directly only the apartments.

A Pod has exactly one IP address, shared by all containers inside it. If you have two containers in the same Pod, they can talk to each other using localhost no service, no DNS, just localhost. This is the most important thing to remember about Pod networking.

Pods are also ephemeral. This is a word Kubernetes people love, and it just means temporary. Pods are designed to die and be replaced. They are not pets. They are cattle. When a Pod dies, Kubernetes creates a new one with a new IP, a new name, a fresh start. This is why you never store important data inside a Pod without a proper Volume. More on that in the Storage chapter.

Common mistake

New engineers often SSH into a Pod to fix something, then wonder why the fix disappeared. When Kubernetes restarts the Pod (which it will), everything inside is gone. The only way to make a change stick is to change the image or the configuration not the running container.

Quick check

Two containers are in the same Pod. How do they communicate with each other?

1.2 Chapter 1 · Pods & Containers

Inside a Pod

What actually lives inside that little box, and why it matters.

6 min read Beginner CKA · CKAD

A Pod is not magic. It is a spec a description of what should run. Kubernetes reads that spec, picks a node, and makes it happen. But what exactly is inside that spec?

Every Pod has three things worth understanding: containers, volumes, and metadata. Containers are the processes you want to run. Volumes are shared storage that containers in the same Pod can access. Metadata is how you find the Pod later its name, namespace, and labels.

Real example

Imagine a web application that generates PDF reports. The main container runs the web server. A second container (a sidecar) watches a shared folder and uploads any new PDFs to S3. Both containers share a volume the main container writes, the sidecar reads and uploads. They never need to talk over the network because they share the same filesystem.

Let's look at what Kubernetes actually gives a Pod when it starts:

A unique IP address assigned from the cluster's pod CIDR range. This IP is only reachable from inside the cluster.
A hostname by default, the Pod's name. Containers inside can resolve each other by using localhost.
Environment variables injected at startup, often from ConfigMaps or Secrets.
Mounted volumes directories that can be shared between containers or persisted beyond the Pod's lifetime.
Resource limits how much CPU and memory the container is allowed to use.

The pause container

Here is something most tutorials skip: every Pod actually runs a hidden container called the pause container. You will never see it in your YAML, but it is always there. Its only job is to hold the network namespace open. All the other containers in the Pod join that network namespace, which is why they all share the same IP and can use localhost.

If you SSH into a node and run crictl ps, you will see one pause container per Pod. Do not touch it. It is Kubernetes infrastructure.

Mental model

Think of the pause container as the building frame. It defines the address (IP). All your application containers are tenants who move into that frame. The frame stays up even if a tenant moves out and back in the address never changes mid-Pod-lifetime.

One more thing that trips people up: containers inside a Pod do not share their filesystems by default. Each container has its own isolated filesystem from its image. The only way two containers share files is through a shared Volume that both mount. This is intentional it keeps containers isolated while still allowing cooperation through explicit mounts.

Quick check

Container A and Container B are in the same Pod. Container A writes a file to /tmp/output.txt. Can Container B read it?

1.3 Chapter 1 · Pods & Containers

Pod Lifecycle

Pods are born, they run, they die. Understanding this cycle saves you hours of debugging.

7 min read Beginner–Intermediate CKA

Every Pod you create goes through a predictable journey. Knowing this journey means you can look at a Pod's status and instantly understand what is happening and what to do about it.

🌱

Pending

Accepted but not
placed on a node yet

→

⚡

Running

On a node, at least
one container active

The five phases you will see in kubectl get pods:

Pending Kubernetes accepted the Pod but has not placed it on a node yet. Usually because no node has enough resources, or the image is being pulled.
Running The Pod is on a node and at least one container is running. This does not mean your app is healthy just that the container process started.
Succeeded All containers exited with code 0. Common for batch jobs.
Failed At least one container exited with a non-zero code and won't restart.
Unknown Kubernetes lost contact with the node. Usually a node networking problem.

Container states vs Pod phases

The Pod phase is a summary. What you really want to look at is the container state. A Pod can be Running while a container inside it is Waiting or Terminated. This is one of the most common sources of confusion.

Container states:

Waiting The container has not started yet. Check the reason: ContainerCreating, ImagePullBackOff, CrashLoopBackOff.
Running The container process is alive.
Terminated The container exited. Check the exit code. 0 means success. 137 means OOMKilled (out of memory). 1 means application error.

CrashLoopBackOff explained

This is not a status it is Kubernetes telling you: the container keeps crashing and I keep restarting it, but I'm backing off exponentially so I don't thrash the node. The backoff starts at 10 seconds, doubles each time, up to 5 minutes. To debug it: kubectl logs <pod> --previous the --previous flag shows you logs from the crashed instance, not the currently restarting one.

Restart policies control what happens when a container exits:

Always (default) Kubernetes always restarts it. Good for long-running services.
OnFailure Only restarts on non-zero exit. Good for batch jobs that should retry on error.
Never No restarts. Good for one-shot jobs.

Debugging workflow

Pod not healthy? Follow this order:

1. kubectl get pods see the phase and restart count
2. kubectl describe pod <name> read the Events section at the bottom
3. kubectl logs <name> --previous see why it crashed
4. kubectl get events --sort-by=.metadata.creationTimestamp cluster-wide view

Quick check

A container exits with code 137. What most likely happened?

1.4 Chapter 1 · Pods & Containers

Writing Pod YAML

Your first real YAML. Every field explained like it matters because it does.

8 min read Hands-on CKA · CKAD

YAML is how you talk to Kubernetes. Every resource Pods, Deployments, Services is described in YAML. Most beginners either avoid it (using only imperative kubectl commands) or copy-paste it without understanding it. Both approaches will eventually break you on the exam and in production.

Let's build a Pod manifest from scratch, line by line.

pod.yaml
# Every K8s resource starts with these four fields
apiVersion: v1          # Pod is in the core API group
kind:       Pod         # what we are creating
metadata:
  name:      my-app     # unique name within the namespace
  namespace: default    # omit this to use current context namespace
  labels:
    app:     my-app     # how Services find this Pod
    env:     production
spec:
  containers:
  - name:  app           # container name (not the image name)
    image: nginx:1.25   # always pin a version, never use :latest in prod
    ports:
    - containerPort: 80 # informational only   does not expose the port
    resources:
      requests:         # what the scheduler uses to place the Pod
        cpu:    "100m"  # 100 millicores = 0.1 of one CPU core
        memory: "128Mi"
      limits:           # hard ceiling   container is killed if it exceeds this
        cpu:    "500m"
        memory: "256Mi"

A few things worth understanding deeply here:

labels are how everything finds everything in Kubernetes. Services select Pods by label. Deployments manage Pods by label. Get comfortable writing them and querying them.
containerPort is purely documentation. It does not open a firewall rule or expose anything. The container's process itself opens the port this field just helps humans understand what port the app uses.
requests vs limits requests are what the scheduler uses to decide which node has room. Limits are the hard ceiling. A container that exceeds its memory limit gets OOMKilled. One that exceeds CPU is throttled (slowed down, not killed).

Why "100m" for CPU?

CPU in Kubernetes is measured in millicores. 1000m = 1 CPU core. So 100m means "10% of one core". This granularity lets you pack many small workloads onto the same node efficiently. Memory uses the standard binary suffixes: Ki, Mi, Gi.

Now apply it and check it:

terminal
# Apply the manifest
kubectl apply -f pod.yaml

# Watch it start up
kubectl get pod my-app -w

# See all the details (events are at the bottom)
kubectl describe pod my-app

# Generate a base YAML instead of writing from scratch
kubectl run my-app --image=nginx:1.25 --dry-run=client -o yaml > pod.yaml

Exam shortcut

kubectl run --dry-run=client -o yaml is the fastest way to generate valid Pod YAML on the exam. Generate it, then edit the fields you need to change, then apply. This saves 3 to 4 minutes per task compared to writing YAML from scratch.

Quick check

A container has memory limit 256Mi. It starts consuming 300Mi. What happens?

1.5 Chapter 1 · Pods & Containers

Multi-Container Pods

When one container is not enough. The patterns that show up on every CKA and in every production cluster.

8 min read Intermediate CKA · CKAD

Most Pods run one container. But Kubernetes supports multiple containers per Pod, and there are three patterns every engineer should know by name. These patterns appear on the CKA exam and in real production clusters everywhere.

Before we go through the patterns, there is one question that comes up constantly in the CKA community and genuinely confuses people so let's clear it up first.

The confusion that trips everyone up

Are sidecars the same as init containers?

In Kubernetes 1.29+, the official docs introduced a new pattern: you can now declare a sidecar as an initContainer with restartPolicy: Always. This confused a lot of people including engineers actively studying for the CKA.

Here is the mental model that makes it click:

Classic init containers run to completion before the main container starts. They do one job and exit. Think: "download this config file, then exit 0."

Sidecar containers (the new native kind) run alongside the main container for the entire Pod lifetime. They never exit on their own. Think: "keep shipping these logs forever."

The fact that sidecars are technically declared under spec.initContainers with restartPolicy: Always is an implementation detail. On the CKA exam, if the spec has a container running an infinite loop (while true; do ...; done), that is a sidecar. If it runs to completion, that is a classic init container.

Pattern 1 Sidecar

A sidecar runs alongside the main container for the full lifetime of the Pod. It enhances the main container without modifying it. The main container does its job the sidecar adds a capability on top.

Real examples: a log shipper tailing the app's log file and forwarding to Elasticsearch. A certificate rotator watching for expiring TLS certs. An Envoy proxy handling all outbound traffic (this is exactly how Istio works).

sidecar-pod.yaml   native sidecar (K8s 1.29+)
spec:
  initContainers:
  - name: log-reader          # declared here, but runs like a sidecar
    image: busybox
    restartPolicy: Always   # this is what makes it a native sidecar
    command:
    - sh
    - -c
    - "tail -f /var/log/app.log"  # infinite   never exits on its own
    volumeMounts:
    - name: logs
      mountPath: /var/log
  containers:
  - name: main-app
    image: myapp:1.0
    command:
    - sh
    - -c
    - "while true; do date >> /var/log/app.log; sleep 5; done"
    volumeMounts:
    - name: logs
      mountPath: /var/log
  volumes:
  - name: logs
    emptyDir: {}

Pattern 2 Init Container

An init container runs before the main container starts and must succeed before the main container is allowed to begin. It runs once, completes, and exits. This is perfect for setup tasks: waiting for a database, running migrations, downloading config.

Init containers are defined under spec.initContainers. They run in order, one at a time. If one fails, Kubernetes restarts the Pod.

pod-with-init.yaml
spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command:             # array form   safer than inline sh -c
    - sh
    - -c
    - "until nc -z postgres 5432; do echo waiting; sleep 2; done"
    # no restartPolicy here   classic init, runs to completion
  containers:
  - name: app
    image: myapp:1.0    # only starts after wait-for-db exits 0

The sh -c question everyone asks

When you write a command like "while true; do date; sleep 5; done", you have two ways to put it in YAML:

Inline (single string): command: ["sh", "-c", "while true; do date; sleep 5; done"]

Array form (recommended):
command:
  - sh
  - -c
  - "while true; do date; sleep 5; done"

Both work. The array form is safer because YAML quoting rules can bite you with inline strings containing special characters. On the exam, the array form is less likely to fail due to indentation or quoting errors.

The exam dry-run trick

On the CKA, when you need to create a Pod with a complex multi-container spec, do not write the YAML from scratch. Use this workflow it saves 3 to 4 minutes and avoids syntax errors:

terminal   exam workflow
# Step 1: generate the main container YAML with a placeholder command
kubectl run main-app --image=busybox --dry-run=client -o yaml \
  --command -- sleep 1000 > pod.yaml

# Step 2: open the file and replace the placeholder with the real command
# Change:  command: ["sleep", "1000"]
# To:      command: ["sh", "-c", "while true; do date >> /var/log/app.log; sleep 5; done"]

# Step 3: add the initContainers section manually above containers:
#   initContainers:
#   - name: log-reader
#     image: busybox
#     restartPolicy: Always   # sidecar
#     command: ["sh", "-c", "tail -f /var/log/app.log"]

# Step 4: apply
kubectl apply -f pod.yaml

How to decide: sidecar or init?

Read the command the exam gives you. Ask: does this container need to keep running?

If the command is an infinite loop (while true, tail -f, a server process) it is a sidecar. Declare it under initContainers with restartPolicy: Always.

If the command runs once and exits (nc -z to check a port, wget to download a file, a database migration script) it is a classic init container. Declare it under initContainers without restartPolicy.

The fact that a container with an infinite loop could technically reach a natural completion point is irrelevant. If the spec intends it to run forever, treat it as a sidecar.

Pattern 3 Ambassador

An ambassador container acts as a proxy between the main container and the outside world. The main container only ever talks to localhost. The ambassador handles routing, retries, auth, and TLS to the real destination. This way you add complexity without touching the application code at all.

Modifying a running Pod's containers

The CKA often asks you to add an init container to an existing running Pod. You cannot kubectl edit a running Pod's container spec Kubernetes will reject it. The correct approach:

kubectl get pod <name> -o yaml > pod.yaml
Edit the file, then:
kubectl replace --force -f pod.yaml

The --force flag deletes and recreates the Pod. It will have a new IP and new start time, but the spec will be correct. This is the accepted exam technique.

Quick check

The exam asks you to add a container named "log-reader" that runs "tail -f /var/log/app.log". Where do you declare it and what restartPolicy?

🎉

Chapter 1 Complete

You now understand Pods at a level most engineers take months to reach. Networking, Storage and Security chapters are coming next.