Rook v1.9 Storage Enhancements
The Rook v1.9 release is out! v1.9 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.8 release in December:
- 9.3K to 9.8K Github stars
- 250M to 260M Container downloads
- 4.8K to 5.1K Slack members
- 6.2K to 6.4K Twitter followers
We have a lot of new features for the Ceph storage provider that we hope you’ll be excited about with the v1.9 release!
Quincy Support
Ceph Quincy (v17) is the next major version of Ceph that is also released this week. Keeping up with the latest updates to the data plane is critical to Rook so you can always deploy the version of the data plane that you desire. To learn more about all the new features in the Quincy release, see the release notes.
In addition to Quincy, Rook v1.9 continues to support Octopus (v15) and Pacific (v16). In Rook v1.10 we anticipate removing support for Octopus to correspond with its end-of-life from the Ceph team. If you are still running Octopus, we encourage you to update to the latest version of Pacific in the near future.
Ceph-CSI v3.6
The v3.6 release of the Ceph-CSI driver is now the version deployed by default with Rook. The driver has a number of updates, including:
- NFS Provisioner: Allows dynamic provisioning of Ceph NFS volumes (more on NFS in the next section)
- Fuse mount recovery: Detection of corrupt Ceph fuse mounts will be detected and remounted automatically
- AWS KMS encryption: CSI can be configured to use Amazon STS
- Support for Ceph Quincy
NFS CSI Driver
For many releases, Rook has had the ability to create NFS servers backed by Ceph storage, but it wasn’t quite as polished as we would have liked. Creating NFS exports was still a manual process that required users to use the Ceph CLI or Dashboard to create usable storage, and it would require more work to attach those exports to Kubernetes Pods.
For v1.9, we decided we wanted a Kubernetes-native way to create NFS exports. We worked with the Ceph CSI team to develop a CSI provisioner that can dynamically provision exports that are backed by a CephFilesystem.
We’re happy to say that we now have alpha-level support for creating NFS exports via Persistent Volume Claims, and experimental integration with the Ceph CSI’s NFS export provisioner. We look forward to your feedback on this new feature!
Updated Prometheus Alerts
The Prometheus alerts for Ceph have been an area of focus for upstream Ceph, with many alerts added and updated. All of these improvements to the alerts have been included with Rook v1.9 and can be optionally installed with the Cluster helm chart by setting the monitoring.createPrometheusRules setting. Or if you are not installing with helm, instructions are included in the monitoring documentation to enable the alerts.
RADOS Namespace CRD
A RADOS namespace is a division of a pool into separate logical namespaces. They allow for multi-tenancy by providing isolation between tenants without increasing the number of pools. The new RADOS Namespace CRD provides the capability for Rook to automate creating those namespaces for you with a standard CRD.
Network Encryption and Compression
Ceph has recently added the ability to enable encryption and compression on the wire. These features are not enabled by default, so Rook has exposed settings in the CephCluster CR to enable them in the network connection settings.
Encryption on the wire can be enabled with Ceph Pacific. However, due to changes in the Ceph kernel drivers, the 5.11 kernel is required for the latest nbd and cephFS drivers. Alternatively for testing only, you can set the rbd-nbdor fuse mounters in the storage class, but the user-mode drivers are not supported as they suffer from losing mounts when the csi driver mounter pod is restarted.
Compression on the wire requires Ceph Quincy in addition to a newer kernel as mentioned for encryption.
Admission Controller
For many releases, Rook has provided an admission controller for additional validation during resource creation, although enabling the admission controller has required several extra steps. With v1.9, now there is only one pre-requisite for enabling the admission controller, which is to install the cert-manager in your cluster. If Rook sees the cert-manager available in your cluster, the admission controller will be automatically enabled to provide an extra level of validation. This will increase your assurance that you have created cluster resources with a valid configuration.
Default Helm Resources
To most effectively deploy in production environments, Kubernetes best-practices recommend that resource requests and limits should be set. While we have not previously set the resources by default due to the varying requirements between different workloads, we have settled on some defaults in the Rook Helm charts that we expect will be effective for most clusters. If you find the defaults are too generous or restrictive for your workload, they can be adjusted in values.yaml as with any other helm settings. Please let us know if you have suggestions on different defaults!
Multus networking
A few releases ago we announced initial support for Multus CNI (Container Network Interface), allowing attaching multiple network interfaces to pods in Kubernetes. After significant effort to stabilize it, we can now say with confidence that we have achieved the maturity and level of robustness necessary to run with Multus in production.
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.9 milestone!
