Kubernetes Deployment configuration: which parameters to set for a service and why

The interviewer asks about specific Kubernetes configuration parameters. The report does not say which parameters or which workload they concerned, so this version assumes a typical case: a stateless HTTP backend service, deployed as a Deployment behind a Service, which must stay available while new versions roll out and while nodes are drained for maintenance. Explain which parameters you would set in its manifests, what each one does at runtime, and how you would choose its value. ```hint Two numbers per resource Ask what the scheduler looks at when it places a pod, what the kernel enforces once the pod runs, and what happens in each case when the pod needs more than you set. ``` ```hint Alive is not the same as ready Think about how Kubernetes should treat a pod that is alive but briefly unable to serve, compared with one that is stuck, and what each health check should therefore test. ``` ### Clarifying Questions - What does the service do: short request-response calls, long-lived connections, or background work? The answer affects health checks and shutdown. - What are its measured CPU and memory usage at normal and peak load, and how spiky is the traffic? - How available must it stay during deploys and node maintenance, and how many zones does the cluster span? - Which runtime does it use, and does that runtime size its own memory, as a JVM heap does? ### What a Strong Answer Covers - Requests versus limits for CPU and memory, and their effect on scheduling, quality-of-service class, throttling and out-of-memory kills - Startup, readiness and liveness probes, with parameters chosen so that a slow start or a dependency outage does not cause restart loops - Rolling-update settings, graceful shutdown and disruption budgets that keep the service available through deploys and node drains - Replica counts and autoscaling tied to a measured metric, with replicas spread across nodes and zones - How configuration and secrets reach the pods, and how a bad value is caught during rollout - Values justified from measurements rather than copied defaults ### Follow-up Questions - Under load, pods restart repeatedly with exit code 137. What do you check, and what do you change? - Latency rises while the average CPU usage stays well below the limit. Could the CPU limit be the cause, and how would you confirm it? - A few requests fail with connection errors during every deploy. Which settings do you look at? - The autoscaler adds pods too late for traffic spikes. What would you tune?