# kubectl kadalu storage-add storage-pool1 --type=Disperse \ --data 2 --redundancy 1 \ --device kube-nodename1:/dev/vdc \ --device kube-nodename2:/dev/vdc \ --device kube-nodename3:/dev/vdc
Announcing Kadalu Storage 0.8.3
The Kadalu team is happy to announce a new version of Kadalu Storage, 0.8.3.
Disperse Storage Type
If you already used GlusterFS Volume then you will be familiar with Disperse Volume type. With this release, we are happy to announce that we added support for Disperse Storage in Kadalu. Disperse type uses erasure codes. The data can be recoverable if the number of bricks equivalent to the number of redundancy bricks. Redundancy is distributed equally in all the bricks, data is recoverable/readable even if a data brick is down but Quoram is available(
up_bricks == data_bricks_count). Read more about Disperse Volume type in GlusterFS documentation and usage instructions on the Kadalu website.
Distributed Volume support for External Volumes
Early releases of Kadalu used xfs quota in the Storage backend for each PVs created. With that supporting Distribute Storage was a challenge. With the version 0.8.0, the Simple Quota feature was introduced for the Storage volumes managed by Kadalu Operator. But the Simple Quota feature is not available with GlusterFS releases yet! So Distribute was not supported for the external GlusterFS Volumes.
With this release, Distribute Volume support is added by using the GlusterFS Quota feature itself. Thanks to Yugo Yamauchi from Hitachi for this wonderful enhancement. Read more details about this enhancement here.
Archiving the PVs on delete
Introduced the option to set a reclaim policy for all the PVCs at the Storage level. Set this option while adding the new Storages. By default, the PV reclaim policy is set to
delete. If it is set to
archive then all PVs will be archived instead of delete.
With kubectl extension,
# kubectl kadalu storage-add storage-pool-1 \ --device kube1.example.com:/dev/vdc \ --pv-reclaim-policy=archive
Arm64 / Arm7 support
Arm support is getting better with the releases. Arm support is first introduced in 7.6, many issues are fixed. In this release, this got even better. Fixed a couple of issues related to GlusterFS build and kubectl binary compatibility issues within the containers.
Migrating Gluster Volumes to Kadalu Storage
If someone plan to migrate the existing Gluster Volume to Kubernetes, it is very easy now. Join all your Storage nodes to Kubernetes Cluster and add the bricks of the existing Gluster Volume as Kadalu Storage units in the same order.
For example, if the Gluster Volume is
gvol1 with the following bricks
Volume ID: 0a5836ff-e3c0-4760-a54c-2baafa80635d Bricks: server1.example.com:/bricks/gvol1/brick1/brick server2.example.com:/bricks/gvol1/brick2/brick server3.example.com:/bricks/gvol1/brick3/brick
Get the node names by running the
kubectl get nodes command if the Storage node names are changed. Once the new node names are collected, prepare the Kadalu storage-add command as follows.
# kubectl kadalu storage-add gvol1 \ --volume-id 0a5836ff-e3c0-4760-a54c-2baafa80635d \ --path kube-server1.example.com:/bricks/gvol1/brick1/brick \ --path kube-server2.example.com:/bricks/gvol1/brick2/brick \ --path kube-server3.example.com:/bricks/gvol1/brick3/brick
Note the additional argument(
--volume-id) to the Storage add command. This Volume ID should be the same as the Volume ID when it was a Gluster Volume.
This enhancement also helps to re-setup the GlusterFS or Kadalu Storage when disks need to be migrated.
External GlusterFS Volume support enhancements
Support for external GlusterFS Volume just got better with this release. Storage configuration for external Volume is looking similar to in-cluster Volumes configurations/YAML. The following two formats are available with External Volumes.
native: Multiple PVs from the external Volume
non-native: Single PV from the external Volume
Decommissioning Storage units
Introduced the option to decommission a Storage unit so that Storage shrink, replacing the disks and other maintenance activities are possible.
Replica 1 to Replica 2 or 3 Migration support
The existing Replica 1 Storage type can be migrated to Replica 2/3 and Self-heal will sync all the files to the new bricks.
See the detailed release notes for additional information.
Contributors to this release (8)
Join the Kadalu team as we plan, design and develop new features. We are available on our Slack instance, https://kadalu.slack.com.