Rook

What it is

Rook is a Kubernetes storage orchestrator. It doesn't provide storage itself — it automates the deployment, configuration, scaling, upgrading, and day-2 operations of storage systems running inside Kubernetes, with Ceph as its primary (and now effectively only actively maintained) backend. Think of it as an operator that turns "run Ceph" into "run a CRD" — you declare a CephCluster, CephBlockPool, or CephFilesystem object, and Rook reconciles the actual Ceph daemons (mons, OSDs, MDS, RGW) to match.

It exposes block (RBD), file (CephFS), and object (RGW/S3-compatible) storage through standard Kubernetes primitives — StorageClasses, PVCs, CSI drivers — so workloads consume storage without knowing Ceph is underneath.

Who builds it and why

Rook is a CNCF graduated project, which means it's cleared the bar for adoption breadth, governance, and maturity that CNCF requires — not a rubber stamp. 680 contributors and active commit history (latest as of mid-2026) indicate this isn't a project running on fumes. Contributors come primarily from the Ceph/Rook ecosystem itself and companies operating Kubernetes storage at scale — the motivation is straightforward: Ceph is powerful but operationally brutal to run by hand, and Rook exists to make Ceph tractable inside a Kubernetes control plane instead of requiring a dedicated storage ops team.

Production readiness signal

Graduated CNCF status plus 13.5k GitHub stars and 680 contributors is a strong maturity signal. v1.20.1 as the latest release indicates a long, incrementally versioned history rather than a project still finding its API surface. Rook has been running in production storage stacks for years at this point — it's not bleeding edge.

That said, "Rook is mature" and "Ceph is easy" are different claims. Rook removes deployment toil; it does not remove the need to understand Ceph failure domains, CRUSH maps, and rebalancing behavior when a node dies. Production readiness here means the orchestration layer is solid — your team still needs Ceph literacy to operate it well at scale.

Who should use this

• Teams already committed to Ceph who want it Kubernetes-native instead of managed by a separate ops team with Ansible playbooks.
• Platform teams building on-prem or bare-metal Kubernetes clusters that need block/file/object storage without buying a commercial SAN or cloud-managed service.
• Organizations that need a single storage substrate serving multiple protocols (block + file + object) rather than stitching together three separate systems.
• Anyone who has the operational appetite to run distributed storage themselves, in exchange for avoiding cloud storage costs or vendor lock-in.

Who should NOT use this

• Teams running in a public cloud where EBS/Azure Disk/Persistent Disk plus a managed object store (S3, GCS) already meets requirements — Rook adds real operational surface area for no benefit there.
• Small clusters or small teams without dedicated storage/SRE capacity. Ceph under load, under-provisioned, or under node churn is unforgiving, and Rook won't hide that complexity when things go sideways.
• Anyone needing extreme low-latency or NVMe-native performance where Ceph's replication/erasure-coding overhead is a poor fit — look at something more specialized.
• Teams wanting a "set and forget" storage layer. Rook still requires you to understand PG counts, OSD sizing, and recovery behavior — it automates mechanics, not decisions.

Alternatives

• OpenEBS — simpler, more modular Kubernetes-native storage, lower operational ceiling but easier entry point for smaller clusters.
• Longhorn — lightweight distributed block storage built for Kubernetes, less powerful than Ceph but dramatically simpler to run.
• Portworx — commercial, enterprise-support-backed alternative if you want vendor accountability instead of self-operated Ceph.

Pricing

Fully open source, Apache-2.0 licensed. No paid tier, no commercial entity behind Rook itself gating features. Cost is entirely operational — infrastructure and the engineering time to run Ceph correctly.