Explains Kubernetes pods their role, single versus multi-container pods, lifecycle statuses, creation and inspection commands, and when to use controllers versus bare pods.
With Kubernetes, the goal is to run your application as containers distributed across a set of machines (worker nodes) inside a cluster. Kubernetes does not schedule containers directly on nodes; instead it groups one or more containers into a higher-level object called a pod. A pod is the smallest deployable unit in Kubernetes and typically represents a single instance of your application.In the simplest setup you may have a single-node cluster with one pod containing a single container that runs your app. When you need to scale to handle more users, you add additional pod instances — not additional containers inside an existing pod. Each new pod runs its own container instance, and the scheduler places pods on nodes according to available capacity. If nodes run out of capacity you can add more nodes and schedule pods onto them, preserving the common one-to-one relationship between a pod and the application container it holds.
Key points:
Pods are the smallest object you create in Kubernetes.
You scale an application by creating or deleting pods.
You do not scale by adding additional application containers into an existing pod.
Although most pods contain a single container, a pod can host multiple containers that share the same network namespace and storage volumes. Multi-container pods are useful for co-located helper processes such as sidecar containers for logging, monitoring, proxying, or caching. All containers in a pod are created and terminated together.
Deploying pods
Historically kubectl run created a Pod object, but in recent kubectl versions it defaults to creating a controller (like a Deployment) that manages pods. If you explicitly want a bare Pod object, set the restart policy to Never.
Images are pulled from registries (Docker Hub by default). For private registries use image pull secrets.
Create a single Pod named nginx that runs the official nginx image:
kubectl run nginx --image=nginx --restart=Never
Note: On modern kubectl releases, kubectl run without --restart=Never will create a controller that manages pods. Use --restart=Never to create a single Pod object that is not managed by a controller.
Inspecting pods
List pods in the current namespace:
kubectl get pods
Example output immediately after creating a pod:
$ kubectl get podsNAME READY STATUS RESTARTS AGEnginx 0/1 ContainerCreating 0 10s
READY shows how many containers in the pod are ready vs. the total.
STATUS indicates the pod lifecycle state (e.g., Pending, ContainerCreating, Running, CrashLoopBackOff, Succeeded, Failed).
RESTARTS is the number of times containers in the pod have restarted.
Common pod statuses and what they mean:
Status
Meaning
Pending
Pod has been accepted by the scheduler but one or more containers are still being set up (e.g., image pull).
ContainerCreating
Kubernetes is pulling the image and preparing the container runtime on the node.
Running
Pod has been scheduled and all containers have been created. At least one container is still running.
Succeeded
All containers in the pod have terminated successfully and will not be restarted.
Failed
All containers have terminated and at least one container has terminated in failure.
CrashLoopBackOff
A container is repeatedly crashing; Kubernetes is backing off between restart attempts.
Useful commands
Command
Purpose
kubectl run nginx --image=nginx --restart=Never
Create a single Pod running the nginx image.
kubectl get pods
List pods and their statuses.
kubectl describe pod <pod-name>
Show detailed information and events for a pod.
kubectl logs <pod-name> [-c container]
View logs for a container in a pod.
When to use a bare Pod vs a controller
Use a bare Pod object for one-off tasks, debugging, or learning.
For production workloads and scaling, use higher-level controllers (Deployments, ReplicaSets, StatefulSets) to manage pod lifecycle, autoscaling, and rolling updates.
Summary
This lesson covered the pod concept in Kubernetes: what pods are, how they relate to containers, when to use multi-container pods, and the core commands to create and inspect pods. For production workloads prefer controllers (e.g., Deployments) to manage scaling and availability rather than creating many unmanaged Pod objects.Links and references
