One k3s node, four months of CPU starvation, three false fixes
TL;DR One worker in my home k3s cluster, k3s-agent-4, has been starved for CPU on and off since 2026-06-13. I’ve written about it in my cluster knowledge base more than a dozen times. It was declared fixed at least once and the declaration was falsified twice. “Quiet for a few weeks” turned out to be temporary. What the node showed: requests at 87 percent, limits at 629 percent of CPU, probes timing out, and Longhorn’s engine-image pod restarting hundreds of times. The alert I’d written for this could not fire on a node starved enough to silence its own exporter. Replacing it was the most useful change of the whole saga. The latest and most promising finding is physical: the Proxmox host under that VM clamps its CPU to 800 MHz under load (BD PROCHOT). As of early October that is open, not fixed. This is a post about the shape of a chronic problem, and how many plausible explanations can be true at once. The cluster in one paragraph The home cluster is four Proxmox hosts running k3s VMs: a control plane and four workers, with Longhorn for storage. (It used to have three control planes, until I collapsed it to one on 2026-09-05.) Workers have 6 to 10 vCPU each. The worker in this story lives on the fourth host, the only one with hyperthreading: an i7 with six physical cores and twelve threads, hosting the 10-vCPU agent. ...