Pods and Workloads

httpGet: the kubelet calls the container's IP and port; status 200-399 is success. tcpSocket: success if a TCP connection opens - it proves only that a listener exists. exec: runs a command inside the container, exit 0 is success, but forks a process every period. grpc: calls the standard gRPC health checking service.

Put stable and canary Deployments behind one Service that selects only their shared app label; the canary gets roughly its fraction of ready pods. That share moves in one-pod steps, is counted per connection, and drifts when either side scales.

LimitRange is per-object: it defaults and bounds an individual container's or Pod's requests and limits at admission. ResourceQuota is per-namespace aggregate: it caps total requests, limits and object counts. A quota on a resource makes declaring it mandatory; LimitRange defaults satisfy that.

Only the pod template is reverted: kubectl copies revision 4's template back into the Deployment. The controller reuses that old ReplicaSet and renumbers it to the next revision, so the Deployment reports a new number, not 4.

OrderedReady (the default) creates Pods one at a time in ordinal order, waiting for each to be Running and Ready, and deletes in reverse one at a time. Parallel starts and stops them all at once. Neither changes rolling-update ordering, which stays sequential.

With updateStrategy RollingUpdate (the default), the controller replaces pods node by node, keeping at most maxUnavailable (default 1) unavailable at a time; maxSurge can instead start the new pod before deleting the old. OnDelete updates a node only when you delete its pod manually.

Look at the Deployment's conditions and events, then at the new ReplicaSet and its pods. ProgressDeadlineExceeded means the rollout made no progress within progressDeadlineSeconds (default 600); it is a status marker only — Kubernetes does not roll back for you.

A Job's Pod is only complete when its regular containers have all exited, and the log shipper never exits. Fix it by declaring the helper as a native sidecar — an initContainers entry with restartPolicy: Always — so completion is judged on the batch container alone.

Containers listed in a Pod's containers field start in parallel, so the app can beat the proxy. Fix it by declaring the proxy in initContainers with restartPolicy: Always and a startupProbe — the kubelet then waits for the probe to pass before starting the app.

The CronJob controller counts every schedule point missed since the last run; if it finds more than 100 it gives up and logs an error instead of guessing. startingDeadlineSeconds limits how far back it looks and how late a missed run may still start — setting it below 100 intervals prevents the lock-up.

List a stable and a canary Service in one HTTPRoute rule with weights 995 and 5; the gateway sends 0.5% of requests to the canary whatever its pod count. Pod-to-pod calls via the Service ClusterIP bypass those weights.

progressDeadlineSeconds measures the longest gap between progress events, not the whole rollout, so it must exceed one pod's time to Ready plus margin. minReadySeconds catches early crashes, and a --timeout above the total rollout time is the backstop.

StatefulSet rolling updates go in reverse ordinal order, one Pod at a time. Setting partition to k means only Pods with ordinal greater than or equal to k are updated; lower ordinals stay on the old revision. Setting it to replicas minus one gives a single-Pod canary.

An exec preStop sleep longer than terminationGracePeriodSeconds consumes the whole budget; the kubelet then allows only a 2-second stop window, so SIGKILL follows SIGTERM. Shorten the sleep and size the grace period to sleep plus drain.

Same Pod when they must share fate, scale 1:1, and need localhost or a shared filesystem. Separate Pods when they scale, release or fail independently. A Pod is the unit of scheduling, scaling, rollout and blast radius, so co-locating couples all four at once.

Hand-built releases suffice while few services release rarely under a watching person. When many teams need automatic bake-and-abort, precise splits and an audit trail, a progressive-delivery controller or mesh should own the steps; core Kubernetes never judges a release.

Size requests from observed usage percentiles plus headroom, not guesses. Overcommit CPU deliberately — it is compressible and degrades gracefully. Do not overcommit memory: set memory request equal to limit so failures stay contained and attributable rather than node-wide.

Decide by lifetime and blast radius: one-shot precondition for this Pod means init container; continuous work bound to this Pod's lifetime means sidecar; work that must happen once per release or scale independently means its own Job or Deployment; universal, stable behaviour with no separate lifecycle belongs in the image.

Treat the schedule as at-least-once and make exactly-once a property of the payload: derive a deterministic run key from the period, take a database lock or unique-constraint claim on it, make every charge idempotent with a per-invoice key, and alert on a heartbeat rather than on Job failures.