k3os and systemd: What is the impact of kubelet's stop timeout on pod termination?

k3os ↔ systemd: graceful kubelet shutdown

The goal is to understand how the stop timeout configured in the kubelet.service unit influences the termination of running pods when a k3os node is powered down or reset. In k3os the kubelet is launched as a systemd service with TimeoutStopSec=0 by default, meaning that a SIGTERM is followed immediately by a SIGKILL. This can leave stateful workloads in an indeterminate state, potentially causing data corruption.

Constraints include the fact that the timeout is not exposed as a k3os CLI flag, and that systemd overrides may be lost during upgrades. The uncertainty lies in whether k3os should automatically set a non‑zero stop timeout or provide a higher‑level configuration option.

Given these conditions, we need to clarify:

• What is the current TimeoutStopSec value on a fresh k3os installation, and how does it change after a reset or upgrade?
• Does the kubelet process receive a SIGTERM and wait for pod termination before systemd enforces the timeout?
• What is the recommended approach to ensure graceful pod shutdown without manual unit file edits?