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

Direct answer

No, changing kubelet arguments in machine.yaml does not always force a Talos node reboot. Talos decides whether to reboot from the configuration diff; many kubelet argument changes restart the kubelet container only, while kernel, boot, containerd, or node-identity changes can require a reboot. The exact boundary depends on the installed Talos version.

Confirmed facts versus likely explanation

Item	Status
Talos automatically cordons or drains Kubernetes nodes	Not confirmed; Talos does not perform Kubernetes cordon or drain during talosctl apply-config.
Talos respects pod disruption budgets during a reboot	Not confirmed; PDBs are evaluated by Kubernetes, not by Talos, and a required reboot can evict a single replica before the target node is ready.
Built-in coordination between Talos reboot and pod eviction	Not confirmed; orchestration must be done manually with kubectl cordon and kubectl drain.

Steps for this migration

1. Confirm the target Talos node is Ready and schedulable.
2. Run kubectl cordon <source-node> to prevent new scheduling.
3. Run kubectl drain <source-node> --ignore-daemonsets --delete-emptydir-data. If the application has a PDB with minAvailable: 1 and only one replica, drain may block; temporarily add a second replica or adjust the PDB before draining.
4. Verify the application pod is Running on the target node.
5. Apply the Talos configuration: talosctl apply-config -f machine.yaml -n <node-endpoint>. Reboot only if the command output or Talos indicates a reboot is required.
6. Wait for the source node to return to Ready, then run kubectl uncordon <source-node>.

Missing diagnostic detail

Please provide the installed Talos version (talosctl version). Whether your specific kubelet argument change triggers a reboot versus a live kubelet restart is version-sensitive, and the answer changes whether you must plan for a reboot window.

Verification

• kubectl get nodes — confirm the target node is Ready before draining the source.
• kubectl get pods -o wide — confirm the application pod rescheduled to the target node.
• kubectl describe pdb <pdb-name> — confirm the PDB allows eviction or plan for a standby replica.
• talosctl version — confirm the release before applying machine.yaml to production.

Treat this as a draft for human review until the Talos version is confirmed. Assumptions: you are using kubectl against the same Kubernetes cluster managed by Talos, and you have access to the Talos node endpoints. Test this sequence on a non-production node first; applying an invalid machine.yaml can make a node unreachable.