The Rook v1.15 release is out! v1.15 is another feature-filled release to improve storage for Kubernetes. Thanks again to the community for all the great support in this journey to deploy storage in production.
The statistics continue to show Rook community growth since the v1.14 release in April:
- 11.9K to 12.2K Github stars
- 317M to 333M Container downloads
- 6.6K to 6.8K Slack members
- 7.5K to 7.7K X followers
We have a lot of new features for the Ceph storage provider that we hope you’ll be excited about with the v1.15 release!
Versions
Ceph Squid Support
v1.14 was planning on supporting the upcoming Ceph Squid (v19) release. Now the Squid release is in final testing, so support for Squid will come instead with v1.15. Same level of support delivered, just delayed a bit while Squid has been preparing its engines for takeoff.
Kubernetes v1.26
Kubernetes v1.26 is now the minimum version supported by Rook, which means we run CI tests against v1.26 and newer. If you still require running an older K8s version we haven’t done anything to prevent running Rook, we simply just do not have test validation on older versions.
CSI
Ceph CSI v3.12
The v3.12 release of the Ceph-CSI driver is now the version deployed by default with Rook. The driver has a number of important updates to add more storage features and fixes available to clients. The primary features to mention are:
- RBD: Added support for a flattenMode option for replication, implemented encryption key rotation, and added backend support for VolumeGroup operations.
- Log rotation: Similar to the rotation of the Ceph logs, the CSI logs will also be rotated if the logCollector settings are enabled in the CephCluster CR.
- CSI sidecar images: The sidecars are updated to the latest versions for the resizer, provisioner, attacher, snapshotter, and driver registrar.
Ceph CSI Operator
Configuration of the Ceph CSI driver has always been driven by Rook automatically. The CSI-related settings are soon moving to CRDs to be managed by a new Ceph CSI operator. This will allow configuration of settings in CRs, rather than applying settings in env vars or a configmap.
This feature is experimental in v1.15. Please try out the CSI operator in a test cluster and send us your feedback! There are just two steps to enable the CSI operator:
- Create csi-operator.yaml
- Set ROOK_USE_CSI_OPERATOR: true in operator.yaml
Once enabled, Rook will convert the settings previously defined in the operator configmap or env vars into the new CRs managed by the CSI operator.
In the next Rook release (v1.16), we plan to enable and require the CSI operator for all deployments. The upgrade is expected to have no noticeable impact on your cluster since Rook will automatically configure the CSI operator with your existing CSI settings.
CRUSH Updates
There are two new properties that allow properties in the CRUSH map to be updated automatically, instead of requiring manual intervention:
- OSD Device Class: Update the device class to which an OSD is assigned. This is not enabled by default since we want you to have control of when the data might be impacted as PGs may be redistributed in the cluster. This setting is enabled in the CephCluster CR with: spec.storage.allowDeviceClassUpdate: true
- OSD Weight: After expanding the size of an OSD, the OSD weight should be increased in the CRUSH map. Resizing has long been supported by Rook, but the weight has not previously been automatically updated. This setting is enabled in the CephCluster CR with: spec.storage.allowOsdCrushWeightUpdate: true
These settings are disabled by default in upgraded clusters to prevent unexpected changes for users who may have been configuring these settings manually.
Object Store with Keystone and Swift
Ceph RGW can integrate with the Swift API and Keystone via the CephObjectStore CRD. This allows native integration of the Rook object store into OpenStack clouds. Once Rook is configured with the Keystone access and related settings, Rook will configure the Ceph object store automatically. To try out this feature, see the topic on Object Store with Keystone and Swift.
This feature is in experimental mode. We look forward to your feedback to confirm if there are any issues before declaring it stable!
Holder Pod Deprecation
Rook is beginning the process of deprecating network holder pods. The holder pod was previously required for scenarios where host networking was disabled in the CSI driver, including Multus. After reviewing user feedback and available options, we have determined the preferred option for the CSI driver is to use host networking instead of holder pods. Clusters that have enabled the holder pods with Multus or similar configuration will need to follow the migration guide to disable the holder pods soon. We understand this can be a significant configuration change, so the holder pods are still supported in v1.15 to give you time to transition. See the documentation for details on the migration. The holders will be fully removed in the next release, so the migration must be complete before you upgrade to v1.16 in the future.
What’s Next?
As we continue the journey to develop reliable storage operators for Kubernetes, we look forward to your ongoing feedback. Only with the community is it possible to continue this fantastic momentum.
There are many different ways to get involved in the Rook project, whether as a user or developer. Please join us in helping the project continue to grow on its way beyond the v1.15 milestone!
<hr /><p>Rook v1.15 Storage Enhancements was originally published in Rook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>