KubeBlocks
BlogsKubeBlocks Cloud
⌘K
​
Manage Milvus with KubeBlocks
  1. Before you start
  2. Create a cluster
  3. Scale
    1. Before you start
    2. Steps
  4. Volume Expansion
    1. Before you start
    2. Steps
  5. Restart
  6. Stop/Start a cluster
    1. Stop a cluster
    2. Start a cluster
  7. Delete a cluster
    1. Termination policy
    2. Steps

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.

  • Install KubeBlocks.

  • Install and enable the milvus Addon.

  • To keep things isolated, create a separate namespace called demo throughout this tutorial.

    kubectl create namespace demo

Create a cluster

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: terminationPolicy: Delete affinity: podAntiAffinity: Preferred topologyKeys: - kubernetes.io/hostname tenancy: SharedNode tolerations: - key: kb-data operator: Equal value: 'true' effect: NoSchedule componentSpecs: - name: proxy componentDef: milvus-proxy-0.9.0 replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi serviceRefs: - cluster: etcdm-cluster name: milvus-meta-storage - cluster: pulsarm-cluster name: milvus-log-storage - name: milvus-object-storage namespace: default clusterServiceSelector: cluster: miniom-cluster service: component: minio service: headless port: http credential: component: minio name: admin - name: mixcoord componentDef: milvus-mixcoord-0.9.0 replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi serviceRefs: - cluster: etcdm-cluster name: milvus-meta-storage - cluster: pulsarm-cluster name: milvus-log-storage - name: milvus-object-storage namespace: default clusterServiceSelector: cluster: miniom-cluster service: component: minio service: headless port: http credential: component: minio name: admin - name: datanode componentDef: milvus-datanode-0.9.0 replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi serviceRefs: - cluster: etcdm-cluster name: milvus-meta-storage - cluster: pulsarm-cluster name: milvus-log-storage - name: milvus-object-storage namespace: default clusterServiceSelector: cluster: miniom-cluster service: component: minio service: headless port: http credential: component: minio name: admin - name: indexnode componentDef: milvus-indexnode-0.9.0 replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi serviceRefs: - cluster: etcdm-cluster name: milvus-meta-storage - cluster: pulsarm-cluster name: milvus-log-storage - name: milvus-object-storage namespace: default clusterServiceSelector: cluster: miniom-cluster service: component: minio service: headless port: http credential: component: minio name: admin - name: querynode componentDef: milvus-querynode-0.9.0 replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi serviceRefs: - cluster: etcdm-cluster name: milvus-meta-storage - cluster: pulsarm-cluster name: milvus-log-storage - name: milvus-object-storage namespace: default clusterServiceSelector: cluster: miniom-cluster service: component: minio service: headless port: http credential: component: minio name: admin --- apiVersion: apps.kubeblocks.io/v1alpha1 kind: Cluster metadata: name: etcdm-cluster namespace: demo spec: clusterDefinitionRef: etcd clusterVersionRef: etcd-v3.5.6 terminationPolicy: WipeOut affinity: podAntiAffinity: Preferred topologyKeys: - kubernetes.io/hostname tenancy: SharedNode tolerations: - key: kb-data operator: Equal value: 'true' effect: NoSchedule componentSpecs: - name: etcd componentDefRef: etcd replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi volumeClaimTemplates: - name: data spec: storageClassName: null accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- apiVersion: apps.kubeblocks.io/v1alpha1 kind: Cluster metadata: name: pulsarm-cluster namespace: demo annotations: "kubeblocks.io/extra-env": '{"KB_PULSAR_BROKER_NODEPORT": "false"}' spec: clusterDefinitionRef: pulsar clusterVersionRef: pulsar-3.0.2 terminationPolicy: WipeOut affinity: podAntiAffinity: Preferred topologyKeys: - kubernetes.io/hostname tenancy: SharedNode tolerations: - key: kb-data operator: Equal value: 'true' effect: NoSchedule componentSpecs: - name: pulsar-broker componentDefRef: pulsar-broker disableExporter: true replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi - name: bookies componentDefRef: bookies disableExporter: true replicas: 3 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi volumeClaimTemplates: - name: journal spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi - name: ledgers spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi - name: zookeeper componentDefRef: zookeeper disableExporter: true replicas: 3 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- apiVersion: apps.kubeblocks.io/v1alpha1 kind: Cluster metadata: name: miniom-cluster namespace: demo spec: terminationPolicy: WipeOut componentSpecs: - name: minio componentDef: milvus-minio-0.9.0 replicas: 1 resources: limits: cpu: '0.5' memory: 0.5Gi requests: cpu: '0.5' memory: 0.5Gi volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF
FieldDefinition
spec.terminationPolicyIt 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.affinityIt 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.podAntiAffinityIt 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.topologyKeysIt represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.
spec.tolerationsIt is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.
spec.componentSpecsIt is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.
spec.componentSpecs.componentDefRefIt 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.nameIt specifies the name of the component.
spec.componentSpecs.disableExporterIt defines whether the monitoring function is enabled.
spec.componentSpecs.replicasIt specifies the number of replicas of the component.
spec.componentSpecs.resourcesIt 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

