Kubereboot/Kured: Kubernetes Reboot Daemon
ankitg12
19 points
10 comments
April 30, 2026
Related Discussions
Found 5 related stories in 81.9ms across 8,303 title embeddings via pgvector HNSW
- K3k: Kubernetes in Kubernetes jzebedee · 12 pts · May 02, 2026 · 56% similar
- Copy-fail-destroyer: K8s remediation for CVE-2026-31431 evenh · 17 pts · April 30, 2026 · 45% similar
- Rusternetes : A ground-up reimplementation of Kubernetes in Rust mariuz · 12 pts · April 29, 2026 · 45% similar
- Show HN: Kstack – Skill pack for monitoring/troubleshooting K8s in Claude Code andres · 19 pts · May 07, 2026 · 43% similar
- Show HN: Kula – Lightweight, self-contained Linux server monitoring tool c0m4r · 30 pts · March 07, 2026 · 42% similar
Discussion Highlights (4 comments)
edude03
Insert the "No god no" meme here - you really shouldn't be updating nodes in place and thus shouldn't be restarting nodes. I'm aware bare metal exists and it's not always practical to just provision more servers, yet I think for most workloads you're not getting the benefit of Kubernetes if you have say 3 servers and lose 1/3 of your capacity to do software updates.
AntiUSAbah
I like it. K8s should be more opiniated about this. Whats also missing is rebalancing of pods. Rescheduler
adamtulinius
Almost 3000 lines of code for automating draining nodes and rebooting it. And it requires that another component has already queued up an update that requires a reboot. Looking at the issues, people try to shoehorn a thousand unique behaviours into a general purpose tool, just to avoid a bit of old school sysadmin-ing. There's a guy wanting to change TZ of the running cluster, and want "Kured" to support that use case so it's only updated during night - in an ever changing TZ.
captn3m0
What’s the usecase where you are okay cordoning a node but not okay with just terminating it and starting a new one? Physical nodes where you have to reclaim them and don’t run any virtualisation ?