Pod
The smallest thing Kubernetes handles is not a container but a Pod. A Pod wraps one or more containers, and the containers inside share a single IP and their volumes. That lets them call each other over localhost and read the same files. Placement and lifetime are shared too, which makes the Pod both the unit that gets scheduled onto a node and the unit that gets restarted.
01Pod
Concept at a GlanceSeparate containers · strangers
Start the container that pulls files and the web server that serves them separately, and they are strangers: each gets its own IP and its own filesystem.
The web server cannot simply open the file the puller fetched. It has to find an address and hand it over the network.
Placement is separate too. If the two land on different servers, that handover now leaves the machine.
When one dies the other stays up. Treating them as one unit means writing that rule yourself.
Ports are private too. Both can listen on 8080 without colliding — but each has to know the other's address and port.
Scaling is separate as well. Take the puller to three and you must match the web server to three, then pair them up by hand.
Pod · sharing one IP and volumes
A Pod wraps several containers into one bundle. What Kubernetes handles is that bundle, not the container.
Bundled containers share a single IP. No address lookup — they call each other on localhost.
A volume attaches to the Pod rather than to a container, so the web server reads the file the puller fetched, right where it is.
What each container exchanges with the outside still differs: the puller takes files in, the web server faces the visitors.
Placement and lifetime come as a set. The Pod is what gets put on a node and what gets restarted.
Sharing has a price. The port space is shared too, so if both containers open 8080 they simply collide.
Scaling moves the whole bundle. Take the Pod to three and puller and web server reach three together, still paired.
02 Understand It Simply
For EveryoneA pod is the unit of deployment wrapping one or more containers. Containers in a pod share an IP and volumes and talk over localhost, and scheduling and restarts happen to the pod as a whole.
Containers in a Pod share a network namespace, so they share one IP and one port space: ports can collide, but they can reach each other on localhost.
Volumes attach at the Pod level, so a sidecar reads exactly the files the app wrote.
The scheduler places Pods rather than containers, so containers in one Pod always run on the same node.
That is why log shippers, proxies, and config reloaders — things that must travel with the main process — go in as sidecars.
- –Designing sidecar patterns (log shipping
- –proxying
- –config reload)
- –deciding whether containers belong in one Pod or several
- –and reasoning about Pod-level restart and scaling
03 Frequently Asked Questions
FAQWhat is Pod?+
The smallest thing Kubernetes handles is not a container but a Pod. A Pod wraps one or more containers, and the containers inside share a single IP and their volumes. That lets them call each other over localhost and read the same files. Placement and lifetime are shared too, which makes the Pod both the unit that gets scheduled onto a node and the unit that gets restarted.
Where is Pod used?+
Designing sidecar patterns (log shipping, proxying, config reload), deciding whether containers belong in one Pod or several, and reasoning about Pod-level restart and scaling.
What's a simple analogy for Pod?+
A pod is the unit of deployment wrapping one or more containers. Containers in a pod share an IP and volumes and talk over localhost, and scheduling and restarts happen to the pod as a whole.