Kubernetes / Basic: objects and execution boundaries / Lesson 3

Pods and workload controllers

Choose a workload model from process lifetime, identity, completion, and replacement requirements rather than treating every task as a bare Pod.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the model, assumptions, and boundaries of pods and workload controllers.
Interpret both examples and distinguish declared intent from established evidence.
Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.

A Pod is an execution unit

A Pod groups one or more containers with shared networking and selected storage. Containers in the same Pod can reach one another through its network context, but still have distinct images and process behavior. Group containers when they need a tightly coupled lifecycle, not merely because they belong to the same product. A Pod is disposable and is not a durable machine identity. If its node is lost, a replacement managed by a controller is a new Pod rather than the old instance moving intact. Applications must tolerate connection loss and interrupted work.

Read container lifecycle and initialization

A container can be waiting, running, or terminated, with reasons and exit information that matter more than a single summary label. Init containers can prepare prerequisites before ordinary application containers start. Sidecar-related behavior has version-specific details, so use the selected API documentation rather than assuming every container has identical ordering. The first synthetic timeline separates successful initialization from an application failure. A Pod phase such as Running does not mean every container is ready or that its business work is correct. Keep container name and restart count in the diagnostic context.

text Synthetic multi-container evidence

init/config-check: terminated, exit 0
app/api: terminated, exit 1
app/api safe message: invalid nonsecret setting
owner: synthetic Deployment
interpretation: initialization succeeded; application startup failed

The successful init container does not make the application healthy. Inspect the failing container and its owner template before changing the workload type.

Select the controller by semantics

A Deployment suits interchangeable long-running replicas; a StatefulSet adds stable identity and storage association for workloads designed to use them; a DaemonSet places eligible copies on selected nodes. A Job tracks completion, while a CronJob creates Jobs on a schedule. These controllers do not make a task exactly once or automatically repair application state. The second record compares a web API with an idempotent batch task. Choose based on completion, identity, storage, and recovery needs. A StatefulSet is not a substitute for database replication, consistency design, or backups.

text Synthetic controller selection

workload             intended controller     required application property
interchangeable API  Deployment              safe concurrent replicas
nightly report       CronJob -> Job          idempotent resumable output
node log agent       DaemonSet               narrow node access
identity-bound data  StatefulSet             designed storage and recovery

Controller choice follows workload semantics. The table does not promise exactly-once jobs, automatic database safety, or permission to install a node agent.

Design replacement and completion safely

A process can finish just before its completion evidence reaches the controller, and clients or controllers can retry. Batch logic therefore needs idempotency or deduplication where repeated effects matter. Scheduled tasks also need an explicit policy for overlap, missed schedules, timezone, and late starts. Keep durable checkpoints outside a disposable writable layer. For long-running workloads, define graceful termination and admission behavior so replacement does not cut off every accepted operation. Controller defaults are implementation mechanisms; they cannot infer how to reconcile an external payment or a partially published message.

Keep the specification and the evidence distinct

Review the Pod template used by the owning workload rather than editing one generated Pod as a lasting repair. The controller can replace that edit from its template. A status snapshot should include owner, template revision, node, container state, and time, with sensitive fields redacted. Compare intended behavior with observed restart and completion evidence before changing policies. All lifecycle records in this lesson are fictional and no workload is started. A correct workload choice makes replacement predictable; it still needs measured resources, appropriate access, observable outcomes, and a tested recovery plan.

Common errors and fixes

A bare Pod is expected to recover forever

Why it happens: No workload controller owns replacement.
How to fix it: Choose an appropriate reviewed controller model.
Prevent it next time: Document owner and replacement semantics.

A Job duplicates an external effect

Why it happens: Task retry was assumed to mean exactly-once execution.
How to fix it: Use idempotency, checkpoints, and reconciliation.
Prevent it next time: Test interruption near completion boundaries.

Editing one Pod does not persist

Why it happens: The controller recreates its declared template.
How to fix it: Repair the reviewed owner template instead.
Prevent it next time: Trace owner references before diagnosis.

Check your understanding

1. A report may run again after interruption. Which controller and application behavior fit?

Show worked solution

Use Job for completion or CronJob for scheduled creation, with an idempotent output identity and resumable work. Controller retries are not deduplication. Verify that a second attempt observes the prior result instead of publishing the same external effect twice.

2. Does StatefulSet make a database safe after node loss?