Workloads and rollout
Deployments, pods, and rolling updates — shipping changes without confusing readiness with “the process started.”
Most services should run as a Deployment (or a higher-level platform chart that creates one). Pods are ephemeral; controllers give them identity over time.
Prefer Deployments for stateless services
A Deployment owns ReplicaSets and rolling updates. You declare replicas, the pod template, and the strategy. Avoid hand-managing naked pods in production.
StatefulSets, DaemonSets, and Jobs exist for real reasons — persistent identity, every-node agents, finite work. Do not use them as a fashion choice.
Probes are product contracts
- Startup — slow boots without killing the container early
- Liveness — restart when the process is wedged
- Readiness — remove from Service endpoints when not ready to take traffic
A liveness probe that hits a dependency turns an outage next door into a restart storm. Keep liveness local; put dependency checks in readiness or app-level degradation.
Rolling updates need budgets
maxUnavailable / maxSurge decide whether a bad release takes the service down. Pair with readiness so traffic only hits ready pods. Without readiness, “rolling” still serves broken code.
Resources are scheduling truth
Requests influence placement; limits cap abuse. Untyped “best effort” pods get evicted first under pressure. Set requests from measured usage; revisit after load tests — fantasy numbers become noisy neighbors.
Image and config immutability
Pin digests or immutable tags in production. Changing a floating latest under a Deployment is how you lose reproducibility. Config changes belong in versioned ConfigMaps/Secrets (or an external store) with a deliberate rollout.