KubeLab

Chapter 7 of 47 · Pods in depth, part 3

Pod storage, lifecycle, and why Pods are disposable

Where data lives in a Pod, the phases a Pod goes through, where Pods actually run, and the mindset that makes Kubernetes work: a Pod is not your server.

Storage

Containers are ephemeral. Anything written to a container's own filesystem can vanish when that container is replaced. To keep or share data, a Pod mounts volumes.

Two containers share a volumeThe posts container writes to a shared volume and the logging container reads from it. Files written only to a container's own filesystem are lost with that container.PODpostswrites logsloggingreads logsshared volume

Later chapters go into Volumes, PersistentVolumes and PersistentVolumeClaims, which keep data even after the Pod is gone. For now: container filesystem = temporary, volume = shared, and can be made lasting.

Lifecycle

A Pod moves through a few phases. kubectl get pods shows them in the STATUS column, sometimes with a more specific reason. Pick a story and step through it:

  1. Kubernetes accepted the Pod. It is waiting for the scheduler to pick a node.
  2. A node was chosen. The image is being pulled and the container created. Still Pending.
  3. The container started. At least one container in the Pod is running, so the phase is Running.
  1. A one-off task, such as a database migration, is waiting to be scheduled.
  2. The migration script runs.
  3. The script exits with code 0. All containers finished successfully: Succeeded. This is typical for Jobs.
  1. A one-off task runs, with restartPolicy: Never.
  2. The script exits with code 1. A container finished and failed, and nothing restarts it: Failed.
  1. The node tries to pull micro-postz, a typo.
  2. The pull fails. The Pod stays Pending.
  3. Kubernetes keeps retrying, waiting longer each time. Still Pending; it will never run until you fix the image name.
  1. The Pod is running on node-2.
  2. node-2 stops reporting (power cut, network split). Kubernetes cannot tell what the Pod is doing: Unknown.
PhaseMeans
PendingAccepted, not running yet: waiting for a node, resources or the image
RunningBound to a node, at least one container running (or starting/restarting)
SucceededAll containers exited successfully and will not restart
FailedAll containers exited, and at least one failed
UnknownThe Pod's state cannot be read, usually because its node is unreachable

You will also see CrashLoopBackOff: the container keeps crashing, and Kubernetes waits longer before each restart. The phase is still Running.

Container crash vs Pod gone

These are different events, and it matters which one happened.

The kubelet on that node restarts the container inside the same Pod, following the Pod's restartPolicy (default Always). Same Pod name, same IP; the RESTARTS count goes up.

NAME        READY   STATUS    RESTARTS   AGE
posts-pod   1/1     Running   1          5m

Pods are disposable

Don't think

"My Pod is my server." Something you name, log into, fix by hand and keep alive.

Think

"My Pod is disposable." posts-pod-abc can disappear and posts-pod-xyz takes over. The app keeps working.

So: keep no important data only in the container, never depend on a Pod's name or IP, and make your app start cleanly every time.

Pod vs Node

Do not confuse them. A Node is a machine. Pods run on Nodes. Click each level:

Cluster, nodes, Pods and containers KUBERNETES CLUSTER Node 1 Node 2 Pod Containerposts app Container Pod Pod Pod

Node

One machine, a VM or physical server, with CPU and memory. Many Pods run on each Node. If a Node dies, every Pod on it dies with it.

Cluster → Node → Pod → Container → Application

Why a Deployment manages Pods

A Pod by itself cannot say "always keep 3 of these running". A Deployment can:

spec:
  replicas: 3

In fact a Deployment does this through a ReplicaSet, an object whose only job is keeping N identical Pods alive:

Deployment
    └── ReplicaSet
          ├── Pod
          ├── Pod
          └── Pod

This is why in real applications you will rarely create Pods by hand. Deployments are coming up next.

The seven Pod ideas

  1. A Pod is the smallest deployable Kubernetes unit.
  2. A Pod can contain several containers: an app plus sidecars.
  3. Containers in a Pod share networking and reach each other on localhost.
  4. A Pod gets an IP, but that IP is temporary.
  5. Containers in a Pod can share volumes.
  6. Pods are disposable. Do not depend on their identity or IP.
  7. A Deployment (through a ReplicaSet) normally manages Pods.
Mental model: a Pod is a small, shared execution environment for one or more tightly coupled containers. Kubernetes schedules and manages Pods, not bare containers.

Pod lifecycle: common questions

What does Pending mean for a Kubernetes Pod?

The Pod was accepted but is not running yet: it is waiting for a node, for resources, or for its image to be pulled.