devops/materials/03-working-with-pods.md

id	title
mat-03-working-with-pods	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.