KubeBlocks
BlogsKubeBlocks Cloud
⌘K
​
Overview
Quickstart

Operations

Lifecycle Management
Vertical Scaling
Horizontal Scaling
Volume Expansion
Manage Qdrant Services
Minor Version Upgrade
Decommission Qdrant Replica

Backup And Restores

Create BackupRepo
Create Full Backup
Scheduled Backups
Restore Qdrant Cluster

Monitoring

Observability for Qdrant Clusters

tpl

  1. Prerequisites
    1. System Requirements
    2. Verify Qdrant Add-on
    3. Verify Supported Qdrant Versions
    4. Storage Configuration
  2. Deploy a Qdrant Cluster
    1. Create a Version-Specific Qdrant Cluster
  3. Verify Cluster Status
  4. Stop the Qdrant Cluster
  5. Start the Qdrant Cluster
  6. Delete Qdrant Cluster

Qdrant Quickstart

This guide provides a comprehensive walkabout for deploying and managing Qdrant ReplicaSet Clusters using the KubeBlocks Qdrant Add-on, covering:

  • System prerequisites and add-on installation
  • Cluster creation and configuration
  • Operational management including start/stop procedures
  • Connection methods and cluster monitoring

Prerequisites

System Requirements

Before proceeding, verify your environment meets these requirements:

  • A functional Kubernetes cluster (v1.21+ recommended)
  • kubectl v1.21+ installed and configured with cluster access
  • Helm installed (installation guide)
  • KubeBlocks installed (installation guide)

Verify Qdrant Add-on

The Qdrant Add-on is included with KubeBlocks by default. Check its status:

helm list -n kb-system | grep qdrant
Example Output:
NAME                NAMESPACE   REVISION    UPDATED                     STATUS      CHART
kb-addon-qdrant     kb-system   1           2025-05-21                  deployed    qdrant-1.0.0

If the add-on isn't enabled, choose an installation method:

# Add Helm repo
helm repo add kubeblocks-addons https://apecloud.github.io/helm-charts
# For users in Mainland China, if GitHub is inaccessible or slow, use this alternative repo:
#helm repo add kubeblocks-addons https://jihulab.com/api/v4/projects/150246/packages/helm/stable

# Update helm repo
helm repo update
# Search available Add-on versions
helm search repo kubeblocks/qdrant --versions
# Install your desired version (replace <VERSION> with your chosen version)
helm upgrade -i kb-addon-qdrant kubeblocks-addons/qdrant --version <VERSION> -n kb-system
# Add an index (kubeblocks is added by default)
kbcli addon index add kubeblocks https://github.com/apecloud/block-index.git
# Update the index
kbcli addon index update kubeblocks
# Update all indexes
kbcli addon index update --all

To search and install an addon:

# Search Add-on
kbcli addon search qdrant
# Install Add-on with your desired version (replace <VERSION> with your chosen version)
kbcli addon install qdrant --version <VERSION>

Example Output:

ADDON   VERSION         INDEX
qdrant   0.9.0           kubeblocks
qdrant   0.9.1           kubeblocks
qdrant   1.0.0           kubeblocks

To enable or disable an addon:

# Enable Add-on
kbcli addon enable qdrant
# Disable Add-on
kbcli addon disable qdrant
NOTE

Version Compatibility

Always verify that the Qdrant Add-on version matches your KubeBlocks major version to avoid compatibility issues.

Verify Supported Qdrant Versions

List available Qdrant versions:

kubectl get cmpv qdrant
Example Output
NAME     VERSIONS                                STATUS      AGE
qdrant   1.14.0,1.10.0,1.8.4,1.8.1,1.7.3,1.5.0   Available   26d

Check version compatibility for ComponentDefinitions

Step 1. Get the list of ComponentDefinition associated with a given ComponentVersion

kubectl get cmpv qdrant -ojson | jq -r '.metadata.annotations."componentversion.kubeblocks.io/compatible-definitions"' | tr ',' '\n'
Example Output
qdrant-1.0.0

