On-call staff propose a runbook that SSHes to node-3 and pip installs the DNA dashboard wherever capacity appears. How should Docker and Kubernetes CD integration work instead?
Select an answer to reveal the explanation.
Short Explanation
One sealed meal kit, any kitchen with an open burner—Kubernetes schedules the same image wherever capacity exists. SSH pip install on node-3 is a snowflake, not CD integration.
Full Explanation
Docker and Kubernetes CD integration schedules the same container image onto whichever node has capacity; it avoids unique host installs per node. On-call runbooks that SSH to node-3 and pip install the DNA dashboard wherever capacity appears create snowflakes and fight the scheduler. The civic pattern is one sealed image, many possible nodes—not per-host package rituals that drift from the CD path.
Maintaining a snowflake pip install on each worker and skipping container images entirely abandons the CD image contract and guarantees configuration drift across the fleet. Requiring underlay STP tuning before any image may be scheduled confuses Layer-2 topology chores with application delivery and invents a blocking dependency the orchestrator does not need. Binding the app permanently to node-3 by hostname and never rescheduling destroys the point of cluster capacity scheduling and creates a single point of failure.
Exam caveat: node affinity may exist for special hardware, but the default integration story is portable images scheduled by the cluster—not SSH install playbooks. Operational check: deploy the DNA dashboard as a workload using one image tag, cordon or drain a node, and confirm the pod reschedules elsewhere without a manual pip install on the new host.