Rook: a Kubernetes operator that runs Ceph for you

The gap Rook fills between Kubernetes and Ceph

Kubernetes gives you a PersistentVolumeClaim API and nothing behind it. Ceph gives you distributed file, block and object storage, but it expects you to run monitors, OSDs, managers and metadata servers, wire up the CRUSH map, and keep all of that alive across failures. The distance between those two facts is where most storage projects live, and it is the distance Rook is built to close.

The README describes Rook as an open source cloud-native storage orchestrator for Kubernetes, providing the platform, framework and support for Ceph to natively integrate with Kubernetes. The operator, in the README's words, deploys, configures, provisions, scales, upgrades and monitors Ceph by building on Kubernetes resources. The audience is a platform or infrastructure team already running Kubernetes that wants Ceph's three storage types without writing its own control plane for them. The README also states that the Ceph storage provider is Stable and that upgrades between versions are provided to ensure backward compatibility between releases, which is a stronger claim than most operators make.

How the operator drives Ceph through custom resources

The mechanism is the standard Kubernetes operator pattern, but the scope is larger than most. Rook ships custom resource definitions and a controller; when you create a CephCluster resource, the operator reconciles it into the DaemonSets, Deployments and configuration that Ceph needs. The same pattern covers block pools, filesystems and object stores, which is why the README can describe the result as self-managing, self-scaling and self-healing storage services.

The repository layout backs this up. The pkg/ directory holds the operator logic, deploy/ holds the manifests and Helm charts used to install it, and pkg/apis is a separate Go module referenced through a replace directive in go.mod, so the API types can be consumed independently of the operator. The go.mod file also lists the Ceph client bindings and the CSI driver packages among its direct dependencies, which tells you the operator is not a thin wrapper around shell commands: it talks to Ceph through Go libraries and through the CSI layer that Kubernetes itself uses.

One consequence of that design is worth stating plainly. Rook is an orchestrator, not a storage implementation. If Ceph cannot keep quorum on your hardware, no amount of reconciliation in Rook will fix it, and the operator will faithfully report a cluster that is not healthy.

Installing Rook and creating a first Ceph cluster

The README does not include install commands. It points to the Documentation site and the QuickStart Guide at rook.github.io/docs/rook/latest-release/Getting-Started/quickstart for installation, deployment and administration. That is the authoritative source, and the versions of the manifests and Helm charts move with each release, so copying a snippet from a blog post is a good way to end up with CRDs that do not match the operator image.

What the repository does show is the shape of the work. The deploy/ directory holds the manifests, and the top-level Makefile carries the tool versions the project pins for its own build, including kustomize v5.3.0 and controller-gen v0.19.0. Those pins matter because the CRDs are generated, and a mismatched generator produces schemas the operator will reject.

A first cluster follows the QuickStart's sequence: apply the common resources, then the operator, then a CephCluster manifest naming the nodes and devices Ceph may use. Once the cluster reports healthy, you create a pool or a filesystem and point a StorageClass at it. The README's own framing of the operator's job is the useful mental model here: you declare the storage you want as a Kubernetes resource, and Rook builds and maintains the Ceph components that deliver it.

Where Rook stops being the right answer

The strongest argument against Rook in a small environment is arithmetic. Ceph is designed for scale, and the README says so directly, describing it as a distributed storage system deployed in large scale production clusters. A three-node home lab can run it, but the operator, the monitors and the OSDs all consume CPU and memory on the same machines that are supposed to be serving your workloads, and the failure modes you inherit are Ceph's, not Kubernetes'.

There is a second limitation in the release process itself. The README recommends using official releases and warns that unreleased versions from the master branch are subject to changes and incompatibilities that will not be supported in the official releases, and that builds from master can have functionality changed or removed at any time without compatibility support and without prior notice. That is a normal policy, but it means the master branch is not a staging environment you can lean on.

The third constraint is version pairing. The repository lists v1.20.7 and v1.19.11 both released on 2026-09-02, with v1.20.6 before them. Two maintained lines are a benefit for teams that need to stay on an older Kubernetes version, and a trap for anyone who assumes the newest tag is the only one that matters. The README does not document an in-place rollback path between Rook versions, so an upgrade that goes wrong is a forward fix, not a revert.

Rook against plain Ceph and against CSI drivers alone

The honest alternative is running Ceph yourself and pointing a CSI driver at it. The difference is where the lifecycle work sits. With Rook, the CephCluster resource is the source of truth and the operator reconciles the daemons, the configuration and the upgrades toward it. Without Rook, you own the cephadm or manual deployment, the upgrade sequencing, and the monitoring integration, and you gain direct control over every knob.

A second alternative is using only a CSI driver against external storage, whether that is a cloud block service or an NFS server. That path is far simpler and needs no operator at all, but it gives you no distributed filesystem, no object gateway and no self-healing across nodes. Rook's value is concentrated in the cases where you want all three storage types on hardware you control.

The comparison is not about which is better in the abstract. Rook is the right layer when you have decided you want Ceph and you want Kubernetes to be the control plane for it. If either half of that sentence is false, the operator is overhead.

Maintenance, release cadence and the Apache-2.0 terms

The last push to the default branch was on 2026-09-21, and the most recent releases are v1.20.7 and v1.19.11 from 2026-09-02. The project is not archived. That combination describes a repository with ongoing maintenance, and it also tells you the practical upgrade cost: two release lines are being patched at once, so you choose a line and follow it rather than jumping between them.

Upgrade cost is mostly the operator plus the CRDs plus Ceph itself. The README states that upgrades between versions are provided to ensure backward compatibility between releases, but it does not describe a downgrade procedure, so treat each upgrade as one-way and stage it somewhere that is not production first. The PendingReleaseNotes.md file at the repository root is where the project records changes ahead of a release, and reading it before an upgrade is cheaper than reading it after.

Licensing is Apache-2.0, stated in the README and present as the LICENSE file at the repository root. That is a permissive licence with an explicit patent grant and no copyleft obligation on your own code. It says nothing about the licences of the Ceph components Rook deploys or of the container images you pull, and those are separate questions this repository does not answer. Nothing here is legal advice; if your organisation has a licence review process, the Apache-2.0 text and the dependency list in go.mod are what that process will want.

Editorial conclusion

Adopt Rook if you already run Kubernetes and need Ceph's file, block and object storage managed through custom resources rather than assembled by hand, and you can accept that the operator, the CRDs and Ceph itself all move together. Do not adopt it for a single node, a single PersistentVolume, or a team without the appetite to learn Ceph's failure modes. Before committing, read the QuickStart guide, confirm which Rook release matches your Kubernetes version, and decide whether you will track v1.20.x or stay on v1.19.x, because the project ships both lines in parallel and mixing them is not a supported path.

Frequently asked questions

Official sources

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