A water-utility team wants OKE to keep twenty meter-reading API replicas running. Which approach actually uses the orchestration contract?
Select an answer to reveal the explanation.
Short Explanation
Orchestration is a wish list the cluster keeps true, not a shell script touring twenty hosts. You submit a declaration; the control plane converges. SSH loops of docker run are containers without orchestration.
Full Explanation
Keeping twenty meter-reading API replicas running is the orchestration contract: submit a declared object such as a Deployment through the Kubernetes API stating the desired replica count and Pod template, then let the control plane converge cluster reality to that declaration—creating, replacing, and rescheduling as nodes and Pods change. The API is the source of desired state; reconciliation is continuous rather than a one-shot shell tour. A cron that SSHs to twenty hosts and runs docker run is an imperative loop that races failures, misses node replacements, and never encodes desired state in the cluster API where controllers can enforce it. Manual docker start on whichever worker looks idle is ad hoc capacity guessing without resource accounting or replica controllers. Copying binaries with scp onto workers skips the container image model, the runtime, and the cluster schedule entirely. Exam caveat: declaring twenty replicas only works if the node pool has enough allocatable CPU and memory and the image plus probes allow Pods to become Ready; otherwise the Deployment stays partially available with Pending or CrashLooping Pods. Operational check: kubectl apply the Deployment, watch ready replicas climb to twenty, delete a Pod, and confirm a replacement appears without any SSH docker run loop.