Step 2. Get the list of ComponentDefinition associated with a given ComponentVersion

kubectl get cmpv qdrant -o json | jq -r '.spec.compatibilityRules[] | select(.compDefs | any(startswith("^qdrant"))) | .releases[]'

This returns versions compatible with ComponentDefinition named qdrant:

Example Output
1.5.0
1.7.3
1.8.1
1.8.4
1.10.0
1.14.0

Storage Configuration

Qdrant requires persistent storage. Verify available options:

kubectl get storageclass

Recommended storage characteristics:

  • Minimum 20Gi capacity
  • ReadWriteOnce access mode
  • Supports volume expansion
  • Appropriate performance for workload

Deploy a Qdrant Cluster

Deploy a basic Qdrant Cluster with default settings:

kubectl apply -f https://raw.githubusercontent.com/apecloud/kubeblocks-addons/refs/heads/main/examples/qdrant/cluster.yaml

This creates:

  • A Qdrant Cluster with 3 replicas.
  • Default resource allocations (0.5 CPU, 0.5Gi memory)
  • 20Gi persistent storage
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: qdrant-cluster
  namespace: demo
spec:
  # Specifies the behavior when a Cluster is deleted.
  # Valid options are: [DoNotTerminate, Delete, WipeOut] (`Halt` is deprecated since KB 0.9)
  # - `DoNotTerminate`: Prevents deletion of the Cluster. This policy ensures that all resources remain intact.
  # - `Delete`: Extends the `Halt` policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
  # - `WipeOut`: 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.
  terminationPolicy: Delete
  # 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
  clusterDef: qdrant
  # Specifies the name of the ClusterTopology to be used when creating the
  # Cluster.
  # Valid options are: [cluster]
  topology: cluster
  componentSpecs:
    - name: qdrant
      # ServiceVersion 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]
      serviceVersion: 1.10.0
      # Update `replicas` to your need.
      # Recommended values are: [3,5,7]
      replicas: 3
      # Specifies the resources required by the Component.
      resources:
        limits:
          cpu: "0.5"
          memory: "0.5Gi"
        requests:
          cpu: "0.5"
          memory: "0.5Gi"
      # Specifies a list of PersistentVolumeClaim templates that define the storage
      # requirements for the Component.
      volumeClaimTemplates:
        # Refers to the name of a volumeMount defined in
        # `componentDefinition.spec.runtime.containers[*].volumeMounts
        - name: data
          spec:
            # 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
            storageClassName: ""
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                # Set the storage size as needed
                storage: 20Gi

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

Create a Version-Specific Qdrant Cluster

To create a cluster with a specific version, configure spec.componentSpecs.serviceVersion (major.minor version) fields before applying it:

Verify Cluster Status

When deploying a Qdrant Cluster with 3 replicas:

Confirm successful deployment by checking:

  1. Cluster phase is Running
  2. All pods are operational

Check status using either method:

kubectl get cluster qdrant-cluster -n demo -w
NAME             CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS     AGE
qdrant-cluster   qdrant               Delete               Creating   27s
qdrant-cluster   qdrant               Delete               Running    64s

kubectl get pods -l app.kubernetes.io/instance=qdrant-cluster -n demo
qdrant-cluster-qdrant-0   2/2     Running   0          92s
qdrant-cluster-qdrant-1   2/2     Running   0          77s
qdrant-cluster-qdrant-2   2/2     Running   0          63s

With kbcli installed, you can view comprehensive cluster information:

kbcli cluster describe qdrant-cluster -n demo

Name: qdrant-cluster	 Created Time: May 18,2025 23:05 UTC+0800
NAMESPACE   CLUSTER-DEFINITION   TOPOLOGY   STATUS    TERMINATION-POLICY
demo        qdrant               cluster    Running   Delete

Endpoints:
COMPONENT   INTERNAL                                                   EXTERNAL
qdrant      qdrant-cluster-qdrant-qdrant.demo.svc.cluster.local:6333   <none>
            qdrant-cluster-qdrant-qdrant.demo.svc.cluster.local:6334

