Version: release-0.9

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 kubectl or a YAML file. You can find the YAML examples and guides in the GitHub repository.

Before you start

Install KubeBlocks.
View all the database types and versions available for creating a cluster.
Make sure the milvus cluster definition is installed. If the cluster definition is not available, refer to this doc to enable it first.
```
kubectl get clusterdefinition milvus
>
NAME         TOPOLOGIES   SERVICEREFS   STATUS      AGE
milvus                                  Available   30m
```
View all available versions for creating a cluster.
```
kubectl get clusterversions -l clusterdefinition.kubeblocks.io/name=milvus
```
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:
  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`, `Halt`, `Delete`, `WipeOut`. - `DoNotTerminate` blocks deletion operation. - `Halt` deletes workload resources such as statefulset and deployment workloads but keep PVCs. - `Delete` is based on Halt and deletes PVCs. - `WipeOut` is based on Delete and wipe out all volume snapshots and snapshot data from a backup storage location.
`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

Scaling

You can vertically scale a Milvus cluster by changing resource requirements and limits (CPU and storage). For example, you can change the resource class from 1C2G to 2C4G by performing vertical scaling.

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               milvus-2.3.2   Delete                 Running   47m

Steps

There are two ways to apply vertical scaling.

OpsRequest
Edit cluster YAML file

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

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.

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: Delete

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Volume Expanding

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               milvus-2.3.2      Delete               Running   4m29s

Steps

There are two ways to apply volume expansion.

OpsRequest
Edit cluster YAML fil

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"
EOF

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.

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: 1Gi # Change the volume storage size.
  terminationPolicy: Delete

Check whether the corresponding cluster resources change.
```
kubectl describe cluster mycluster -n demo
```

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. Start this cluster again if you want to restore the cluster resources from the original storage by snapshots.

Stop a cluster

OpsRequest
Edit Cluster YAML File

Run the command below 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

Configure 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
    volumeClaimTemplates:
    - name: data
      spec:
        storageClassName: standard
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi

Start a cluster

OpsRequest
Edit Cluster YAML File

Run the command below 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 

Change 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
    volumeClaimTemplates:
    - name: data
      spec:
        storageClassName: standard
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi

Restart

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

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.

Manage Milvus with KubeBlocks

Before you start​

Create a cluster​

Scaling​

Before you start​

Steps​

Volume Expanding​

Before you start​

Steps​

Stop/Start a Cluster​

Stop a cluster​

Start a cluster​

Restart​

Before you start

Create a cluster

Scaling

Before you start

Steps

Volume Expanding

Before you start

Steps

Stop/Start a Cluster

Stop a cluster

Start a cluster

Restart