“Run this one here” sounds like the simplest possible scheduling rule. Sometimes it is exactly the rule you need. A machine may have the architecture, locality or operational role you want for a particular service.
Hakopod alpha.21 adds a Run on node picker and the corresponding node_name field. The useful part is explicit placement. The part worth reading twice is what happens when the chosen machine is unavailable.
A pin narrows the scheduler’s choices
Automatic placement lets Kubernetes choose among eligible nodes. A pin reduces that set to one named node. Architecture, taints, resource requests and runtime allocation still apply; the pin does not bypass them.
All replicas of a pinned service go to that node. Two replicas on one machine can help with some process-level problems, but they do not survive the loss of that machine. If the node disappears, the service waits for it rather than moving somewhere else.
That behavior is deliberate. A preference that silently became a different placement could break the assumption that made you choose the machine in the first place. If mobility matters more, keep placement automatic.
Capacity checks are a conversation with the present
The plan checks node availability, architecture and known resource capacity. It can reject an obviously unsuitable choice before deployment.
It does not reserve the observed capacity. Another deployment can consume resources after you read the plan, and a rolling update may temporarily need room for old and new pods. Leave headroom instead of treating a passing check as an allocation guarantee.
The name matters too: node_name is the Kubernetes node name. An IP address or a friendly VM label will not stand in for it. Use the picker to see the available choices for the current scope.
Storage makes placement a data decision
A local volume belongs to its original node. Changing a line in TOML does not copy its contents to another server. Hakopod rejects a pin that conflicts with known volume placement, which is much more useful than letting a new empty directory look like a successful migration.
If you need to move a stateful service, plan the data migration or restore first. Check the destination, access permissions and recovery procedure before changing placement. Removing a pin does not move data either.
Our default advice is ordinary: leave scheduling automatic until you have a reason to constrain it. When you do, write that reason beside the operational runbook so the next person understands why the service waits for a specific machine.
The node placement guide covers configuration, capacity checks and the storage boundary.