---
id: mat-03-working-with-pods
title: "Working with Pods"
---

# Working with Pods

## Previously
Key reminders:
- Pods are the atomic unit of scheduling.
- Pods die and are immutable.
- We usually do not deploy Pods directly (we use Controllers such as Deployments, DaemonSets, StatefulSets).

## Pods
Anything you run on Kubernetes runs in a Pod.
Typical effects:
- Deploy an app → a new Pod is created.
- Terminate an app → its Pod is destroyed.
- Scale up → new Pods are scheduled.
- Scale down → some Pods are destroyed.

Pods act as:
- containers with extra metadata
- a wrapper object that can bring containers “close together”

## Pod augmentation data
Pods can be augmented with:
- labels and annotations
- restart policies
- probes (startup/readiness/liveness)
- affinity and anti-affinity
- termination control
- security policies
- resource requests and limits

Helpful CLI exploration:
- `kubectl explain pods --recursive`
- `kubectl explain pod.spec.restartPolicy`

## Some Pod features (why they matter)
- **Labels**: group Pods and associate them with other objects.
- **Annotations**: attach extra info used by third-party/experimental tools.
- **Probes**: inspect container behavior and health.
- **Affinity/Anti-affinity**: control where Pods are deployed.
- **Termination control**: graceful termination.
- **Security policies**: enforce security features.
- **Resource requests/limits**: minimum required vs maximum allowed resources.

## Static Pods vs Controllers
If you deploy a Pod directly:
- it gets deployed (IP, DNS)
- kubelet can restart it for some time (depending on restart policy)
- but: no scaling, no rolling updates, no self-healing across node failure
- if the node dies → the Pod is gone

If a Pod is managed by a Controller:
- control plane monitors it
- if a Pod is irreparable, a new Pod is created
- new Pod means new IP/DNS → Pods should be treated as stateless

## Deploying Pods (high level)
Workflow:
1. Define the manifest (YAML).
2. Post it to the Kubernetes API (via kubectl).
3. API server authenticates/authorizes and validates.
4. Scheduler assigns to a worker node.
5. Kubelet starts monitoring it.

If managed by a Controller:
- config is added to the cluster store and the control plane monitors it.