71 lines
2.2 KiB
Markdown
71 lines
2.2 KiB
Markdown
---
|
|
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.
|