A Pod is one or more containers that share an IP, ports and volumes.

Kubernetes schedules Pods, never bare containers. The containers in a Pod always land on the same node and talk over localhost.

Why not just a container?

Some helpers must share the network and files of the main process: a log shipper, a mesh proxy, a config reloader. The Pod is the unit that groups them.

Pods are disposable

A Pod is never repaired. If it dies, a controller creates a new one with a new name and a new IP.

Rule of thumb

One Pod, one main process. Add a second container only when it must share the first one's lifecycle.

Think of a Pod as one logical host for tightly coupled containers, and as cattle: replaceable, never nursed back to health.

A Pod is the smallest thing Kubernetes runs

A container is a process with an isolated view of the filesystem, network and process table. Kubernetes adds one level above it, the Pod. Every container in a Pod shares:

one network namespace: a single IP address and port space, so containers reach each other on localhost

the same volumes you mount into the Pod

the same node, lifecycle and scheduling decision

Why the extra level exists

Many systems need a helper tightly attached to the main process: a log shipper that reads the files the app writes, a service-mesh proxy that intercepts its traffic, a config reloader. In one Pod they get the shared network and files they need with no special wiring. This is the sidecar pattern.

Pods are disposable

You rarely create a bare Pod. A controller (for example a Deployment) creates Pods and replaces them when they fail. A replacement gets a new name and a new IP, which is why Services (Module 6) give you a stable address.

apiVersion: v1 kind: Pod metadata: name: checkout labels: {app: checkout} spec: containers: - name: app image: shopwave/checkout:1.4 ports: [{containerPort: 8080}]

Gotcha. Do not put two independent services in one Pod to save a manifest: they would scale, restart and fail together.