> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Pods
> 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:
```bash theme={null}
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:
```bash theme={null}
kubectl get pods
```
Example output immediately after creating a pod:
```bash theme={null}
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 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 ` | Show detailed information and events for a pod. |
| `kubectl logs [-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
* [Kubernetes Pods](https://kubernetes.io/docs/concepts/workloads/pods/)
* [Kubernetes Documentation](https://kubernetes.io/docs/)
* [Docker Hub](https://hub.docker.com/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.