What Rook does with Ceph, and where the README stops

Rook hands Ceph's lifecycle to a Kubernetes operator

Ceph is the storage system here: a distributed one serving file, block and object storage, already used in large scale production clusters. What Rook contributes is the layer that binds it to Kubernetes, described as the platform, framework and support for Ceph to integrate natively.

The work happens in an operator that builds on Kubernetes resources to deploy, configure, provision, scale, upgrade and monitor Ceph. Read that verb list as the contract. Storage lifecycle stops being a set of daemons you touch on individual hosts and becomes objects you submit to the API server, which means cluster RBAC, quotas and namespace boundaries apply to your storage the same way they apply to a Deployment. Rook calls the result self-managing, self-scaling and self-healing storage services.

The README carries no install command and no version matrix

Expect to leave the repository for the first step. Installation, deployment and administration are handed to the documentation site at rook.github.io/docs/rook/latest-release and to a QuickStart Guide at rook.github.io/docs/rook/latest-release/Getting-Started/quickstart. No command is printed: nothing to apply, no chart reference, no namespace to create. INSTALL.md does sit in the repository root, but the README never points at it or describes what is inside it.

That choice costs anyone pinning a release. Nothing in the README says which Kubernetes version or which Ceph version a given tag supports, so the compatibility matrix lives on a hosted site that changes independently of the tag you checked out. Go read the version support page there before you commit. The repository will not answer it.

Master branch builds carry no compatibility support

The project's own warning is blunt. Official releases are strongly recommended, and builds from the master branch are described as subject to changes and incompatibilities that the official releases will not support. The following sentence is the part that matters for planning: functionality in a master build can be changed and even removed at any time, without compatibility support and without prior notice.

So a master build cannot promise an upgrade path. Deploy one and the tag you later move to may no longer accept the custom resources your cluster has been running, and reconciling that difference falls to you with no release note explaining the change. On a storage layer the objects in question describe where data lives, which makes that a bad trade. Install a tagged release and keep the tag next to your other version pins.

Only the Ceph provider is labelled Stable

Rook assigns a status to its storage providers, and the only status the README gives is Stable, for Ceph. Features and improvements are planned for many future versions, and upgrades between versions are provided to ensure backward compatibility between releases.

Read that narrowly. The sentence covers one provider, and the README says nothing about the status of any other.

For a reader choosing between providers, the honest summary is that Rook calls Ceph Stable and says nothing about the rest. Hold any non-Ceph integration to its own documentation before assuming the compatibility sentence covers it, because that sentence was written about Ceph.

One replace directive sends the build to a fork Rook does not own

Dependencies are declared in go.mod, where the module is github.com/rook/rook built against go 1.26.4. Three replace directives sit at the top of that file, and one deserves a close read:

replace (
	// TODO: remove this replace once https://github.com/libopenstorage/secrets/pull/83 is merged
	github.com/libopenstorage/secrets => github.com/rook/secrets v0.0.0-20240315053144-3195f6906937
	github.com/portworx/sched-ops => github.com/portworx/sched-ops v0.20.4-openstorage-rc3
	github.com/rook/rook/pkg/apis => ./pkg/apis
)

Two consequences follow for anyone compiling from source. The secrets module resolves to a fork in the rook organisation at v0.0.0-20240315053144-3195f6906937, and the comment above it says the override exists only until a pull request in the original repository merges, so the module you build against is not what upstream publishes. The sched-ops pin names a release candidate, v0.20.4-openstorage-rc3, and a candidate in the build path is a version that can still move. The third line keeps the API types local to ./pkg/apis, so that directory has to travel with the rest of the tree. Among the pinned dependencies, ceph-csi and go-ceph v0.42.1 tie the operator to a specific Ceph client and provisioner, which is the other place a version mismatch will surface.

The Makefile pins six tools and one image digest

Building from source means matching Rook's toolchain, and the Makefile fixes it by hand:

CONTROLLER_GEN_VERSION=v0.19.0
CT_VERSION := v3.13.0
KUSTOMIZE_VERSION := v5.3.0
MARKDOWNLINT_IMAGE_VERSION := v0.22.0
SHELLCHECK_VERSION := v0.10.0
BLACK_VERSION := 26.5.1

The default goal is build. The yamllint container is not tracked by tag but by digest, which is the stricter choice:

YAMLLINT_IMAGE_SHA ?= sha256:3e9eb827ab2b12a5ea5f49d4257bb3aca94bba9f1ba427c8bc7f2456385a5204

Rook records how that value is refreshed, reading the published digest of the latest tag with podman:

podman inspect --format='{{index .RepoDigests 0}}' docker.io/cytopia/yamllint:latest

Run that line before you touch the digest in a fork or an internal mirror. Build ordering does not come from your shell either: the Makefile exports LC_ALL=C, with comments explaining that different operating systems sort files differently and that C ordering is based on byte values, which is what keeps generated output deterministic across machines.

Rook against a Ceph you run yourself

The alternative is not another piece of software. It is no operator, with Ceph deployed directly and administered by the team that owns the hosts, an arrangement Ceph already supports since it runs in large scale production clusters.

The difference is where each decision lands. Direct administration leaves daemon placement, configuration changes, upgrades and provisioning with the cluster team. Rook moves those same verbs into an operator that reconciles Ceph through Kubernetes resources, so a change travels as an API object carrying the same review trail and permission model as the workloads around it. Storage stops being a separate operational lane.

No document in the repository settles the argument. There is no throughput figure, no failure-rate claim and no statement about how much operator overhead disappears, so a team already administering Ceph competently has no documented gain from adding the operator, while a team that wants storage to look like the rest of its cluster does. Judge it on that control plane question, not on performance, because no performance evidence is published.

Vulnerabilities go to a mailing list, not a tracker

Security reporting is deliberately kept off the issue tracker. The README asks that a vulnerability, or a possible one, be sent to [email protected], with a commitment to send a confirmation email on receipt and a further email once the issue has been identified as positive or negative. The full process sits in SECURITY.md at the repository root.

Nothing in that flow happens in public, so a reporter gets no issue number to reference and the timeline is invisible to everyone outside the list. That is the correct trade for a coordinator, and it does mean you cannot watch Rook's security response the way you watch a bug tracker.

Automated checks run alongside it rather than in place of it: a snyk.yaml workflow under .github, a .snyk file at the top level, and OpenSSF Scorecard, Go Report Card and FOSSA license badges in the README. Scanners read the declared dependency list, and a replace directive points one entry at a different repository, which is worth keeping in mind when you audit your own build. Routine bugs go the other way, to a GitHub issue, where the discussion is public by default.

Editorial conclusion

Rook suits teams that already run Ceph and want its lifecycle to be a set of Kubernetes objects rather than per-host administration. It does not suit a team shopping for a storage system, because Rook ships no storage engine of its own, and it does not offer a case against a competent Ceph team that needs none. Check two things before installing: the Kubernetes and Ceph version matrix on rook.github.io, which the README does not carry, and whether a tagged release rather than a master build is what reaches your nodes.

Frequently asked questions

Official sources

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