Lesson 3 · Core objects & the control plane

Pods — the atom

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)

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.
Read this next

Kubernetes docs — Pods

What a Pod is, why it's the unit, the shared network/storage model, and Pod lifecycle basics.

→ kubernetes.io — Pods

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.

1. Kubernetes — Pods (unit, shared network/storage, ephemerality).