A city permitting office runs permit-review workers as containers across a pool of hosts. When a reviewer container must start, which orchestration responsibility decides which worker has enough CPU and memory and binds the container there?
Select an answer to reveal the explanation.
Short Explanation
Think of the scheduler as a dispatcher who knows which desk has free space. It matches CPU, memory, and constraints to a worker and seats the container there. You do not keep picking the same hostname out of habit.
Full Explanation
In a multi-host container pool for permit-review workers, placement is an orchestration scheduling problem: match the new container’s CPU, memory, and any placement constraints against workers that still have capacity, then bind the instance to one of those workers. The scheduler is the control-plane component that performs that match continuously as workload arrives; without it, capacity on idle hosts sits unused while overloaded hosts refuse new starts. Habitual SSH to a familiar hostname and a local docker start ignores cluster-wide resource accounting and recreates snowflake placement—when that host fills or fails, startups break even though other workers are free. Vault is for secrets and cryptographic material, not for choosing which worker receives a container; rotating a “placement secret” does not implement affinity, taints, or resource requests. An API Gateway balances HTTP routes to backends; it does not schedule container processes onto worker CPUs or honor Pod resource requests. Exam caveat: scheduling answers constraints and capacity at start time—it does not by itself heal a crashed process or change replica count. Operational check: after a failed placement, inspect pending events for Insufficient cpu/memory or unmet constraints, confirm requests versus allocatable capacity on workers, and verify the scheduler (not a host SSH habit) is the placement path.