Rook 1.21 makes Ceph msgrv2 the default protocol

6 October 2026. Version 1.21.0 of Rook was released by travisn, one of the maintainers, with a major breaking change: the msgrv2 protocol of Ceph becomes mandatory by default. 6 October 2026. The Helm OCI chart tags drop the v prefix (1.21.0 instead of v1.21.0). 6 October 2026. Support for Ceph Umbrella (v21) is announced, pending the release of Ceph 21.2.0. Why it matters: msgrv2 requires a Linux 5.11 kernel or newer — a cluster running older nodes may fail outright after the upgrade.

A breaking change in the heart of the data plane

Rook is the Kubernetes operator that orchestrates Ceph: it deploys monitors, OSDs, and services, and continuously reconciles cluster state against the CephCluster resource. Much of its value lies in hiding Ceph’s complexity — until a breaking change surfaces it again.

msgrv2 is Ceph’s modern messaging protocol, the one that encrypts and authenticates exchanges between cluster daemons. It has been Ceph’s default for several releases, but Rook had left the door open to the legacy msgrv1 protocol. 1.21.0 closes that door: msgrv2 is required by default, and that requirement depends on a precise system prerequisite — the Linux 5.11 kernel, introduced in February 2021.

For context, msgrv2 arrived with Ceph Nautilus (v14, 2019) and became the default protocol for new clusters starting with Octopus (v15). Its value is twofold: encryption of exchanges between daemons and stronger authentication through the cephx entity, whereas the legacy msgrv1 left part of the traffic in cleartext. Dropping msgrv1 therefore closes a network exposure surface on the data plane — but at the cost of a kernel requirement that not every fleet has met yet.

Why the 5.11 kernel is the tipping point

The constraint does not come from Rook itself but from how the in-kernel Ceph client (krbd, the RBD driver) negotiates the connection. msgrv2 relies on kernel features that only exist from 5.11 onward. Below that, a node cannot establish the encrypted connection the protocol requires — and RBD volumes mounted on those nodes fail.

This is exactly the kind of detail that bites at the worst moment. Ubuntu 20.04 ships a 5.4 kernel, RHEL 8 a 4.18, CentOS 7 a 3.10: all platforms still present in fleets that have not been refreshed. An operator who upgrades Rook to 1.21 on those nodes without checking the kernel can turn a routine version change into a storage outage.

The escape hatch is documented in the release notes: to stay on the old protocol, explicitly disable msgrv2 via the network.connections.requireMsgr2: false field in the CephCluster resource — or, when using the Helm chart, under the cephClusterSpec key in the values.

# CephCluster: keep msgrv1 on nodes running a kernel below 5.11
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  network:
    connections:
      requireMsgr2: false

The trap is that this opt-out is not a “neutral” state: it keeps a protocol that Ceph itself treats as legacy. On a mixed fleet, where some nodes are current and others are not, the check must be done node by node — a single node below 5.11 is enough to break the RBD volumes mounted there, even if the rest of the cluster is healthy.

The two other breaking changes

1.21.0 contains two more, less dangerous but worth knowing before upgrading:

• Helm OCI chart tags drop the v prefix: a script or pipeline that references the chart by tag (v1.21.0) must switch to 1.21.0. Auto-update tooling that parses versions is affected first.
• New NFS installs must define their own CephBlockPool for the .nfs pool: Rook no longer creates that pool automatically. Existing clusters are unaffected, since the pool already exists.

What 1.21 gives in return

The release is not only breaking changes. The headline is announced support for Ceph Umbrella (v21), the next major Ceph release, usable once 21.2.0 ships. Three concrete operational additions follow:

• RBD QoS: quality of service on volumes is configured through VolumeAttributesClass, with io.max enforcement carried by cgroup v2 and the krbd mounter.
• Automated OSD replacement: an OSD deployment can be annotated to mark it for replacement; Rook drains and destroys it while preserving its CRUSH position, to reuse it when a new device arrives on the node.
• Dashboard TLS certificates: they can now come from a same-namespace Kubernetes Secret via spec.dashboard.sslCertificateRef.

Finally, the CSI driver container images are no longer pinned by Rook: the rook-csi-operator-image-set-configmap configmap switches to empty values, letting ceph-csi-operator use its built-in defaults — a point to check for anyone who overrode those images.

Automated OSD replacement deserves particular attention for teams managing aging disks at scale. Instead of deleting an OSD and recreating it by hand — losing its place in the CRUSH hierarchy and triggering a full rebalancing — the operator annotates the OSD deployment, and Rook drains then destroys it while preserving its position. When a new device arrives on the same node, the slot is already reserved. The known limit: this mechanism covers host-based OSDs, not PVC-backed OSDs.

The RBD QoS feature is worth a note of its own. It rides on VolumeAttributesClass and enforces limits through cgroup v2’s io.max on the krbd mounter, so it requires both the cluster and the node to run cgroup v2 — yet another reason the kernel baseline matters. Teams that have already standardized on cgroup v2 for Kubernetes get per-volume bandwidth caps without switching storage classes.

Ceph Umbrella support matters more than it looks. Rook 1.21 is the first release to treat the next major Ceph line as supported once 21.2.0 lands, which means teams can start planning the jump from their current Ceph release now rather than after it ships. In practice, the migration path is the same as any Rook Ceph upgrade — reconcile the new operator version, then let Rook roll the Ceph daemons in order — but the 5.11 kernel gate is what decides whether that upgrade is trivial or blocked.

What to do before upgrading

The sequence comes down to four checks:

• Check the kernel on every node: uname -r, then compare against 5.11. Any node below it forces either a kernel upgrade or network.connections.requireMsgr2: false.
• Audit Helm scripts that reference the Rook chart by tag and remove the v prefix.
• Check the CSI configmap if you overrode the driver images.
• Read the official upgrade guide before any version change on a production cluster.

The check itself is one command — uname -r on every node — compared against 5.11. But beware of distribution backports: a RHEL 8 kernel labeled 4.18 may carry patches that do not change msgrv2 support; the kernel version, not the distro label, is the criterion. When in doubt, the most reliable test is to mount a scratch RBD volume on the node before rolling the upgrade out fleet-wide.

Verdict

If every node runs a Linux 5.11 kernel or newer, 1.21.0 goes in without special precautions on the msgrv2 front — but still fix your Helm tag references. If part of your fleet is below 5.11, you have two options: upgrade the kernels (the right long-term fix) or disable msgrv2 via requireMsgr2: false to defer the migration — knowing that you are postponing a requirement that will eventually become unavoidable.

References

• GitHub — Rook v1.21.0 release notes (6 October 2026)
• Rook Documentation — Upgrade guide v1.21
• lwcn.dev — Week 42, Oct 12–18, 2026