> ## 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
> Introduction to Kubernetes Pods, their purpose, multi container patterns, differences from raw Docker, scaling, and creating and managing Pods with kubectl
Welcome to this lesson on Kubernetes Pods. This page explains what Pods are, when to use multi-container Pods, how they help manage containers compared to raw Docker, and how to create a Pod using `kubectl`.
## Prerequisites
Before proceeding, we assume the following are already in place:
* Your application is built into a Docker image and pushed to a container registry (for example, [Docker Hub](https://hub.docker.com)).
* A Kubernetes cluster is available and operational (single-node or multi-node) with cluster services running.
## What is a Pod?
Kubernetes schedules and runs application containers across a set of worker nodes. Rather than placing containers directly on nodes, Kubernetes groups containers into a Pod.
Key facts about Pods:
* A Pod is the smallest deployable unit in Kubernetes.
* A Pod usually represents a single instance of an application.
* In the simplest form, a Pod contains one container. Pods can contain multiple containers when those containers must be tightly coupled.
Pod characteristics and responsibilities:
| Feature | What it means | Example / Use |
| -: | - | - |
| Smallest deployable unit | Kubernetes schedules Pods, not individual containers | Deployments and ReplicaSets manage Pods |
| Network namespace | Containers in the same Pod share `localhost` and ports | Sidecar containers can proxy traffic to the main container |
| Shared storage | Containers within a Pod can access the same volumes | Log forwarder and app container writing to the same volume |
| Shared lifecycle | All containers in a Pod are created, scheduled, and terminated together | Useful for helper/sidecar containers |
## Scaling and scheduling
To scale an application horizontally, you create additional Pods—one Pod per application instance—rather than adding containers to an existing Pod. If the cluster needs more capacity, add nodes to the cluster and Kubernetes will schedule Pods onto those nodes. This separation makes horizontal scaling straightforward: increase or decrease the number of Pods.
Note: load balancing and service discovery are separate topics. Kubernetes Services distribute traffic across Pods and provide discoverability; we will cover those separately.
## Multi-container Pods
Yes — a Pod can contain more than one container. Multi-container Pods are appropriate when containers must work closely together and share networking, storage, and lifecycle.
Common multi-container Pod patterns:
* Sidecar containers: auxiliary containers that extend or augment the main container (e.g., log collectors, proxies).
* Ambassador/proxy containers: handle communication with external services.
* Adapter containers: transform or enrich data for the main container.
Shared aspects inside a Pod:
* Network namespace — containers can communicate via `localhost`.
* Shared volumes — persistent or ephemeral storage can be mounted across containers.
* Unified lifecycle — all containers in the Pod are scheduled and terminated together.
## Pod vs. raw Docker on a single host
Compare managing many containers manually with Docker to using Pods:
Example of launching multiple containers directly with Docker:
```bash theme={null}
docker run python-app
docker run python-app
docker run python-app
docker run python-app
docker run helper -link app1
docker run helper -link app2
docker run helper -link app3
docker run helper -link app4
# informal mapping
# App | Helper | Volume
# Python1 | App1 | Vol1
# Python2 | App2 | Vol2
```
Managing relationships between application and helper containers manually requires:
* Creating custom networks or links to connect related containers.
* Manually creating and sharing volumes.
* Monitoring containers and ensuring helpers stop when their paired app dies.
* Launching additional helpers when new app containers are created.
Kubernetes Pods declare which containers belong together. Kubernetes ensures:
* Containers are scheduled on the same node.
* They share networking and storage as configured.
* They follow the same lifecycle (created and terminated together).
Use multi-container Pods only when containers must be tightly coupled. Most applications run one container per Pod.
Most applications in practice use one container per Pod. Use multi-container Pods only when containers must be tightly coupled and share the same lifecycle and namespaces.
## Deploying Pods with kubectl
You can create a Pod directly with `kubectl`. Note: `kubectl run` behavior changed over time and may create a Deployment by default. To create a single Pod (one-off), specify `--restart=Never`:
```bash theme={null}
kubectl run nginx --image=nginx --restart=Never
```
This creates a Pod named `nginx` that runs the public `nginx` image (pulled from the configured registry).
To list Pods in the current namespace:
```bash theme={null}
kubectl get pods
```
Example flow when a Pod starts up and transitions to Running:
```bash theme={null}
C:\Kubernetes> kubectl run nginx --image=nginx --restart=Never
C:\Kubernetes> kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 0/1 ContainerCreating 0 3s
C:\Kubernetes> kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 8s
```
If you omit `--restart=Never`, `kubectl run` may create a Deployment (which manages ReplicaSets and Pods) depending on your kubectl version. Use Deployments when you want managed, restartable replicas; use Pods (with `--restart=Never`) for single, short-lived containers or demos.
## Accessing Pods
A running Pod does not automatically expose a port externally. Exposing services, load balancing, and service discovery are handled via Kubernetes Services and Ingress objects — topics we will cover next.
## Summary
* Pods are the basic scheduling unit in Kubernetes.
* Pods can contain one or multiple containers; multi-container Pods are for tightly coupled processes.
* Use Deployments to manage replicas and automatic restarts; use single Pods for one-off or short-lived tasks.
* Use `kubectl run --restart=Never` to create a direct Pod for demos or transient work.
## Links and References
* [Kubernetes Concepts: 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.