New to KubeDB? Please start here.
Milvus Storage Autoscaling
This guide will give an overview on how the KubeDB Autoscaler operator autoscales the persistent storage of a Milvus database.
Before You Begin
- You should be familiar with the following
KubeDBconcepts:
How Storage Autoscaling Works
A MilvusAutoscaler of type storage watches PVC usage and, when a volume crosses the configured usage threshold, creates a VolumeExpansion MilvusOpsRequest to grow the volume.
spec.storage is keyed by the workload that carries persistent storage:
- Standalone:
node. - Distributed:
streamingnode— among the distributed roles, onlystreamingnodehas a persistent volume, so it is the sole storage-autoscaling target.
spec:
storage:
streamingnode: # or 'node' for standalone
trigger: "On"
usageThreshold: 34
expansionMode: "Online"
scalingRules:
- appliesUpto: "100Ti"
threshold: "50%"
trigger—On/Off.usageThreshold— percentage of disk usage that triggers expansion.expansionMode—OnlineorOffline(passed through to the generatedVolumeExpansionops request).scalingRules— how much to grow, optionally varying by current size.
The flow is:
- A user creates a
MilvusAutoscalerwithspec.storage. - The autoscaler reads PVC usage from the
custom.metrics.k8s.ioAPI backed by the KubeDB storage-metrics apiserver. - When usage exceeds
usageThreshold, the autoscaler creates aVolumeExpansionMilvusOpsRequestsized perscalingRules. - The Ops-manager operator performs the volume expansion as usual.
Prerequisites: The KubeDB storage metrics server must be enabled and serving the
custom.metrics.k8s.ioAPI, and the PVC’sStorageClassmust haveallowVolumeExpansion: true.
In the next doc, we will see a step-by-step guide on storage autoscaling of a Milvus database.