Weekend campground reservation spikes overload the city’s checkout microservice on OKE. How should the team scale capacity using orchestration’s primary scale knob?
Select an answer to reveal the explanation.
Short Explanation
Scale here means more copies of checkout, not one giant machine you babysit. Raising the declared replica count is the orchestration knob. Think lanes at a booth, not a bigger single window.
Full Explanation
Weekend campground reservation spikes increase concurrent demand on the checkout microservice. Orchestration’s primary scale knob for that pattern is horizontal: raise the declared replica count so more Pods share the load behind the same Service. Each replica is another instance of the same unit; the control plane schedules the extras onto workers that have capacity. Vertically resizing one VM by hand and SSHing to raise vCPU treats capacity as a single snowflake machine and bypasses the declarative replica contract the cluster is meant to honor. Disabling the Service does not add capacity—it removes the stable discovery path and queues or fails traffic elsewhere, which is shedding load by outage rather than scaling. Storing a larger instance shape name in a ConfigMap without restarting or changing the Deployment does nothing to running Pods; ConfigMaps hold configuration, they do not resize nodes or spawn replicas by themselves. Exam caveat: more replicas help only if the app is horizontally scalable and backends (databases, rate limits) can absorb the fan-out—otherwise you move the bottleneck. Operational check: raise replicas before the spike window, watch Pod Ready counts and Service endpoints climb, and confirm latency and error rates drop under load tests rather than only documenting a bigger shape name.