Explains Kubernetes pods, their role as the smallest deployable unit, single versus multi-container pods, shared networking and storage, lifecycle, scaling, and basic kubectl pod commands.
Before we dive into pods, make sure the following are already in place:
Your application is built into Docker images.
Those images are hosted in a registry (for example, Docker Hub) so Kubernetes can pull them.
You have a working Kubernetes cluster (single-node or multi-node).
Cluster services are running.
Kubernetes schedules containers onto worker nodes, but it does not schedule raw containers directly. Instead, Kubernetes groups one or more containers into the smallest deployable unit called a pod.What is a pod?
A pod is a single instance of an application (or a logical group of tightly coupled containers).
It is the smallest deployable object in Kubernetes.
Here’s the simplest scenario: a single-node Kubernetes cluster running one instance of an application in a single container, packaged inside a pod.
Scaling is done by creating or deleting pods — not by adding containers to an existing pod. When user load grows, you create additional pods running the same application image. Kubernetes may place new pods on the same node or schedule them to other nodes to balance capacity.
Key takeaway:
Most pods run a single main application container.
To scale up, create more pods; to scale down, delete pods.
When do you use multiple containers in a pod?
Although less common, pods can contain multiple containers. Multi-container pods are valuable when you need helper or sidecar containers that must share the same lifecycle, network namespace, and storage as the main application container. Typical use cases include logging, monitoring agents, data fetchers, or file processors that must run alongside each app instance.When containers share a pod:
They are created and terminated together.
They share the same network namespace (can reach each other on localhost).
They can mount and share the same persistent volumes.
Multi-container pods (sidecars) solve problems where multiple tightly coupled processes need to share storage, network, and lifecycle. They are useful but relatively uncommon — most pods run a single main container.
Pod characteristics at a glance:
Characteristic
Description
Example / Note
Deployable unit
Smallest object you create to run containers
Pods encapsulate one or more containers
Network
Containers share a network namespace
Communicate over localhost between containers in the same pod
Storage
Containers in a pod can mount the same volumes
Useful for sidecars that write/read the same files
Lifecycle
Containers are co-scheduled and restarted together
Pod-level restart semantics determine behavior
If this still feels abstract, compare with plain Docker on a single host. Initially you might run only the application container:
docker run --name app1 python-appdocker run --name app2 python-app
As the design evolves you may need helper containers paired with each app instance. With Docker on a host you would manually start helpers and link them to their respective app containers:
# application instancesdocker run --name app1 python-appdocker run --name app2 python-appdocker run --name app3 python-appdocker run --name app4 python-app# helper instances, manually linked to the corresponding appdocker run --name helper1 --link app1:app helper-imagedocker run --name helper2 --link app2:app helper-imagedocker run --name helper3 --link app3:app helper-imagedocker run --name helper4 --link app4:app helper-image
You would also need to manage shared volumes and keep helper lifecycles in sync with the application containers. Kubernetes pods simplify this by declaring all co-located containers in a single pod spec. Kubernetes creates them together, assigns a shared network namespace, mounts volumes, and enforces a single lifecycle.A conceptual mapping for per-instance helpers:
Even if your app uses a single container now, designing around pods makes future changes and scaling simpler. This lesson focuses primarily on single-container pods.Deploying a pod with kubectl
You can create a simple pod directly from the command line with kubectl run. Depending on kubectl and cluster versions and flags, kubectl run may create different resource types (pod vs. deployment). To request a plain pod, set --restart=Never:
kubectl run nginx --image=nginx --restart=Never
This tells Kubernetes to create a pod that runs the official NGINX image. Kubernetes will pull the image from Docker Hub or another configured registry if needed.To list pods:
kubectl get pods
Example session showing a pod starting and running:
$ kubectl run nginx --image=nginx --restart=Never$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx 0/1 ContainerCreating 0 3snginx 1/1 Running 0 8s
Note: In newer versions of kubectl, kubectl run may create different resource types depending on flags. To explicitly create pods, use kubectl run --restart=Never, use kubectl create with the appropriate subcommand, or apply a declarative YAML manifest with kubectl apply -f pod.yaml.
What we did not cover
We did not expose the NGINX server externally. The pod is accessible inside the cluster (or from the node depending on your cluster networking and tools such as port forwarding).
Networking and Services that expose pods to end users will be covered in a separate lesson.
Try it
Create a few pods with different images to observe scheduling and pod lifecycle.
Experiment with a simple multi-container pod spec (sidecar) and observe how containers share localhost and volumes.
Convert imperative kubectl run commands into declarative YAML manifests (pod.yaml) and apply them with kubectl apply -f pod.yaml.
