kured: rebooting one Kubernetes node at a time, safely

Four behaviours, and the lock is the important one

The README lists what kured does in four bullets, and one of them is why this project exists. It watches for the presence of a reboot sentinel file such as `/var/run/reboot-required`, or for the successful run of a sentinel command. It uses a lock in the API server to ensure only one node reboots at a time. It optionally defers reboots in the presence of active Prometheus alerts or selected pods. And it cordons and drains worker nodes before the reboot, uncordoning them afterwards.

Read those in order and the design is clear. The package manager on the operating system decides a reboot is needed, which means the trigger is the same signal Ubuntu, Debian and their relatives already use. kured does not decide whether patches should be applied or when; it reacts to a signal the OS already emitted.

The API server lock is what makes this safe to run across a fleet. Without it, every node holding the sentinel file would reboot at once, which is precisely the outage the daemonset exists to prevent. A node also has to be cordoned and drained before it restarts, so its pods are rescheduled rather than killed, and uncordoned when it comes back.

The deferral behaviour is the part that connects kured to the rest of an operations setup. A reboot can be postponed while Prometheus alerts are firing or while particular pods are running, which is how you avoid taking a node down in the middle of an incident you are already handling.

A CNCF sandbox project with an unusually formal process

kured is a Cloud Native Computing Foundation Sandbox project, which the README states in its trademarks section. The badges at the top of the README reinforce the institutional weight: an Artifact Hub badge for the Helm chart, a CLOMonitor badge, an OpenSSF Best Practices badge, and FOSSA for licence scanning.

The process is laid out with the same care. Questions go to the CNCF Slack in the `#kured` channel, or as a GitHub issue. There is a monthly meeting on the first Wednesday of the month at 16:00 UTC with a linked agenda document, and a developer mailing list at `lists.cncf.io`. The project follows the CNCF code of conduct.

For a tool with 2,575 stars and 233 forks, that level of process is a signal about who depends on it. A cluster operator is putting automated reboots into their production fleet, and the surrounding process is part of the product.

The release history matches. Versions 1.22.0 on 2026-05-26, 1.22.1 on 2026-06-08 and 1.23.0 on 2026-06-30 are all small releases, dominated by dependabot bumps for actions, Alpine base images and the Prometheus client library, plus Go module updates to the latest Kubernetes libraries. The 1.22.1 release also includes a Go bump described as fixing a CVE.

Why the boring dependency releases are still news

Look at what is inside the 1.23.0 release and a pattern emerges. It bumps mise, reverts that mise bump in the very next pull request, bumps golangci-lint, updates kured to the latest Kubernetes modules, and then runs through a list of build dependency updates for actions/stale, the mise action, checkout, docker login, the Prometheus common library and Alpine.

The 1.22.0 release shows the same shape across a longer list, including the Alpine base image moving from 3.22.2 to 3.23.3, the setup-qemu action, a harden-runner bump, the setup-go action, and a logrus update.

A project whose releases are almost entirely dependency maintenance is a project where the upstream surface is the risk. kured talks to the Kubernetes API through client libraries and ships as a container built on Alpine, so every relevant vulnerability in those dependencies becomes a kured release. There are no user-facing features in these three releases, and that is not a criticism: for infrastructure at this level, staying current on the base image and the client libraries is the work.

A bump-then-revert pair for the same dependency in the same release is also a small sign of an active reviewer rather than a purely automated pipeline.

What the README does not tell you

The README is short, and almost everything operational is on kured.dev. It links an installation page, a configuration page, an operation page and a development page, under a general documentation link, and then stops.

That means the questions you would need answered before deploying are not answered here: which RBAC permissions the daemonset needs, how the lock is represented and what happens if a node dies mid-reboot, what the drain timeout is, how the Prometheus alert check is configured and whether it needs a Prometheus URL or Kubernetes discovery, and what the sentinel command interface looks like. All of that is on the documentation site.

The repository tree is small, which is consistent with a focused tool. The code lives under `src/`, there is a `Makefile`, a `Dockerfile`, chart files for the Helm package, and the usual repository metadata including a code of conduct.

There is also no runnable command anywhere in the README, which reflects how the project expects to be installed: as a Helm chart from Artifact Hub rather than as something you clone and invoke. The README's own description, a Kubernetes daemonset that performs safe automatic node reboots, is the most accurate summary available in the repository itself.

What kured replaces and what it does not

The alternative to kured is a cron job that runs a script on each node, or an infrastructure management tool that reboots instances. Both work until a cluster has enough nodes that rebooting them simultaneously is an outage, which is the entire problem kured solves.

Against a configuration management tool such as Ansible or a cloud instance manager, kured's advantage is trigger specificity. It does not decide that a node should reboot on a schedule or after an instance replacement; it waits for the operating system's own package manager to say a reboot is required, which is a signal tied to actual pending changes rather than to your configuration drift.

Against a rolling update mechanism, the distinction is ownership. A node reboot is not a pod or deployment change, so the tools that roll out workloads do not own it, and the tools that own instances generally cannot coordinate through the Kubernetes API.

What kured explicitly does not do is patch anything. It applies no updates. It reacts to a sentinel the package manager leaves behind, which means the update itself comes from your existing unattended-upgrades or image build process.

Editorial conclusion

kured solves a narrow problem that is genuinely hard to solve safely: an unattended kernel or base image upgrade on every node in a cluster without taking the cluster down. The lock in the API server is the part that makes it a rolling operation rather than a simultaneous one, and the cordon and drain is the part that respects your disruption budgets. Version 1.23.0 shipped on 2026-06-30 as a dependency maintenance release, with a repository push on 2026-09-28. Start at the installation guide on kured.dev, then read the configuration page for the alerting and pod deferral settings.

Frequently asked questions

Official sources

1. kubereboot/kured on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases