Talos machine.yaml reboot flag during in‑place application migration

Goal

Move a small, single‑replica Kubernetes application from one Talos node to another while keeping the service available.

Constraints & Uncertainty

Updating the machine.yaml to adjust kubelet arguments typically triggers a node reboot. Talos does not automatically cordon or drain the node, and pod disruption budgets are not respected during the upgrade. It is unclear whether the reboot will evict the running pod before the new node is ready to host it, potentially causing downtime.

Key Questions

1. Does applying a machine.yaml that changes kubelet arguments always require a node reboot, or can the change be applied live?
2. If a reboot is mandatory, can we safely cordon and drain the node before talosctl apply to ensure the pod is rescheduled elsewhere without violating its disruption budget?
3. Does Talos provide any built‑in mechanism to coordinate the reboot with Kubernetes pod eviction, or must this be orchestrated manually?