k3s embedded API server and agent watch clients: who owns reconnection timing after a dropped watch?

Where the components meet

k3s runs an embedded API server in the server process; each agent watches it through a standard client-go client. They meet at the watch stream: the server side honors context cancellation and closes the stream, while the agent side reconnects using client-go's default exponential backoff, commonly capped near 30 seconds, with the initial delay set by the bundled client-go version.

The open decision

The goal is to determine whether that reconnect timing can be tuned for clusters where short control-plane interruptions should not leave agents retrying on a fixed curve, or whether the default must be accepted as-is. No k3s-specific flag for watch reconnection is known in the documentation, effective values can shift with the client-go version bundled per release, and patching the agent binary is unsupported and complicates upgrades. Assume a currently supported v1.3x-series release; the exact initial delay and cap should be confirmed for that release before relying on them.

Specific questions

• Does any supported k3s mechanism—flags, environment variables, or generated kubeconfig fields—change the agent's watch reconnect backoff?
• After the server cancels a watch context, does the agent's next retry restart at the backoff floor or continue climbing the curve?
• Do server-side watch timeouts combined with agent-side backoff bound the worst-case staleness of node and secret watches?