Topology:
COMPONENT   SERVICE-VERSION   INSTANCE                  ROLE     STATUS    AZ       NODE    CREATED-TIME
qdrant      1.10.0            qdrant-cluster-qdrant-0   <none>   Running   zone-x   x.y.z   May 18,2025 23:05 UTC+0800
qdrant      1.10.0            qdrant-cluster-qdrant-1   <none>   Running   zone-x   x.y.z   May 18,2025 23:06 UTC+0800
qdrant      1.10.0            qdrant-cluster-qdrant-2   <none>   Running   zone-x   x.y.z   May 18,2025 23:06 UTC+0800

Resources Allocation:
COMPONENT   INSTANCE-TEMPLATE   CPU(REQUEST/LIMIT)   MEMORY(REQUEST/LIMIT)   STORAGE-SIZE   STORAGE-CLASS
qdrant                          500m / 500m          512Mi / 512Mi           data:20Gi      <none>

Images:
COMPONENT   COMPONENT-DEFINITION   IMAGE
qdrant      qdrant-1.0.0           docker.io/qdrant/qdrant:v1.10.0
                                   docker.io/apecloud/curl-jq:0.1.0

Data Protection:
BACKUP-REPO   AUTO-BACKUP   BACKUP-SCHEDULE   BACKUP-METHOD   BACKUP-RETENTION   RECOVERABLE-TIME

Show cluster events: kbcli cluster list-events -n demo qdrant-cluster

Stop the Qdrant Cluster

Stopping a cluster temporarily suspends operations while preserving all data and configuration:

Key Effects:

  • Compute resources (Pods) are released
  • Persistent storage (PVCs) remains intact
  • Service definitions are maintained
  • Cluster configuration is preserved
  • Operational costs are reduced
kubectl apply -f https://raw.githubusercontent.com/apecloud/kubeblocks-addons/refs/heads/main/examples/qdrant/stop.yaml
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: qdrant-stop
  namespace: demo
spec:
  clusterName: qdrant-cluster
  type: Stop

Alternatively, stop by setting spec.componentSpecs.stop to true:

kubectl patch cluster qdrant-cluster -n demo --type='json' -p='[
{
  "op": "add",
  "path": "/spec/componentSpecs/0/stop",
  "value": true
}
]'
spec:
  componentSpecs:
    - name: qdrant
      stop: true  # Set to stop component
      replicas: 3

Start the Qdrant Cluster

Restarting a stopped cluster resumes operations with all data and configuration intact.

Key Effects:

  • Compute resources (Pods) are recreated
  • Services become available again
  • Cluster returns to previous state
kubectl apply -f https://raw.githubusercontent.com/apecloud/kubeblocks-addons/refs/heads/main/examples/qdrant/start.yaml
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: qdrant-start
  namespace: demo
spec:
  clusterName: qdrant-cluster
  type: Start

Restart by setting spec.componentSpecs.stop to false:

kubectl patch cluster qdrant-cluster -n demo --type='json' -p='[
{
  "op": "remove",
  "path": "/spec/componentSpecs/0/stop"
}
]'

Delete Qdrant Cluster

Choose carefully based on your data retention needs:

PolicyResources RemovedData RemovedRecommended For
DoNotTerminateNoneNoneCritical production clusters
DeleteAll resourcesPVCs deletedNon-critical environments
WipeOutAll resourcesEverything*Test environments only

*Includes snapshots and backups in external storage

Pre-Deletion Checklist:

  1. Verify no applications are using the cluster
  2. Ensure required backups exist
  3. Confirm proper terminationPolicy is set
  4. Check for dependent resources

For test environments, use this complete cleanup:

kubectl patch cluster qdrant-cluster -p '{"spec":{"terminationPolicy":"WipeOut"}}' --type="merge" -n demo
kubectl delete cluster qdrant-cluster -n demo

© 2025 ApeCloud PTE. Ltd.