Steps

  1. Execute the following command to create a Milvus cluster.

    kbcli cluster create mycluster --cluster-definition=milvus-2.3.2 -n demo
NOTE

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
  1. 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+0800
  2. Check 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

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.

kubectl get cluster mycluster -n demo > NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE mycluster milvus-2.3.2 Delete Running 4m29s
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

Steps

  1. 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" EOF
  2. Check 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 6m

    If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

  3. Check whether the corresponding resources change.

    kubectl describe cluster mycluster -n demo
  1. 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: Delete
  2. Check whether the corresponding resources change.

    kubectl describe cluster mycluster -n demo
  1. 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.

  2. 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.

  3. After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.

    kbcli cluster describe mycluster -n demo

Volume Expansion

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kubectl get cluster mycluster -n demo > NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE mycluster milvus-2.3.2 Delete Running 4m29s
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

Steps

  1. 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. EOF
  2. Validate 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 6m

    If 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.

  3. Check whether the corresponding cluster resources change.

    kubectl describe cluster mycluster -n demo
  1. 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

    Edit the value of spec.componentSpecs.volumeClaimTemplates.spec.resources.

    ... 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 ...
  2. Check whether the corresponding cluster resources change.

    kubectl describe cluster mycluster -n demo
  1. 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.

  2. 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.
  3. After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.

    kbcli cluster describe mycluster -n demo

Restart

  1. 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 EOF
  2. Check the pod and operation status to validate the restarting.

    kubectl get pod -n demo kubectl get ops ops-restart -n demo

    During 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.
  1. Configure the values of components and ttlSecondsAfterSucceed 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.
  2. 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.

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 to restore it to the state it was in before it was stopped.

Stop a cluster

  1. Configure the name of your cluster and run the command below to stop this cluster.

    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 EOF
    kubectl edit cluster mycluster -n demo

    Configure replicas as 0 to delete pods.

    ... spec: clusterDefinitionRef: milvus clusterVersionRef: milvus-2.3.2 terminationPolicy: Delete componentSpecs: - name: milvus componentDefRef: milvus disableExporter: true replicas: 0 # Change this value ...
    kbcli cluster stop mycluster -n demo
  2. Check the status of the cluster to see whether it is stopped.

    kubectl get cluster mycluster -n demo
    kbcli cluster list mycluster -n demo

Start a cluster

  1. Configure the name of your cluster and run the command below to start this cluster.

    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 EOF
    kubectl edit cluster mycluster -n demo

    Change replicas back to the original amount to start this cluster again.

    ... spec: clusterDefinitionRef: milvus clusterVersionRef: milvus-2.3.2 terminationPolicy: Delete componentSpecs: - name: milvus componentDefRef: milvus disableExporter: true replicas: 1 # Change this value ...
    kbcli cluster start mycluster -n demo
  2. Check the status of the cluster to see whether it is running again.

    kubectl get cluster mycluster -n demo
    kbcli cluster list mycluster -n demo

Delete a cluster

Termination policy

NOTE

The termination policy determines how a cluster is deleted.

terminationPolicyDeleting Operation
DoNotTerminateDoNotTerminate blocks delete operation.
HaltHalt 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.
DeleteDelete extends the Halt policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
WipeOutWipeOut 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.

kubectl get cluster mycluster -n demo > NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE mycluster milvus-2.3.2 Delete Running 14m
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

Steps

Run the command below to delete a specified cluster.

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
kbcli cluster delete mycluster -n demo

© 2025 ApeCloud PTE. Ltd.