Kubernetes

You describe the end state, not the steps. That idea underlies replicas, updates, and rollback: the cluster keeps working to match your description. Spec beats imperative steps A Deployment is a statement of the end state, not a list of steps: how many replicas, which image, what update strategy, which labels. The operator publishes the what, and the controller, a reconcile loop, is responsible for the how. The difference from running a command is structural: a one-off docker run or kubectl run orders something to happen now, while a Deployment says ’this is the state I want to remain true.’ If the work is interrupted, the command fails and the state may be left half-done, whereas the controller keeps trying to converge, which is exactly what turns startups and fixes into things the system will keep pursuing. ...

A container is ephemeral by design, so a PersistentVolumeClaim is the handle that pins real storage to it even when the Pod is recreated. The split is deliberate: a PersistentVolume declares capacity that exists, a PersistentVolumeClaim requests capacity that is needed, and a controller matches one to the other. With a StorageClass the claim can create its own volume through a provisioner, so nobody has to pre-build the storage. ...

A HorizontalPodAutoscaler is a feedback controller, not a capacity planner. Once every sync period — 15 seconds by default — it asks the resource metrics API for per-pod CPU, divides the observed value by the target to get a ratio, and writes the result into the target workload’s scale subresource. The formula is one line: desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue). ...

A slow start is not a dead process: readiness shields traffic while liveness only cares about keeping the process alive. Teams wire a single HTTP endpoint into both probes, and then every slow dependency becomes a restart loop — the app needs time, liveness refuses to grant it. Two probes exist because “not ready” and “dead” demand opposite responses: one asks for time, the other for a restart. ...

Changing a ConfigMap updates an API object. Whether a running application changes behavior depends on how Kubernetes delivers the value and how the application reads it. Environment injection, normal volume projection, a subPath mount, and an already-open file are different paths with different lifetimes. Diagnose the consumer that actually matters rather than treating all configuration delivery as one mechanism. ...

A probe result is evidence consumed by a control loop. Kubernetes does not infer your application’s recovery strategy from a route named healthz. The probe type, result, configured thresholds, and container lifecycle determine what happens next. Treating every failure as “restart the Pod” erases distinctions that directly affect availability. ...

A Kubernetes resource request and a resource limit belong to different decisions. Requests participate in scheduling and resource sharing; limits configure execution constraints supported by the runtime and operating system. Treating a limit as the scheduler’s reservation obscures both mechanisms. A useful resource policy identifies placement needs, acceptable contention and the failure behavior when a running workload reaches its boundary. ...

Small batches are the whole trick: a wave stops an old pod only after the replacement is already healthy. Instead of flipping the entire fleet at once — the all-or-nothing gamble of a recreate deployment — the controller keeps most of the old version serving while it proves the new one, pod by pod. A bad image then stalls the rollout with the old version still up, rather than replacing a working fleet with a broken one in seconds. ...