Jon Chery
c3226192f5
---ci--- project: atelier phase: 2 milestone: v0.2 status: complete requirements: covered: [ATELIER-41, ATELIER-42, ATELIER-43, ATELIER-44, ATELIER-45, ATELIER-46, ATELIER-47] partial: [] ---/ci---
3.8 KiB
3.8 KiB
Workloads — Derived Rules
Derives from
domains/kubernetes/first-principles.md. Covers Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet, Job, and CronJob. Applies P1–P10.
The Pod (P2 Pods are Mortal)
- A pod is the smallest deployable unit: one or more containers sharing network and storage namespaces.
- Never deploy a bare pod. A bare pod has no controller to restart, scale, or replace it. Use a controller.
- Pods are replaceable by design. Do not store state in a pod's filesystem (
emptyDiris scratch, not storage — seestorage.md).
Controllers (P1 Declarative Desired State)
| Controller | When | Identity | Ordering |
|---|---|---|---|
| Deployment | Stateless workloads | None (pods interchangeable) | No ordering |
| StatefulSet | Stateful workloads (databases, queues) | Stable name (pod-0, pod-1) + stable PVC |
Ordered, sequential |
| DaemonSet | One pod per node (logging, monitoring, CNI) | Per-node | — |
| Job | Run to completion (batch) | — | — |
| CronJob | Scheduled batch | — | — |
- A Deployment manages a ReplicaSet, which manages pods. You interact with the Deployment; the ReplicaSet is an implementation detail except during rollouts.
- StatefulSet gives stable network identity and stable persistent storage per replica. Use it when the workload needs a stable name or per-replica data (databases, distributed systems). Do not use StatefulSet for stateless workloads — the ordering is overhead.
Probes (P5 Probes Drive Health)
- Readiness probe — is the pod ready to serve traffic? Failing readiness removes the pod from the Service's endpoints but does not restart it. Use for "warm-up" and transient unavailability.
- Liveness probe — is the pod alive? Failing liveness restarts the container. Use for "wedged but running." Do not use liveness to check dependencies (it will cascade-restart on a dependency blip).
- Startup probe — has the pod finished starting? Disables liveness/readiness until it succeeds. Use for slow-starting workloads so liveness does not kill them before they are ready.
- Probes must check the workload's own health, not the health of its dependencies. A readiness probe that fails on a downstream outage causes the Service to drain all pods simultaneously.
Lifecycle and Disruption (P2 Pods are Mortal, P10 Roll Forward Roll Back)
kubectl rollout statuswatches a Deployment's rollout to completion.kubectl rollout undoreverts to the previous ReplicaSet.- PodDisruptionBudgets (PDBs) protect voluntary disruptions (node drain, cluster autoscaler). An involuntary disruption (node failure) ignores the PDB. Set a PDB on every workload that must keep a minimum available.
- Rolling update strategy:
maxUnavailableandmaxSurgecontrol the speed of rollout. Slow rollouts (lowmaxSurge) are safer; fast rollouts (highmaxUnavailable) risk availability.
Resource Contracts (P4 Requests and Limits are Contracts)
- Every container in production has a CPU request, a memory request, and a memory limit. CPU limits are optional but recommended to bound noisy neighbours.
- QoS classes:
Guaranteed(requests == limits),Burstable(requests < limits),BestEffort(no requests).BestEffortis first evicted under node pressure — never for prod. - A workload without requests is an unbounded gamble on the scheduler. Set them.
What Violates Workload Discipline
| Violation | Principle |
|---|---|
| Bare pod (no controller) | P2 Pods are Mortal |
| StatefulSet for a stateless workload | P1 Declarative Desired State (overhead) |
| No probes | P5 Probes Drive Health |
| Liveness probe checks a dependency | P5 Probes Drive Health |
| No PDB on a critical workload | P10 Roll Forward Roll Back |
| No resource requests in prod | P4 Requests and Limits are Contracts |
emptyDir for data that must persist |
P8 Storage is Explicit |