Deployment & Infra
K8s objects: multiple-choice review
Crux Multiple-choice synthesis across the K8s objects unit — reconciliation, the workload hierarchy, Service selectors, probes, ConfigMap/Secret, and resource requests vs limits.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one is a decision you make while writing a manifest or debugging a rollout — not a definition to recite, but a failure mode to reason through under production conditions.
Goal
Confirm you can connect the reconciliation loop, the Pod→ReplicaSet→Deployment hierarchy, Service label-selectors, probe semantics, ConfigMap/Secret behaviour, and resource requests vs limits — the synthesis the lesson built toward.
Quiz
Completed
A node reboots and takes 3 of a Deployment's 5 pods with it. No human runs any command. What restores the count, and what is the underlying mechanism?
Heads-up Reconciliation is incremental: the controller creates only the 3 missing pods to reach desired count. It does not tear down and rebuild the Deployment or its ReplicaSet.
Heads-up That is imperative thinking. The desired state (replicas: 5) is already stored in the cluster; a controller enforces it forever without human action — that is the entire point of declarative orchestration.
Heads-up Liveness restarts a wedged container in place on a surviving node. Replacing pods lost with a dead node is the ReplicaSet reconciling its count, which is independent of any probe.
Quiz
Completed
A junior runs kubectl run debug --image=busybox to start a one-off pod, and it works fine for days. Why is this still wrong for anything that must stay up?
Heads-up Bare Pods get a normal Pod IP and full network access. The problem is purely lifecycle: nothing reconciles them, so they do not survive node loss or eviction.
Heads-up kubectl run is not disabled by default; admission policy might restrict it, but the fundamental issue is that the resulting Pod has no owning controller to recreate it.
Heads-up A bare Pod with matching labels is added to a Service's endpoints like any other pod. The flaw is durability, not selectability.
Quiz
Completed
A Deployment defines selector app=web and a Service also selects app=web. A second Deployment is later created whose pods also carry app=web. What happens to traffic?
Heads-up Selectors never error on overlap; Kubernetes simply lists every matching pod IP in the Endpoints object. Overlapping labels are a common source of accidental traffic mixing, not a hard failure.
Heads-up Creation order is irrelevant. The selector is evaluated against current pod labels each reconcile; any pod matching app=web is an endpoint regardless of which Deployment spawned it.
Heads-up A Service of this type does not name pods or IPs — it selects dynamically by label. Hardcoding pod IPs would break on every restart, which is exactly why selectors exist.
Quiz
Completed
An app needs ~25s to warm (config load + pool prime) before it can serve, and it occasionally wedges into a hung state hours later. The team adds only this: ```yaml livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 ``` Rollouts still spike 500s. Why, and what is missing?
Heads-up 30s does cover a 25s warmup, and the rollout 500s happen regardless. The real gap is that liveness never gates traffic — a readiness probe is required to hold the pod out of the Service until it can serve.
Heads-up The path is fine. Even a correct liveness path cannot fix rollout 500s, because liveness restarts pods — it does not decide endpoint membership. Readiness does.
Heads-up They are distinct: liveness restarts a wedged pod, readiness pulls a not-yet-serving pod out of Service rotation. Using liveness where you need readiness is the classic rollout outage.
Quiz
Completed
You update a ConfigMap consumed as env vars by a running Deployment: ```yaml envFrom: - configMapRef: { name: app-config } ``` The new value never reaches the pods even hours later. Root cause and the standard fix?
Heads-up The ConfigMap object did update. The issue is propagation: env vars are read once at container start and never refreshed, so running pods keep the old values until they restart.
Heads-up Neither ConfigMap nor Secret env vars hot-reload; both are frozen at start. A rollout restart does work, but teams automate it by hashing config into an annotation so apply itself triggers the roll.
Heads-up envFrom is fully supported. Volume-mounted ConfigMaps do eventually update the projected files, but env vars never refresh — and even mounted files do not restart the process, so apps must re-read them.
Quiz
Completed
A latency-sensitive service sets: ```yaml resources: requests: { cpu: 250m, memory: 256Mi } limits: { cpu: 500m, memory: 256Mi } ``` Under load it shows periodic latency spikes and the occasional OOMKill. What are the two distinct mechanisms, and which knob is the bigger risk?
Heads-up Memory is incompressible — you cannot throttle it. Exceeding the memory limit triggers an OOMKill, not a slowdown. Only CPU is throttled via CFS quota.
Heads-up Requests are for scheduling and the guaranteed share — they do not throttle. The CPU LIMIT enforces the throttle ceiling; the MEMORY limit enforces the OOM ceiling. Requests influence neither cap directly.
Heads-up Equal request/limit for memory gives the Guaranteed QoS class — generally desirable. The OOMKill comes from actual usage exceeding the limit, not from the values matching; the fix is a higher limit or less memory use.
Recap
The unit’s through-line is one model: you declare desired state and controllers reconcile actual toward it forever — which is why a Deployment self-heals and a bare Pod does not. The hierarchy stacks one job per layer (Pod runs containers, ReplicaSet keeps the count, Deployment rolls and rolls back), Services select pods by label into an Endpoints set with no notion of ownership, probes split into readiness (gates traffic) and liveness (restarts), ConfigMap/Secret changes never auto-roll, and resources split into CPU (throttled, compressible) and memory (OOMKilled, incompressible). Every production failure here traces back to one of those exact semantics.