Kubernetes Rook EdgeFS 1.1 Released
Enable Edge/IoT and Edge-Native decentralized computing use cases with new Kubernetes Rook EdgeFS stable release.
Through my career, I’ve been a member of many collaboration groups and open source communities and I have to admit, Rook community is the most open, fast-evolving, inclusive and effective one!
Rook community is “inclusive”. It is no longer just about Ceph. The other Kubernetes Rook operators are thriving and communities are growing rapidly!
Thanks to inclusivity, Rook EdgeFS community grew 230% in the past 6 months, with close to 1M of docker pulls of EdgeFS image!
Rook EdgeFS CRDs graduated to V1
This is a significant milestone after almost one year of development. We went from early users who were enthusiastically using Alpha1v1 to larger users with Petabyte scale deployments who are now will be upgrading from Beta1v1. Upgrade path from Beta1v1 is provided.
With the introduction of stable CRD V1 API, Rook EdgeFS operator now stabilized and any on-going changes will include business logic to ensure smooth upgrade path.
The work was sponsored by Google Summer of Code (GSoC) and @giovanism has done an amazing job of getting generic support for Multi-Homed networking into Rook Framework integrated! At the moment Rook EdgeFS operator is the only one that implements this functionality.
Key advantages of Multi-Homed networking is enhanced backend network security and overall cluster performance.
Rook operators now can be configured with flexible (initial integration includes EdgeFS support for Intel Multus) selection of multi-homed networks.
I would emphasize networking isolation and security benefit as most significant. Isolation additionally improves reliability, i.e. temporary loss of pod network will not cause storage backend operations interruptions.
I’ve presented the below comparison results while at KubeCon earlier this year in Shanghai, and you can see that both latency and bandwidth improvements are significant:
You can learn more about Multi-Homed network in this youtube video.
Rolling upgrades support
This is a must-have feature for production deployments. I’m happy to announce that this feature is now in and any following releases will support seamless rolling upgrades with minimal impact on data services availability.
Dynamic add and remove of EdgeFS target pods
EdgeFS by itself supports this functionality natively. (Running EdgeFS core in production). However, proper Kubernetes integration takes time. I’m happy to see it is now landed into 1.1 release and we’ve got some successful reports of users using it!
With this functionality, users can easily grow cluster configuration without the need for a full-services restart. There are certain limits on how configuration can be added or removed.
See example on how to add a node.
Support for a device spec with full ID path
In Linux, one cannot and must not use kernel representation of a block device, e.g. /dev/sda, /dev/sdb. The naming is not persistent across server reboots! Support for full ID path specification now in 1.1 and it is possible to address devices by persistent IDs, e.g. /dev/disk/by-id/NAME
EdgeFS strengths are in the ability to seamlessly connect hundreds of distributed locations with a blockchain-grade crypto strong security guarantees and global inline WAN/LAN data deduplication.
EdgeFS primary use case is to get edge-born data processed in decentralized locations without the pain of losing track of copies and consistency, while significantly cut cloud bills!
Kubernetes community now has a stable, high performant, decentralized data layer to connect multiple clouds and edge locations as one geo-distributed consistent namespace.
Rook EdgeFS Kubernetes community welcoming new users and looking forward to further improve usability, reliability, availability, and ease of use of Kubernetes native storage solution.
Give it a try today! Star our GitHub repository and let us know what you think?