The smallest thing Kubernetes runs: one or more containers that live and die together.
Your win: explain what a Pod is, why it's the unit (not the container),
what "shares a network and storage" means, and why Pods are ephemeral — the fact
that motivates every controller in Lesson 4.
The unit isn't the container — it's the Pod
Kubernetes never schedules a bare container. It schedules a Pod: one or
more containers that are always placed on the same node and treated as a single
unit.1 Most Pods here hold exactly one app container
(your build/server from Course 1), but the Pod is still the wrapper.
What the containers in a Pod share
Containers in one Pod share a network namespace — one IP address, one port
space, so they reach each other over localhost — and can share
storage volumes. That's the whole reason to co-locate containers in a Pod:
they're tightly coupled helpers (a sidecar next to the main app), not independent services.
Separate services go in separate Pods.
Pods are ephemeral — this is the point
A Pod is disposable. It has no self-healing of its own: if its node dies, the Pod
is gone — it is not resurrected, moved, or rescheduled by itself.1
Its IP is temporary too. This sounds fragile, and on its own it is:
Never run bare Pods in production
A Pod you create directly stays dead when it dies. You almost always want a
controller (a Deployment or StatefulSet, Lesson 4 & 7) to own the Pod, so the
reconcile loop from Lesson 1 replaces it. The Pod's ephemerality is exactly why
those controllers exist — and why you talk to Services (Lesson 5) by name instead of chasing
Pod IPs.
What's inside a Pod spec (the parts you'll meet)
containers — the app image + its command/args, ports, env,
volume mounts, probes, resources (Lesson 8).
initContainers — run to completion before the app containers
start; used for setup/waiting.
volumes — storage made available to the containers (Lesson 6).
Anchor — a Pod in this repo
You never write a Pod directly here — the library chart's container template
(deployments/helm/libs/util/templates/_workload_containers.tpl)
defines the Pod's container: the build/server image, the gserver
<svc> command, a secrets volume mount (:47-50), the
grpc_health_probe readiness/liveness probes (:76-142), and resources
(:145-146). And it's a real multi-container/init story:
_workload_init_container.tpl adds a
wait-for-dependencies initContainer and a {svc}-migrate
initContainer that runs gjob sql_migrate (:21-30) — the DB migration runs to
completion before your server container starts. That's the init-container pattern,
live in your stack.
Backend use case
Backend use case: this is the actual container wrapper around the repo’s `build/server` binary plus its probes, mounted config, secrets, and service account identity.
Common mistake
Common mistake: talking about “a container in Kubernetes” as if the scheduler and service system target containers directly instead of Pods.
Read this next
Kubernetes docs — Pods
What a Pod is, why it's the unit, the shared network/storage model, and Pod lifecycle
basics.
In plain English
Plain English: a Pod is the smallest runnable unit in Kubernetes — one or more containers sharing one network identity and lifecycle.
Check yourself (from memory)
Q1. The smallest deployable unit in Kubernetes is…
K8s schedules Pods, not bare containers — even a one-container
workload is wrapped in a Pod.
Q2. Containers in the same Pod share…
One IP/port space (reach each other on localhost) plus
shareable volumes — that's why they're co-located.
Q3. Its node dies, so a bare Pod (no controller)…
Pods are ephemeral and don't self-heal. A controller
(Deployment/StatefulSet) is what recreates them — Lesson 4.
What is a Pod — the unit, the sharing, the ephemerality?
recall, then click to reveal
A POD is the smallest deployable unit: ONE OR MORE containers always
scheduled together on one node. They SHARE a network namespace (one IP/port space → reach
each other on localhost) and can share VOLUMES — so co-locate only tightly-coupled helpers
(sidecars), not separate services. Pods are EPHEMERAL: no self-healing, temporary IP; if the
node dies the Pod is gone. So never run bare Pods — let a CONTROLLER (Deployment/StatefulSet)
own them and recreate on failure (Lesson 1's loop). Spec parts: containers, initContainers
(run to completion first), volumes. Repo: the pod's container (build/server, grpc_health_probe
probes) comes from _workload_containers.tpl; a {svc}-migrate
initContainer runs migrations before the server starts.
Want the sidecar pattern in detail, or why initContainers are perfect for migrations?
Ask me.