Pods In Depth

Up to this point, every Pod you have created runs a single container. That is the common case — but it is not the only case, and the CKAD exam knows it. The Workloads & Scheduling domain accounts for 15% of the exam score, and a significant portion of those points tests whether you can work with Pods that go beyond the single-container default.

A Pod is not a container. It is a scheduling unit that wraps one or more containers sharing the same network namespace, the same set of volumes, and the same lifecycle. When Kubernetes schedules a Pod, every container in that Pod lands on the same node, communicates over localhost, and can mount the same emptyDir or PersistentVolume. This shared context enables patterns that would be awkward or impossible with standalone containers.

What Gets Tested

The exam tests Pod-level features in several forms:

• Init containers — a task might require you to add a container that runs before the main application starts, pre-populating a shared volume or verifying that a database endpoint is reachable.
• Multi-container patterns — a task might present a Pod with a main application container and ask you to add a sidecar that ships logs to a remote collector, or an adapter that converts custom metrics into a standard format.
• Lifecycle hooks — a task might require a preStop hook that drains connections before the container receives SIGTERM, or a postStart hook that runs a registration script.
• Resource management — a task might specify exact CPU and memory requests and limits, and you need to know where those fields go, what units to use, and what happens when a container exceeds its limits.

Each of these features operates at the Pod level — not the Deployment level, not the Service level. They live inside spec.containers, spec.initContainers, and spec.containers[*].resources. Getting them right means understanding the Pod spec at a granular level.

What This Chapter Covers

The sections that follow divide Pod internals into two focused areas:

1. Init Containers and Multi-Container Patterns — how init containers run sequentially before your application starts, and the three established multi-container patterns (sidecar, ambassador, adapter) with complete YAML examples and a visual diagram showing how containers interact within a Pod.

2. Lifecycle Hooks and Resource Management — the container lifecycle state machine (Waiting → Running → Terminated), postStart and preStop hooks with their interaction with terminationGracePeriodSeconds, resource requests vs. limits in CPU millicores and memory bytes, and the three QoS classes that determine eviction priority.

Master these Pod-level features and you can handle any task the exam throws at you that involves configuring what happens inside a Pod — before, during, and after your application runs.