Skip to main content
Version: Preview

Manage Qdrant with KubeBlocks

The popularity of generative AI (Generative AI) has aroused widespread attention and completely ignited the vector database (Vector Database) market. Qdrant (read: quadrant) is a vector similarity search engine and vector database. It provides a production-ready service with a convenient API to store, search, and manage points—vectors with an additional payload Qdrant is tailored to extended filtering support. It makes it useful for all sorts of neural-network or semantic-based matching, faceted search, and other applications.

KubeBlocks supports the management of Qdrant. This tutorial illustrates how to create and manage a Qdrant cluster by kbcli, kubectl or a YAML file. You can find the YAML examples in the GitHub repository.

Before you start​

Create a cluster​

Steps

KubeBlocks implements a Cluster CRD to define a cluster. Here is an example of creating a Qdrant Replication cluster. Primary and Secondary are distributed on different nodes by default. But if you only have one node for deploying a Replication Cluster, 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:
  name: mycluster
  namespace: demo
spec:
  terminationPolicy: Delete
  clusterDef: qdrant
  topology: cluster
  componentSpecs:
    - name: qdrant
      serviceVersion: 1.10.0
      replicas: 3
      resources:
        limits:
          cpu: "0.5"
          memory: "0.5Gi"
        requests:
          cpu: "0.5"
          memory: "0.5Gi"
      volumeClaimTemplates:
        - name: data
          spec:
            storageClassName: ""
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 20Gi
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 qdrant to create a Qdrant Cluster.
spec.topologyIt specifies the name of the ClusterTopology to be used when creating the Cluster. The valid option is [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.serviceVersionIt specifies the version of the Service expected to be provisioned by this Component. Valid options are [1.10.0,1.5.0,1.7.3,1.8.1,1.8.4].
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. Recommended values are [3,5,7].
spec.componentSpecs.resourcesIt specifies the resources required by the Component.
spec.componentSpecs.volumeClaimTemplatesIt specifies a list of PersistentVolumeClaim templates that define the storage requirements for the Component.
spec.componentSpecs.volumeClaimTemplates.nameIt refers to the name of a volumeMount defined in componentDefinition.spec.runtime.containers[*].volumeMounts.
spec.componentSpecs.volumeClaimTemplates.spec.storageClassNameIt is the name of the StorageClass required by the claim. If not specified, the StorageClass annotated with storageclass.kubernetes.io/is-default-class=true will be used by default.
spec.componentSpecs.volumeClaimTemplates.spec.resources.storageYou can set the storage size as needed.

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 Qdrant cluster object:

kubectl get cluster mycluster -n demo -o yaml

Connect to a Qdrant cluster​

Qdrant provides both HTTP and gRPC protocols for client access on ports 6333 and 6334 respectively. Depending on where the client is, different connection options are offered to connect to the Qdrant cluster.

  1. Run the following command to port forward the service.

    kubectl port-forward svc/mycluster-qdrant 6333:6333 -n demo

  2. Open a new terminal and run the following command to connect to the database.

    curl http://127.0.0.1:6333/collections

    Refer to the official Qdrant documents for the cluster operations.

Scale​

The scaling function for Qdrant is also supported.

Scale horizontally​

Horizontal scaling changes the amount of pods. For example, you can scale out replicas from three to five.

From v0.9.0, besides replicas, KubeBlocks also supports scaling in and out instances, refer to the Horizontal Scale tutorial for more details and examples.

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

Steps​

  1. Apply an OpsRequest to a specified cluster. Configure the parameters according to your needs.

    The example below means adding two replicas.

    kubectl apply -f - <<EOF
    apiVersion: apps.kubeblocks.io/v1alpha1
    kind: OpsRequest
    metadata:
      name: ops-horizontal-scaling
      namespace: demo
    spec:
      clusterName: mycluster
      type: HorizontalScaling
      horizontalScaling:
      - componentName: qdrant
        scaleOut:
          replicaChanges: 2
    EOF

    If you want to scale in replicas, replace scaleOut with scaleIn.

    The example below means deleting two replicas.

    kubectl apply -f - <<EOF
    apiVersion: apps.kubeblocks.io/v1alpha1
    kind: OpsRequest
    metadata:
      name: ops-horizontal-scaling
      namespace: demo
    spec:
      clusterName: mycluster
      type: HorizontalScaling
      horizontalScaling:
      - componentName: qdrant
        scaleIn:
          replicaChanges: 2
    EOF

  2. Check the operation status to validate the horizontal scaling status.

    kubectl get ops -n demo
    >
    NAMESPACE   NAME                     TYPE                CLUSTER     STATUS    PROGRESS   AGE
    demo        ops-horizontal-scaling   HorizontalScaling   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

Scale vertically​

You can vertically scale a 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   qdrant                              Delete                 Running   47m

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: qdrant
        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   qdrant                              Delete                 Running   47m

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: qdrant
        volumeClaimTemplates:
        - name: data
          storage: "40Gi"
    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, 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: qdrant
    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 by snapshots if you want to restore the cluster resources.

Stop a cluster​

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

    Configure replicas as 0 to delete pods.

    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.

    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

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

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

Backup and restore​

The backup and restore operations for Qdrant are the same as those of other clusters and you can refer to the backup and restore documents for details. Remember to use --method parameter.