You can pin a service to a particular node when it needs that machine’s architecture or location. If the node becomes unavailable, the service waits for it; it does not move to another node.
Hakopod alpha.21 adds the Run on node picker and the corresponding node_name field for this placement rule.
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.
A capacity check does not reserve resources
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.
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.
Leave scheduling automatic unless the service needs a particular node. 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.