Manage Milvus with KubeBlocks
The popularity of generative AI (Generative AI) has aroused widespread attention and completely ignited the vector database (Vector Database) market.
Milvus is a highly flexible, reliable, and blazing-fast cloud-native, open-source vector database. It powers embedding similarity search and AI applications and strives to make vector databases accessible to every organization. Milvus can store, index, and manage a billion+ embedding vectors generated by deep neural networks and other machine learning (ML) models.
This tutorial illustrates how to create and manage a Milvus cluster by kbcli
, kubectl
or a YAML file. You can find the YAML examples and guides in the GitHub repository.
Before you start
Install kbcli if you want to manage the Milvus cluster with
kbcli
.To keep things isolated, create a separate namespace called
demo
throughout this tutorial.kubectl create namespace demo
Create a cluster
- kbcli
- kubectl
Steps
Execute the following command to create a Milvus cluster.
kbcli cluster create mycluster --cluster-definition=milvus-2.3.2 -n demo
If you want to customize your cluster specifications, kbcli
provides various options, such as setting cluster version, termination policy, CPU, and memory. You can view these options by adding --help
or -h
flag.
kbcli cluster create milvus --help
kbcli cluster create milvus -h
Check whether the cluster is created successfully.
kbcli cluster list -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo milvus-2.3.2 Delete Running Jul 05,2024 17:35 UTC+0800Check the cluster information.
kbcli cluster describe mycluster -n demo
>
Name: milvus Created Time: Jul 05,2024 17:35 UTC+0800
NAMESPACE CLUSTER-DEFINITION VERSION STATUS TERMINATION-POLICY
demo milvus-2.3.2 Running Delete
Endpoints:
COMPONENT MODE INTERNAL EXTERNAL
milvus ReadWrite milvus-milvus.default.svc.cluster.local:19530 <none>
minio ReadWrite milvus-minio.default.svc.cluster.local:9000 <none>
proxy ReadWrite milvus-proxy.default.svc.cluster.local:19530 <none>
milvus-proxy.default.svc.cluster.local:9091
Topology:
COMPONENT INSTANCE ROLE STATUS AZ NODE CREATED-TIME
etcd milvus-etcd-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
minio milvus-minio-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
milvus milvus-milvus-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
indexnode milvus-indexnode-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
mixcoord milvus-mixcoord-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
querynode milvus-querynode-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
datanode milvus-datanode-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
proxy milvus-proxy-0 <none> Running <none> <none> Jul 05,2024 17:35 UTC+0800
Resources Allocation:
COMPONENT DEDICATED CPU(REQUEST/LIMIT) MEMORY(REQUEST/LIMIT) STORAGE-SIZE STORAGE-CLASS
milvus false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
etcd false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
minio false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
proxy false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
mixcoord false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
datanode false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
indexnode false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
querynode false 1 / 1 1Gi / 1Gi data:20Gi csi-hostpath-sc
Images:
COMPONENT TYPE IMAGE
milvus milvus milvusdb/milvus:v2.3.2
etcd etcd docker.io/milvusdb/etcd:3.5.5-r2
minio minio docker.io/minio/minio:RELEASE.2022-03-17T06-34-49Z
proxy proxy milvusdb/milvus:v2.3.2
mixcoord mixcoord milvusdb/milvus:v2.3.2
datanode datanode milvusdb/milvus:v2.3.2
indexnode indexnode milvusdb/milvus:v2.3.2
querynode querynode milvusdb/milvus:v2.3.2
Show cluster events: kbcli cluster list-events -n demo milvus
KubeBlocks implements a Cluster
CRD to define a cluster. Here is an example of creating a Milvus cluster.
cat <<EOF | kubectl apply -f -
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
affinity:
podAntiAffinity: Preferred
topologyKeys:
- kubernetes.io/hostname
clusterDefinitionRef: milvus-2.3.2
componentSpecs:
- componentDefRef: milvus
disableExporter: true
name: milvus
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: etcd
disableExporter: true
name: etcd
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: minio
disableExporter: true
name: minio
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: proxy
disableExporter: true
name: proxy
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: mixcoord
disableExporter: true
name: mixcoord
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: datanode
disableExporter: true
name: datanode
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: indexnode
disableExporter: true
name: indexnode
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
- componentDefRef: querynode
disableExporter: true
name: querynode
replicas: 1
resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: "1"
memory: 1Gi
serviceAccountName: kb-mycluster
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
resources:
cpu: "0"
memory: "0"
storage:
size: "0"
terminationPolicy: Delete
status: {}
EOF
Field | Definition |
---|---|
spec.clusterDefinitionRef | It specifies the name of the ClusterDefinition for creating a specific type of cluster. |
spec.clusterVersionRef | It is the name of the cluster version CRD that defines the cluster version. |
spec.terminationPolicy | It is the policy of cluster termination. The default value is Delete . Valid values are DoNotTerminate , Delete , WipeOut . For the detailed definition, you can refer to Termination Policy. |
spec.affinity | It defines a set of node affinity scheduling rules for the cluster's Pods. This field helps control the placement of Pods on nodes within the cluster. |
spec.affinity.podAntiAffinity | It specifies the anti-affinity level of Pods within a component. It determines how pods should spread across nodes to improve availability and performance. |
spec.affinity.topologyKeys | It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints. |
spec.tolerations | It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints. |
spec.componentSpecs | It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster. |
spec.componentSpecs.componentDefRef | It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with kubectl get clusterdefinition milvus -o json \| jq '.spec.componentDefs[].name' . |
spec.componentSpecs.name | It specifies the name of the component. |
spec.componentSpecs.disableExporter | It defines whether the monitoring function is enabled. |
spec.componentSpecs.replicas | It specifies the number of replicas of the component. |
spec.componentSpecs.resources | It specifies the resource requirements of the component. |
KubeBlocks operator watches for the Cluster
CRD and creates the cluster and all dependent resources. You can get all the resources created by the cluster with kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo
.
kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo
Run the following command to see the created Milvus cluster object:
kubectl get cluster mycluster -n demo -o yaml
Scale
Currently, KubeBlocks supports vertically scaling a Milvus cluster.
Before you start
Check whether the cluster status is Running
. Otherwise, the following operations may fail.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo milvus-2.3.2 Delete Running Jul 05,2024 17:35 UTC+0800
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster milvus-2.3.2 Delete Running 4m29s
Steps
- kbcli
- OpsRequest
- Edit cluster YAML file
Set the
--cpu
and--memory
values according to your needs and run the following command to perform vertical scaling.kbcli cluster vscale mycluster -n demo --cpu=1 --memory=1Gi --components=milvus
Please wait a few seconds until the scaling process is over.
Validate the vertical scaling operation.
View the OpsRequest progress.
KubeBlocks outputs a command automatically for you to view the OpsRequest progress. The output includes the status of this OpsRequest and Pods. When the status is
Succeed
, this OpsRequest is completed.kbcli cluster describe-ops mycluster-verticalscaling-rpw2l -n demo
Check the cluster status.
kbcli cluster list mycluster -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo Delete Updating Jul 05,2024 17:35 UTC+0800- STATUS=Updating: it means the vertical scaling is in progress.
- STATUS=Running: it means the vertical scaling operation has been applied.
- STATUS=Abnormal: it means the vertical scaling is abnormal. The reason may be that the number of the normal instances is less than that of the total instance or the leader instance is running properly while others are abnormal.
To solve the problem, you can manually check whether this error is caused by insufficient resources. Then if AutoScaling is supported by the Kubernetes cluster, the system recovers when there are enough resources. Otherwise, you can create enough resources and troubleshoot with
kubectl describe
command.
After the OpsRequest status is
Succeed
or the cluster status isRunning
again, check whether the corresponding resources change.kbcli cluster describe mycluster -n demo
Apply an OpsRequest to the specified cluster. Configure the parameters according to your needs.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-vertical-scaling
namespace: demo
spec:
clusterName: mycluster
type: VerticalScaling
verticalScaling:
- componentName: milvus
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "4Gi"
cpu: "2"
EOFCheck the operation status to validate the vertical scaling.
kubectl get ops -n demo
>
NAMESPACE NAME TYPE CLUSTER STATUS PROGRESS AGE
demo ops-vertical-scaling VerticalScaling mycluster Succeed 3/3 6mIf an error occurs, you can troubleshoot with
kubectl describe ops -n demo
command to view the events of this operation.Check whether the corresponding resources change.
kubectl describe cluster mycluster -n demo
Change the configuration of
spec.componentSpecs.resources
in the YAML file.spec.componentSpecs.resources
controls the requirement and limit of resources and changing them triggers a vertical scaling.apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
clusterDefinitionRef: milvus
clusterVersionRef: milvus-2.3.2
componentSpecs:
- name: milvus
componentDefRef: milvus
replicas: 1
resources: # Change the values of resources.
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "4Gi"
cpu: "2"
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
terminationPolicy: DeleteCheck whether the corresponding resources change.
kubectl describe cluster mycluster -n demo
Volume Expansion
Before you start
Check whether the cluster status is Running
. Otherwise, the following operations may fail.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo milvus-2.3.2 Delete Running Jul 05,2024 17:35 UTC+0800
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster milvus-2.3.2 Delete Running 4m29s
Steps
- kbcli
- OpsRequest
- Edit cluster YAML fil
Set the
--storage
value according to your need and run the command to expand the volume.kbcli cluster volume-expand mycluster -n demo --storage=40Gi --components=milvus -t data
The volume expansion may take a few minutes.
Validate the volume expansion operation.
View the OpsRequest progress.
KubeBlocks outputs a command automatically for you to view the details of the OpsRequest progress. The output includes the status of this OpsRequest and PVC. When the status is
Succeed
, this OpsRequest is completed.kbcli cluster describe-ops mycluster-volumeexpansion-5pbd2 -n demo
View the cluster status.
kbcli cluster list mycluster
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo milvus-2.3.2 Delete Running Jul 05,2024 17:35 UTC+0800- STATUS=Updating: it means the volume expansion is in progress.
- STATUS=Running: it means the volume expansion operation has been applied.
After the OpsRequest status is
Succeed
or the cluster status isRunning
again, check whether the corresponding resources change.kbcli cluster describe mycluster -n demo
Change the value of storage according to your need and run the command below to expand the volume of a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-volume-expansion
namespace: demo
spec:
clusterName: mycluster
type: VolumeExpansion
volumeExpansion:
- componentName: milvus
volumeClaimTemplates:
- name: data
storage: "40Gi" # Set the volume storage size.
EOFValidate the volume expansion operation.
kubectl get ops -n demo
>
NAMESPACE NAME TYPE CLUSTER STATUS PROGRESS AGE
demo ops-volume-expansion VolumeExpansion mycluster Succeed 3/3 6mIf an error occurs to the vertical scaling operation, you can troubleshoot with
kubectl describe ops -n demo
command to view the events of this operation.Check whether the corresponding cluster resources change.
kubectl describe cluster mycluster -n demo
Change the value of
spec.componentSpecs.volumeClaimTemplates.spec.resources
in the cluster YAML file.spec.componentSpecs.volumeClaimTemplates.spec.resources
is the storage resource information of the pod and changing this value triggers the volume expansion of a cluster.kubectl edit cluster mycluster -n demo
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
clusterDefinitionRef: milvus
clusterVersionRef: milvus-2.3.2
componentSpecs:
- name: milvus
componentDefRef: milvus
replicas: 2
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 40Gi # Change the volume storage size.
terminationPolicy: DeleteCheck whether the corresponding cluster resources change.
kubectl describe cluster mycluster -n demo
Restart
- kbcli
- OpsRequest
Configure the values of
components
andttlSecondsAfterSucceed
and run the command below to restart a specified cluster.kbcli cluster restart mycluster -n demo --components="milvus" --ttlSecondsAfterSucceed=30
components
describes the component name that needs to be restarted.ttlSecondsAfterSucceed
describes the time to live of an OpsRequest job after the restarting succeeds.
Validate the restarting.
Run the command below to check the cluster status to check the restarting status.
kbcli cluster list mycluster -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
milvus demo milvus-2.3.2 Delete Running Jul 05,2024 18:35 UTC+0800- STATUS=Updating: it means the cluster restart is in progress.
- STATUS=Running: it means the cluster has been restarted.
Restart a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-restart
namespace: demo
spec:
clusterName: mycluster
type: Restart
restart:
- componentName: milvus
EOFCheck the pod and operation status to validate the restarting.
kubectl get pod -n demo
kubectl get ops ops-restart -n demoDuring the restarting process, there are two status types for pods.
- STATUS=Terminating: it means the cluster restart is in progress.
- STATUS=Running: it means the cluster has been restarted.
Stop/Start a cluster
You can stop/start a cluster to save computing resources. When a cluster is stopped, the computing resources of this cluster are released, which means the pods of Kubernetes are released, but the storage resources are reserved. You can start this cluster again by snapshots if you want to restore the cluster resources.
Stop a cluster
Configure the name of your cluster and run the command below to stop this cluster.
- kbcli
- OpsRequest
- Edit Cluster YAML File
kbcli cluster stop mycluster -n demo
Apply an OpsRequest to stop a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-stop
namespace: demo
spec:
clusterName: mycluster
type: Stop
EOFConfigure replicas as 0 to delete pods.
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
clusterDefinitionRef: milvus
clusterVersionRef: milvus-2.3.2
terminationPolicy: Delete
componentSpecs:
- name: milvus
componentDefRef: milvus
disableExporter: true
replicas: 0 # Change this value
......Check the status of the cluster to see whether it is stopped.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
kubectl get cluster mycluster -n demo
Start a cluster
Configure the name of your cluster and run the command below to start this cluster.
- kbcli
- OpsRequest
- Edit Cluster YAML File
kbcli cluster start mycluster -n demo
Apply an OpsRequest to start a cluster.
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: ops-start
namespace: demo
spec:
clusterName: mycluster
type: Start
EOFChange replicas back to the original amount to start this cluster again.
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: mycluster
namespace: demo
spec:
clusterDefinitionRef: milvus
clusterVersionRef: milvus-2.3.2
terminationPolicy: Delete
componentSpecs:
- name: milvus
componentDefRef: milvus
disableExporter: true
replicas: 1 # Change this value
......Check the status of the cluster to see whether it is running again.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
kubectl get cluster mycluster -n demo
Delete a cluster
Termination policy
The termination policy determines how a cluster is deleted.
terminationPolicy | Deleting Operation |
---|---|
DoNotTerminate | DoNotTerminate blocks delete operation. |
Halt | Halt deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations. Halt policy is deprecated in v0.9.1 and will have same meaning as DoNotTerminate. |
Delete | Delete extends the Halt policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data. |
WipeOut | WipeOut deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, especially in non-production environments, to avoid irreversible data loss. |
To check the termination policy, execute the following command.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
>
NAME NAMESPACE CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS CREATED-TIME
mycluster demo milvus-2.3.2 Delete Running Jul 05,2024 17:35 UTC+0800
kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster milvus-2.3.2 Delete Running 14m
Steps
Run the command below to delete a specified cluster.
- kbcli
- kubectl
kbcli cluster delete mycluster -n demo
If you want to delete a cluster and its all related resources, you can modify the termination policy to WipeOut
, then delete the cluster.
kubectl patch -n demo cluster mycluster -p '{"spec":{"terminationPolicy":"WipeOut"}}' --type="merge"
kubectl delete -n demo cluster mycluster