Rook 1.21 impose le protocole msgrv2 de Ceph par défaut
Le 6 octobre 2026, Rook 1.21.0 rend le protocole msgrv2 obligatoire par défaut pour Ceph, ce qui exige un noyau Linux 5.11 ou plus récent. Avant de mettre à niveau, vérifiez la version du noyau de vos nœuds, sinon désactivez explicitement msgrv2 dans le CephCluster.
6 octobre 2026. La version 1.21.0 de Rook est publiée par travisn, l’un des mainteneurs, avec une rupture de compatibilité majeure : le protocole msgrv2 de Ceph devient obligatoire par défaut. 6 octobre 2026. Les tags des charts Helm OCI abandonnent le préfixe v (1.21.0 au lieu de v1.21.0). 6 octobre 2026. Le support de Ceph Umbrella (v21) est annoncé, en attendant la sortie de Ceph 21.2.0. Pourquoi c’est important : msgrv2 exige un noyau Linux 5.11 ou plus récent — un cluster qui tourne sur des nœuds plus anciens peut se retrouver en échec après l’upgrade.
Une rupture de compatibilité au cœur du plan de données
Rook est l’opérateur Kubernetes qui orchestre Ceph : il déploie les moniteurs, les OSD et les services, et réconcilie en continu l’état du cluster avec les ressources CephCluster. Une bonne partie de sa valeur tient à ce qu’il masque la complexité de Ceph — jusqu’au jour où une rupture de compatibilité remonte à la surface.
msgrv2 est le protocole de messagerie moderne de Ceph, celui qui chiffre et authentifie les échanges entre les démons du cluster. Il est le défaut de Ceph depuis plusieurs versions, mais Rook laissait encore la porte ouverte à l’ancien protocole msgrv1. La 1.21.0 referme cette porte : msgrv2 est requis par défaut, et cette exigence dépend d’un prérequis système précis — le noyau Linux 5.11, introduit en février 2021.
Pour mémoire, msgrv2 est arrivé avec Ceph Nautilus (v14, 2019) et s’est imposé comme le protocole par défaut des nouveaux clusters à partir d’Octopus (v15). Sa valeur tient à deux choses : le chiffrement des échanges entre démons et une authentification renforcée via l’entité cephx, là où l’ancien msgrv1 laissait circuler une partie du trafic en clair. Abandonner msgrv1, c’est donc fermer une surface d’exposition réseau sur le plan de données — mais au prix d’une exigence de noyau que tous les parcs n’ont pas encore.
Pourquoi le noyau 5.11 est le point de bascule
La contrainte ne vient pas de Rook lui-même mais de la manière dont le client Ceph dans le noyau (krbd, le pilote RBD) négocie la connexion. msgrv2 repose sur des fonctionnalités du noyau qui n’existent qu’à partir de la 5.11. En dessous, un nœud ne peut pas établir la connexion chiffrée qu’exige le protocole — et les volumes RBD montés sur ces nœuds échouent.
C’est précisément le genre de détail qui se paie au moment le plus inopportun. Une distribution Ubuntu 20.04 embarque un noyau 5.4, RHEL 8 un noyau 4.18, CentOS 7 un 3.10 : autant de socles encore présents dans les parcs qui n’ont pas été rafraîchis. Un opérateur qui met à niveau Rook vers 1.21 sur ces nœuds sans vérifier le noyau peut transformer un simple changement de version en panne de stockage.
La parade est documentée dans les notes de version : pour rester sur l’ancien protocole, il faut désactiver explicitement msgrv2 via le champ network.connections.requireMsgr2: false dans la ressource CephCluster — ou, si l’on passe par le chart Helm, sous la clé cephClusterSpec des valeurs.
# CephCluster : conserver msgrv1 sur des nœuds dont le noyau est < 5.11
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
name: rook-ceph
namespace: rook-ceph
spec:
network:
connections:
requireMsgr2: falseLe piège est que cette désactivation n’est pas un état « neutre » : elle revient à conserver un protocole que Ceph lui-même considère comme hérité. Sur un parc mixte, où certains nœuds sont à jour et d’autres non, la vérification doit se faire nœud par nœud — un seul nœud sous 5.11 suffit à faire échouer les volumes RBD qui y sont montés, même si le reste du cluster est sain.
Les deux autres ruptures de compatibilité
La 1.21.0 en compte deux autres, moins dangereuses mais à connaître avant de mettre à jour :
- Les tags des charts Helm OCI perdent le préfixe
v: un script ou un pipeline qui référence le chart par son tag (v1.21.0) doit passer à1.21.0. Les outils de mise à jour automatique qui parsent les versions sont les premiers concernés. - Les nouvelles installations NFS doivent définir elles-mêmes un
CephBlockPoolpour le pool.nfs: Rook ne crée plus ce pool automatiquement. Les clusters déjà en place ne sont pas impactés, car le pool existe déjà.
Ce que la 1.21 apporte en contrepartie
La version ne se résume pas à des ruptures. Le gros morceau est l’annonce du support de Ceph Umbrella (v21), la prochaine version majeure de Ceph, qui deviendra utilisable dès la sortie de 21.2.0. À cela s’ajoutent trois nouveautés concrètes pour l’exploitation :
- QoS RBD : la qualité de service sur les volumes se configure via
VolumeAttributesClass, avec une applicationio.maxportée par cgroup v2 et le mounterkrbd. - Remplacement automatisé des OSD : on peut annoter un déploiement OSD pour le marquer à remplacer ; Rook le draine et le détruit en préservant sa position CRUSH, pour la réutiliser quand un nouveau disque arrive sur le nœud.
- Certificats TLS du dashboard : ils peuvent désormais venir d’un
SecretKubernetes du même namespace viaspec.dashboard.sslCertificateRef.
Enfin, les images des conteneurs du pilote CSI ne sont plus figées par Rook : la configmap rook-csi-operator-image-set-configmap passe à des valeurs vides, laissant ceph-csi-operator utiliser ses défauts intégrés — un point à vérifier pour ceux qui surchargeaient ces images.
Le remplacement automatisé des OSD mérite une attention particulière pour les équipes qui gèrent des disques vieillissants à grande échelle. Plutôt que de supprimer un OSD et de le recréer à la main — en perdant sa place dans la hiérarchie CRUSH et en déclenchant un rebalancing complet — l’opérateur annote le déploiement OSD, et Rook se charge de le drainer puis de le détruire en préservant sa position. Quand un nouveau disque arrive sur le même nœud, la place est déjà réservée. La limite à connaître : ce mécanisme couvre les OSD host-based, pas les OSD adossés à des PVC.
Ce qu’il faut faire avant l’upgrade
La marche à suivre tient en quatre vérifications :
- Vérifier le noyau de chaque nœud :
uname -r, puis comparer à la 5.11. Tout nœud en dessous impose soit une mise à niveau du noyau, soitnetwork.connections.requireMsgr2: false. - Auditer les scripts Helm qui référencent le chart Rook par tag et retirer le préfixe
v. - Vérifier la configmap CSI si vous surchargiez les images des pilotes.
- Lire le guide d’upgrade officiel avant toute montée de version sur un cluster en production.
La vérification elle-même tient en une commande : uname -r sur chaque nœud, puis une comparaison à la 5.11. Mais méfiez-vous des backports de distribution : un noyau affiché 4.18 sur RHEL 8 peut embarquer des correctifs qui ne changent rien au support de msgrv2 — la version du noyau reste le critère, pas l’étiquette de la distribution. En cas de doute, le test le plus fiable reste de monter un volume RBD de test sur le nœud avant de généraliser l’upgrade.
Verdict
Si tous vos nœuds tournent sous un noyau Linux 5.11 ou plus récent, la 1.21.0 passe sans précaution particulière côté msgrv2 — mais corrigez quand même vos références de tags Helm. Si une partie de votre parc est sous 5.11, deux options s’offrent à vous : mettre à niveau les noyaux (la bonne solution à terme) ou désactiver msgrv2 via requireMsgr2: false pour décaler la migration — en sachant que vous repoussez alors une exigence qui finira par devenir incontournable.