Kubelet systemd watchdog diagnostic guardrails

[googs1025]

/sig node
/kind feature
/stage alpha

Summary

Improve kubelet's Linux systemd watchdog integration so operators can identify why watchdog heartbeats stopped before a systemd-triggered kubelet restart.

Motivation

Today kubelet may stop notifying systemd because a watchdog health checker fails, a checker stalls, SdNotify() returns an error, or SdNotify() blocks. Operators often only see the eventual watchdog-triggered restart, without enough pre-restart evidence to identify the source.

This enhancement is intended to provide bounded execution and default-visible diagnostics for the existing kubelet systemd watchdog path.

Scope

• Per-check timeout diagnostics for kubelet watchdog health checkers.
• Timeout diagnostics around SdNotify().
• Default-visible structured logs for SdNotify() returned errors and timeout paths.
• Retry summary logging when watchdog notification retries are exhausted.
• Unit tests for success, checker error, checker timeout, notify error, notify timeout, retry, watchdog-disabled, and non-Linux compatibility paths.

Non-Goals

• No kubelet config API changes.
• No metrics, events, or NodeCondition in the initial scope.
• No non-Linux behavior changes.
• No redesign of kubelet health checking.
• No broader node self-healing behavior.

Related Issue

• Kubelet watchdog: improve logging visibility and add internal timeouts kubernetes#135449

Notes

The initial design intent is to keep this focused on operational diagnostics and internal kubelet watchdog guardrails. If SIG Node prefers this to proceed as a focused implementation PR instead of a KEP, this issue can be closed or repurposed based on reviewer guidance.

[googs1025]

/assign