Skip to main content
Version: Preview

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

Create a cluster

KubeBlocks implements a Cluster CRD to define a cluster. Here is an example of creating a Milvus cluster. If you only have one node for deploying a cluster with multiple replicas, configure the cluster affinity by setting spec.schedulingPolicy or spec.componentSpecs.schedulingPolicy. For details, you can refer to the API docs. But for a production environment, it is not recommended to deploy all replicas on one node, which may decrease the cluster availability.

cat <<EOF | kubectl apply -f -
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
namespace: demo
name: mycluster
spec:
terminationPolicy: Delete
clusterDef: milvus
topology: cluster
componentSpecs:
- name: proxy
replicas: 1
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
serviceRefs:
- name: milvus-meta-storage
namespace: demo
clusterServiceSelector:
cluster: etcdm-cluster
service:
component: etcd
service: headless
port: client
- name: milvus-log-storage
namespace: demo
clusterServiceSelector:
cluster: pulsarm-cluster
service:
component: broker
service: headless
port: pulsar
- name: milvus-object-storage
namespace: demo
clusterServiceSelector:
cluster: miniom-cluster
service:
component: minio
service: headless
port: http
credential:
component: minio
name: admin
disableExporter: true
- name: mixcoord
replicas: 1
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
serviceRefs:
- name: milvus-meta-storage
namespace: demo
clusterServiceSelector:
cluster: etcdm-cluster
service:
component: etcd
service: headless
port: client

- name: milvus-log-storage
namespace: demo
clusterServiceSelector:
cluster: pulsarm-cluster
service:
component: broker
service: headless
port: pulsar

- name: milvus-object-storage
namespace: demo
clusterServiceSelector:
cluster: miniom-cluster
service:
component: minio
service: headless
port: http
credential:
component: minio
name: admin

disableExporter: true
- name: datanode
replicas: 1
disableExporter: true
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
serviceRefs:
- name: milvus-meta-storage
namespace: demo
clusterServiceSelector:
cluster: etcdm-cluster
service:
component: etcd
service: headless
port: client

- name: milvus-log-storage
namespace: demo
clusterServiceSelector:
cluster: pulsarm-cluster
service:
component: broker
service: headless
port: pulsar

- name: milvus-object-storage
namespace: demo
clusterServiceSelector:
cluster: miniom-cluster
service:
component: minio
service: headless
port: http
credential:
component: minio
name: admin

disableExporter: true
- name: indexnode
replicas: 1
disableExporter: true
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
serviceRefs:
- name: milvus-meta-storage
namespace: demo
clusterServiceSelector:
cluster: etcdm-cluster
service:
component: etcd
service: headless
port: client

- name: milvus-log-storage
namespace: demo
clusterServiceSelector:
cluster: pulsarm-cluster
service:
component: broker
service: headless
port: pulsar

- name: milvus-object-storage
namespace: demo
clusterServiceSelector:
cluster: miniom-cluster
service:
component: minio
service: headless
port: http
credential:
component: minio
name: admin

disableExporter: true
- name: querynode
replicas: 1
disableExporter: true
resources:
limits:
cpu: "0.5"
memory: "0.5Gi"
requests:
cpu: "0.5"
memory: "0.5Gi"
serviceRefs:
- name: milvus-meta-storage
namespace: demo
clusterServiceSelector:
cluster: etcdm-cluster
service:
component: etcd
service: headless
port: client

- name: milvus-log-storage
namespace: demo
clusterServiceSelector:
cluster: pulsarm-cluster
service:
component: broker
service: headless
port: pulsar

- name: milvus-object-storage
namespace: demo
clusterServiceSelector:
cluster: miniom-cluster
service:
component: minio
service: headless
port: http
credential:
component: minio
name: admin

disableExporter: true
EOF
FieldDefinition
spec.terminationPolicyIt is the policy of cluster termination. Valid values are DoNotTerminate, Delete, WipeOut. For the detailed definition, you can refer to Termination Policy.
spec.clusterDefIt specifies the name of the ClusterDefinition to use when creating a Cluster. Note: DO NOT UPDATE THIS FIELD. The value must be milvus to create a Milvus Cluster.
spec.topologyIt specifies the name of the ClusterTopology to be used when creating the Cluster. Valid options are: [standalone,cluster].
spec.componentSpecsIt is the list of ClusterComponentSpec objects that define the individual Components that make up a Cluster. This field allows customized configuration of each component within a cluster.
spec.componentSpecs.serviceRefsIt defines a list of ServiceRef for a Component.
spec.componentSpecs.serviceRefs.nameIt specifies the identifier of the service reference declaration, defined in componentDefinition.spec.serviceRefDeclarations[*].name.
spec.componentSpecs.serviceRefs.clusterServiceSelectorIt references a service provided by another KubeBlocks Cluster.
spec.componentSpecs.serviceRefs.clusterServiceSelector.clusterIt defines the cluster name. You can name it on demand.
spec.componentSpecs.serviceRefs.clusterServiceSelector.service.componentIt defines the component name.
spec.componentSpecs.serviceRefs.clusterServiceSelector.service.serviceIt refers to the default headless Service.
spec.componentSpecs.serviceRefs.clusterServiceSelector.service.portIt refers to port name.
spec.componentSpecs.serviceRefs.clusterServiceSelector.credentialIt specifies the SystemAccount to authenticate and establish a connection with the referenced Cluster.
spec.componentSpecs.serviceRefs.clusterServiceSelector.credential.nameIt specifies to the name of the credential (SystemAccount) to reference, using account 'admin' in this case.
spec.componentSpecs.disableExporterIt determines whether metrics exporter information is annotated on the Component's headless Service. Valid options are [true, false].
spec.componentSpecs.replicasIt specifies the number of replicas of the component.
spec.componentSpecs.resourcesIt specifies the resources required by the Component.

For more API fields and descriptions, refer to the API Reference.

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.

kubectl get cluster mycluster -n demo
>
NAME CLUSTER-DEFINITION VERSION TERMINATION-POLICY STATUS AGE
mycluster milvus-2.3.2 Delete Running 4m29s

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

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

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

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.

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
  2. Check the status of the cluster to see whether it is stopped.

    kubectl get cluster 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
  2. Check the status of the cluster to see whether it is running again.

    kubectl get cluster mycluster -n demo

Delete a cluster

Termination policy

note

The termination policy determines how a cluster is deleted.

terminationPolicyDeleting Operation
DoNotTerminateDoNotTerminate prevents deletion of the Cluster. This policy ensures that all resources remain intact.
DeleteDelete deletes Cluster resources like Pods, Services, and Persistent Volume Claims (PVCs), leading to a thorough cleanup while removing all persistent data.
WipeOutWipeOut is an aggressive policy that deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, primarily 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

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