mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-29 16:08:32 +02:00
Add docs for private cloud and premium tier
This commit is contained in:
Bastian Hofmann
@@ -3,7 +3,7 @@ title: Authentication
|
||||
weight: 30
|
||||
---
|
||||
|
||||
# Authenticating to Qdrant Cloud
|
||||
# Database Authentication in Qdrant Managed Cloud
|
||||
|
||||
This page shows you how to use the Qdrant Cloud Console to create a custom API key for a cluster. You will learn how to connect to your cluster using the new API key.
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ In this case vectors will be stored on the disc in memory-mapped files, and only
|
||||
The amount of available RAM will significantly affect the performance of the search.
|
||||
As a rule of thumb, if you keep 2 times less vectors in RAM, the search latency will be 2 times lower.
|
||||
|
||||
The speed of disks is also important. [Let us know](mailto:cloud@qdrant.io) if you have special requirements for a high-volume search.
|
||||
The speed of disks is also important. [Let us know](/documentation/support/) if you have special requirements for a high-volume search.
|
||||
|
||||
## Sub-groups oriented configuration
|
||||
|
||||
|
||||
@@ -37,4 +37,4 @@ Note, that it is currently not possible to horizontally scale down the cluster i
|
||||
|
||||
We will be glad to consult you on an optimal strategy for scaling.
|
||||
|
||||
[Let us know](mailto:cloud@qdrant.io) your needs and decide together on a proper solution.
|
||||
[Let us know](/documentation/support/) your needs and decide together on a proper solution.
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Premium Tier
|
||||
weight: 66
|
||||
---
|
||||
|
||||
# Qdrant Cloud Premium Tier
|
||||
|
||||
Qdrant Cloud offers an optional premium tier for customers who require additional features and better SLA support levels. The premium tier includes:
|
||||
|
||||
* **24/7 Support**: Our support team is available around the clock to help you with any issues you may encounter.
|
||||
* **Shorter Response Times**: Premium customers receive priority support and can expect faster response times, with shorter SLAs.
|
||||
* **99.9% Uptime SLA**: We guarantee 99.9% uptime for your Qdrant Cloud clusters.
|
||||
* **Single Sign-On (SSO)**: Premium customers can use their existing SSO provider to manage access to Qdrant Cloud.
|
||||
* **VPC Private Links**: Premium customers can connect their Qdrant Cloud clusters to their VPCs using private links (AWS only).
|
||||
* **Storage encryption with shared keys**: Premium customers can encrypt their data at rest using their own keys (AWS only).
|
||||
|
||||
If you are interested in using switch to Qdrant Cloud Premium, please [contact us](/contact-us/) for more information.
|
||||
@@ -52,3 +52,19 @@ If you use multiple accounts for different purposes, it is a good idea to give t
|
||||
### Deleting an account
|
||||
|
||||
When you delete an account, all database clusters and associated data will be deleted.
|
||||
|
||||
## Enterprise Single-Sign-On (SSO)
|
||||
|
||||
Qdrant Cloud supports Enterprise Single-Sign-On for Premium Tier customers. The following providers are supported:
|
||||
|
||||
* Active Directory/LDAP
|
||||
* ADFS
|
||||
* Azure Active Directory Native
|
||||
* Google Workspace
|
||||
* OpenID Connect
|
||||
* Okta
|
||||
* PingFederate
|
||||
* SAML
|
||||
* Azure Active Directory
|
||||
|
||||
Enterprise Sign-On is available as an add-on for [Premium Tier](/documentation/cloud/premium/) customers. If you are interested in using SSO, please [contact us](/contact-us/).
|
||||
@@ -1,15 +0,0 @@
|
||||
---
|
||||
title: Cloud Support
|
||||
weight: 99
|
||||
aliases:
|
||||
---
|
||||
|
||||
# Qdrant Cloud Support and Troubleshooting
|
||||
|
||||
All Qdrant Cloud users are welcome to join our [Discord community](https://qdrant.to/discord/). Our Support Engineers are available to help you anytime.
|
||||
|
||||
|
||||
|
||||
Paid customers can also contact support directly. Links to the support portal are available in the Qdrant Cloud Console.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ To learn how Hybrid Cloud works, [read the overview document](/documentation/hyb
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Kubernetes cluster:** To create a Hybrid Cloud Environment, you need a [standard compliant](https://www.cncf.io/training/certification/software-conformance/) Kubernetes cluster. You can run this cluster in any cloud, on-premise or edge environment, with distributions that range from AWS EKS to VMWare vSphere.
|
||||
- **Kubernetes cluster:** To create a Hybrid Cloud Environment, you need a [standard compliant](https://www.cncf.io/training/certification/software-conformance/) Kubernetes cluster. You can run this cluster in any cloud, on-premise or edge environment, with distributions that range from AWS EKS to VMWare vSphere. See [Deployment Platforms](/documentation/hybrid-cloud/platform-deployment-options/) for more information.
|
||||
- **Storage:** For storage, you need to set up the Kubernetes cluster with a Container Storage Interface (CSI) driver that provides block storage. For vertical scaling, the CSI driver needs to support volume expansion. For backups and restores, the driver needs to support CSI snapshots and restores.
|
||||
|
||||
<aside role="status">Network storage systems like NFS or object storage systems such as S3 are not supported.</aside>
|
||||
@@ -50,6 +50,78 @@ Open Containers Initiative (OCI) Helm charts:
|
||||
- `registry.cloud.qdrant.io/qdrant-charts/qdrant-cluster-manager`
|
||||
- `registry.cloud.qdrant.io/qdrant-charts/prometheus`
|
||||
|
||||
### Rate limits at `docker.io`
|
||||
|
||||
By default, the Qdrant database image will be fetched from Docker Hub, which is the main source of truth. Docker Hub has rate limits for anonymous users. If you have larger setups and also fetch other images from their, you may run into these limits. To solve this, you can provide authentication information for Docker Hub.
|
||||
|
||||
First, create a secret with your Docker Hub credentials into your `the-qdrant-namespace` namespace:
|
||||
|
||||
```shell
|
||||
kubectl create secret docker-registry dockerhub-registry-secret --namespace the-qdrant-namespace --docker-server=https://index.docker.io/v1/ --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
|
||||
```
|
||||
|
||||
Then, you can reference this secret by adding the following configuration in the operator configuration YAML editor in the advanced section of the Hybrid Cloud Environment:
|
||||
|
||||
```yaml
|
||||
qdrant:
|
||||
image:
|
||||
pull_secret: "dockerhub-registry-secret"
|
||||
```
|
||||
|
||||
### Mirroring images and charts
|
||||
|
||||
To mirror all necessary container images and Helm charts into your own registry, you can either use a replication feature that your registry provides, or you can manually sync the images with [Skopeo](https://github.com/containers/skopeo):
|
||||
|
||||
You can find your personal credentials for the Qdrant Cloud registry in the onboarding command, or you can fetch them with `kubectl`:
|
||||
|
||||
```shell
|
||||
kubectl get secrets qdrant-registry-creds --namespace the-qdrant-namespace -o jsonpath='{.data.\.dockerconfigjson}' | base64 --decode | jq -r '.'
|
||||
```
|
||||
|
||||
First login to the source registry:
|
||||
|
||||
```shell
|
||||
skopeo login registry.cloud.qdrant.io
|
||||
```
|
||||
|
||||
Then login to your own registry:
|
||||
|
||||
```shell
|
||||
skopeo login your-registry.example.com
|
||||
```
|
||||
|
||||
To sync all container images:
|
||||
|
||||
```shell
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/qdrant-operator your-registry.example.com/qdrant/qdrant-operator
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/qdrant-cloud-agent your-registry.example.com/qdrant/qdrant-cloud-agent
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/prometheus your-registry.example.com/qdrant/prometheus
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/prometheus-config-reloader your-registry.example.com/qdrant/prometheus-config-reloader
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/kube-state-metrics your-registry.example.com/qdrant/kube-state-metrics
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/qdrant your-registry.example.com/qdrant/qdrant
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/cluster-manager your-registry.example.com/qdrant/cluster-manager
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/operator your-registry.example.com/qdrant/operator
|
||||
```
|
||||
|
||||
To sync all helm charts:
|
||||
|
||||
```shell
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant-charts/prometheus your-registry.example.com/qdrant-charts/prometheus
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant-charts/qdrant-operator your-registry.example.com/qdrant-charts/qdrant-operator
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant-charts/qdrant-operator-crds your-registry.example.com/qdrant-charts/qdrant-operator-crds
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant-charts/qdrant-cloud-agent your-registry.example.com/qdrant-charts/qdrant-cloud-agent
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant-charts/operator your-registry.example.com/qdrant-charts/operator
|
||||
```
|
||||
|
||||
With the above configuration, you can add the following values to the advanced section of your Hybrid Cloud Environment:
|
||||
|
||||
* Container registry URL: `your-registry.example.com/qdrant`
|
||||
* Chart repository URL: `oci://your-registry.example.com/qdrant-charts`
|
||||
|
||||
If you registry requires authentication, you have to create your own secrets with authentication information into your `the-qdrant-namespace` namespace.
|
||||
|
||||
You can then reference they secret by
|
||||
|
||||
## Installation
|
||||
|
||||
1. To set up Hybrid Cloud, open the Qdrant Cloud Console at [cloud.qdrant.io](https://cloud.qdrant.io). On the dashboard, select **Hybrid Cloud**.
|
||||
|
||||
@@ -7,7 +7,7 @@ weight: 5
|
||||
|
||||
This page provides an overview of how to deploy Qdrant Hybrid Cloud on various managed Kubernetes platforms.
|
||||
|
||||
For a general list of prerequisites and installation steps, see our [Hybrid Cloud setup guide](/documentation/hybrid-cloud/hybrid-cloud-setup/).
|
||||
For a general list of prerequisites and installation steps, see our [Hybrid Cloud setup guide](/documentation/hybrid-cloud/hybrid-cloud-setup/). This platform specific documentation also applies to Qdrant Private Cloud.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Private Cloud
|
||||
weight: 10
|
||||
---
|
||||
|
||||
# Qdrant Private Cloud
|
||||
|
||||
Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastucture. It uses the same Qdrant Operator that powers Qdrant Managed Cloud and Qdrant Hybrid Cloud, but without any connection to the Qdrant Cloud Management Console.
|
||||
|
||||
On top of the open source Qdrant database, it allows
|
||||
|
||||
* Easy deployment and management of Qdrant database clusters in your own Kubernetes infrastructure
|
||||
* Zero-downtime upgrades of the Qdrant database with replication
|
||||
* Vertical and horizontal up and downscaling of the Qdrant database with auto rebalancing and shard splitting
|
||||
* Full control over scheduling, including Multi-AZ deployments
|
||||
* Backup & Disaster Recovery
|
||||
* Extended telemetry
|
||||
* Qdrant Enterprise Support Services
|
||||
|
||||
If you are interested in using Qdrant Private Cloud, please [contact us](/contact-us/) for more information.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: Backups
|
||||
weight: 4
|
||||
---
|
||||
|
||||
# Backups
|
||||
|
||||
To create a one-time backup, create a `QdrantClusterSnapshot` resource:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantClusterSnapshot
|
||||
metadata:
|
||||
name: "qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840-snapshot-timestamp"
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
retention: 1h
|
||||
```
|
||||
|
||||
You can also create a recurring backup with the `QdrantClusterScheduledSnapshot` resource:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantClusterScheduledSnapshot
|
||||
metadata:
|
||||
name: "qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840-snapshot-timestamp"
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
scheduleShortId: a7d8d973
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
# every hour
|
||||
schedule: "0 * * * *"
|
||||
retention: 1h
|
||||
```
|
||||
|
||||
To resture from a backup, create a `QdrantClusterRestore` resource:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantClusterRestore
|
||||
metadata:
|
||||
name: "qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840-snapshot-restore-01"
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
source:
|
||||
snapshotName: qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840-snapshot-timestamp
|
||||
namespace: qdrant-private-cloud
|
||||
destination:
|
||||
name: qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840
|
||||
namespace: qdrant-private-cloud
|
||||
```
|
||||
|
||||
Note that with all resources `cluster-id` and `customer-id` label must be set to the values of the corresponding `QdrantCluster` resource.
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
title: Changelog
|
||||
weight: 5
|
||||
---
|
||||
|
||||
# Changelog
|
||||
|
||||
## 0.1.0
|
||||
|
||||
* Initial release
|
||||
@@ -0,0 +1,351 @@
|
||||
---
|
||||
title: Configuration
|
||||
weight: 2
|
||||
---
|
||||
|
||||
# Private Cloud Configuration
|
||||
|
||||
The Qdrant Privagte Cloud helm chart has several configuration options. The following YAML shows all configuration options with their default values:
|
||||
|
||||
```yaml
|
||||
operator:
|
||||
# Amount of replicas for the Qdrant operator (v2)
|
||||
replicaCount: 1
|
||||
|
||||
image:
|
||||
# Image repository for the qdrant operator
|
||||
repository: registry.cloud.qdrant.io/qdrant/operator
|
||||
# Image pullPolicy
|
||||
pullPolicy: IfNotPresent
|
||||
# Overrides the image tag whose default is the chart appVersion.
|
||||
tag: ""
|
||||
|
||||
# Optional image pull secrets
|
||||
imagePullSecrets:
|
||||
- name: qdrant-registry-creds
|
||||
|
||||
nameOverride: ""
|
||||
fullnameOverride: "operator"
|
||||
|
||||
# Service account configuration
|
||||
serviceAccount:
|
||||
create: true
|
||||
annotations: { }
|
||||
|
||||
# Additional pod annotations
|
||||
podAnnotations: { }
|
||||
|
||||
# pod security context
|
||||
podSecurityContext:
|
||||
runAsNonRoot: true
|
||||
runAsUser: 10001
|
||||
runAsGroup: 20001
|
||||
fsGroup: 30001
|
||||
|
||||
# container security context
|
||||
securityContext:
|
||||
capabilities:
|
||||
drop:
|
||||
- ALL
|
||||
readOnlyRootFilesystem: true
|
||||
runAsNonRoot: true
|
||||
runAsUser: 10001
|
||||
runAsGroup: 20001
|
||||
allowPrivilegeEscalation: false
|
||||
seccompProfile:
|
||||
type: RuntimeDefault
|
||||
|
||||
# Configuration for the Qdrant operator service to expose metrics
|
||||
service:
|
||||
enabled: true
|
||||
type: ClusterIP
|
||||
metricsPort: 9290
|
||||
|
||||
# Configuration for the Qdrant operator service monitor to scrape metrics
|
||||
serviceMonitor:
|
||||
enabled: false
|
||||
|
||||
# Resource requests and limits for the Qdrant operator
|
||||
resources: { }
|
||||
|
||||
# Node selector for the Qdrant operator
|
||||
nodeSelector: { }
|
||||
|
||||
# Tolerations for the Qdrant operator
|
||||
tolerations: [ ]
|
||||
|
||||
# Affinity configuration for the Qdrant operator
|
||||
affinity: { }
|
||||
|
||||
watch:
|
||||
# If true, watches only the namespace where the Qdrant operator is deployed, otherwise watches the namespaces in watch.namespaces
|
||||
onlyReleaseNamespace: true
|
||||
# an empty list watches all namespaces.
|
||||
namespaces: [ ]
|
||||
|
||||
limitRBAC: true
|
||||
|
||||
# Configuration for the Qdrant operator (v2)
|
||||
settings:
|
||||
# Does the operator run inside of a Kubernetes cluster (kubernetes) or outside (local)
|
||||
appEnvironment: kubernetes
|
||||
# The log level for the operator
|
||||
# Available options: DEBUG | INFO | WARN | ERROR
|
||||
logLevel: INFO
|
||||
# Metrics contains the operator config related the metrics
|
||||
metrics:
|
||||
# The port used for metrics
|
||||
port: 9290
|
||||
# Health contains the operator config related the health probe
|
||||
healthz:
|
||||
# The port used for the health probe
|
||||
port: 8285
|
||||
# Controller related settings
|
||||
controller:
|
||||
# The period a forced recync is done by the controller (if watches are missed / nothing happened)
|
||||
forceResyncPeriod: 2m
|
||||
# QPS indicates the maximum QPS to the master from this client.
|
||||
# Default is 200
|
||||
qps: 200
|
||||
# Maximum burst for throttle.
|
||||
# Default is 500.
|
||||
burst: 500
|
||||
# Features contains the settings for enabling / disabling the individual features of the operator
|
||||
features:
|
||||
# ClusterManagement contains the settings for qdrant (database) cluster management
|
||||
clusterManagement:
|
||||
# Whether or not the Qdrant cluster features are enabled.
|
||||
# If disabled, all other properties in this struct are disregarded. Otherwise, the individual features will be inspected.
|
||||
# Default is true.
|
||||
enable: true
|
||||
# The StorageClass used to make database and snapshot PVCs.
|
||||
# Default is nil, meaning the default storage class of Kubernetes.
|
||||
storageClass:
|
||||
# The StorageClass used to make database PVCs.
|
||||
# Default is nil, meaning the default storage class of Kubernetes.
|
||||
#database:
|
||||
# The StorageClass used to make snapshot PVCs.
|
||||
# Default is nil, meaning the default storage class of Kubernetes.
|
||||
#snapshot:
|
||||
# Qdrant config contains settings specific for the database
|
||||
qdrant:
|
||||
# The config where to find the image for qdrant
|
||||
image:
|
||||
# The repository where to find the image for qdrant
|
||||
# Default is "qdrant/qdrant"
|
||||
repository: registry.cloud.qdrant.io/qdrant/qdrant
|
||||
# Docker image pull policy
|
||||
# Default "IfNotPresent", unless the tag is dev, master or latest. Then "Always"
|
||||
#pullPolicy:
|
||||
# Docker image pull secret name
|
||||
# This secret should be available in the namespace where the cluster is running
|
||||
# Default not set
|
||||
pullSecretName: qdrant-registry-creds
|
||||
# Qdrant DB log level
|
||||
# Available options: DEBUG | INFO | WARN | ERROR
|
||||
# Default is "INFO"
|
||||
logLevel: INFO
|
||||
# Default Qdrant security context configuration
|
||||
securityContext:
|
||||
# Enable default security context
|
||||
# Default is false
|
||||
enabled: false
|
||||
# Default user for qdrant container
|
||||
# Default not set
|
||||
#user: 1000
|
||||
# Default fsGroup for qdrant container
|
||||
# Default not set
|
||||
#fsUser: 2000
|
||||
# Default group for qdrant container
|
||||
# Default not set
|
||||
#group: 3000
|
||||
# Network policies configuration for the Qdrant databases
|
||||
networkPolicies:
|
||||
ingress:
|
||||
- ports:
|
||||
- protocol: TCP
|
||||
port: 6333
|
||||
- protocol: TCP
|
||||
port: 6334
|
||||
# Allow DNS resolution from qdrant pods at Kubernetes internal DNS server
|
||||
egress:
|
||||
- to:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
kubernetes.io/metadata.name: kube-system
|
||||
ports:
|
||||
- protocol: UDP
|
||||
port: 53
|
||||
# Scheduling config contains the settings specific for scheduling
|
||||
scheduling:
|
||||
# Default topology spread constraints (list from type corev1.TopologySpreadConstraint)
|
||||
# Default is an empty list
|
||||
topologySpreadConstraints: [ ]
|
||||
# Default pod disruption budget (object from type policyv1.PodDisruptionBudgetSpec)
|
||||
# Default is not set
|
||||
podDisruptionBudget: { }
|
||||
# ClusterManager config contains the settings specific for cluster manager
|
||||
clusterManager:
|
||||
# Whether or not the cluster manager (on operator level).
|
||||
# If disabled, all other properties in this struct are disregarded. Otherwise, the individual features will be inspected.
|
||||
# Default is false.
|
||||
enable: true
|
||||
# The endpoint address the cluster manager could be reached
|
||||
# If set, this should be a full URL like: http://cluster-manager.qdrant-cloud-ns.svc.cluster.local:7333
|
||||
endpointAddress: http://cluster-manager
|
||||
# InvocationInterval is the interval between calls (started after the previous call is retured)
|
||||
# Default is 10 seconds
|
||||
invocationInterval: 10s
|
||||
# Timeout is the duration a single call to the cluster manager is allowed to take.
|
||||
# Default is 30 seconds
|
||||
timeout: 30s
|
||||
# Specifies overrides for the manage rules
|
||||
manageRulesOverrides:
|
||||
#dry_run:
|
||||
#max_transfers:
|
||||
#max_transfers_per_collection:
|
||||
#rebalance:
|
||||
#replicate:
|
||||
# Ingress config contains the settings specific for ingress
|
||||
ingress:
|
||||
# Whether or not the Ingress feature is enabled.
|
||||
# Default is true.
|
||||
enable: false
|
||||
# Which specific ingress provider should be used
|
||||
# Default is KubernetesIngress
|
||||
provider: KubernetesIngress
|
||||
# The specific settings when the Provider is QdrantCloudTraefik
|
||||
qdrantCloudTraefik:
|
||||
# Enable tls
|
||||
# Default is false
|
||||
tls: false
|
||||
# Secret with TLS certificate
|
||||
# Default is None
|
||||
secretName: ""
|
||||
# List of Traefik middlewares to apply
|
||||
# Default is an empty list
|
||||
middlewares: [ ]
|
||||
# IP Allowlist Strategy for Traefik
|
||||
# Default is None
|
||||
ipAllowlistStrategy:
|
||||
# Enable body validator plugin and matching ingressroute rules
|
||||
# Default is false
|
||||
enableBodyValidatorPlugin: false
|
||||
# The specific settings when the Provider is KubernetesIngress
|
||||
kubernetesIngress:
|
||||
# Name of the ingress class
|
||||
# Default is None
|
||||
#ingressClassName:
|
||||
# TelemetryTimeout is the duration a single call to the cluster telemetry endpoint is allowed to take.
|
||||
# Default is 3 seconds
|
||||
telemetryTimeout: 3s
|
||||
# MaxConcurrentReconciles is the maximum number of concurrent Reconciles which can be run. Defaults to 20.
|
||||
maxConcurrentReconciles: 20
|
||||
# BackupManagementConfig contains the settings for backup management
|
||||
backupManagement:
|
||||
# Whether or not the backup features are enabled.
|
||||
# If disabled, all other properties in this struct are disregarded. Otherwise, the individual features will be inspected.
|
||||
# Default is true.
|
||||
enable: true
|
||||
# Snapshots contains the settings for snapshots as part of backup management.
|
||||
snapshots:
|
||||
# Whether or not the Snapshot feature is enabled.
|
||||
# Default is true.
|
||||
enable: true
|
||||
# The VolumeSnapshotClass used to make VolumeSnapshots.
|
||||
# Default is "csi-snapclass".
|
||||
volumeSnapshotClass: "csi-snapclass"
|
||||
# The duration a snapshot is retained when the phase becomes Failed or Skipped
|
||||
# Default is 72h (3d).
|
||||
retainUnsuccessful: 72h
|
||||
# MaxConcurrentReconciles is the maximum number of concurrent Reconciles which can be run. Defaults to 1.
|
||||
maxConcurrentReconciles: 1
|
||||
# ScheduledSnapshots contains the settings for scheduled snapshot as part of backup management.
|
||||
scheduledSnapshots:
|
||||
# Whether or not the ScheduledSnapshot feature is enabled.
|
||||
# Default is true.
|
||||
enable: true
|
||||
# RemoveCronJobs can be enabled when the previous [Python] operator (qdrant-operator) has been run and this
|
||||
# operator should remove the cron jobs it created (not used by this operator anymore).
|
||||
# Default is true.
|
||||
removeCronJobs: true
|
||||
# MaxConcurrentReconciles is the maximum number of concurrent Reconciles which can be run. Defaults to 1.
|
||||
maxConcurrentReconciles: 1
|
||||
# Restores contains the settings for restoring (a snapshot) as part of backup management.
|
||||
restores:
|
||||
# Whether or not the Restore feature is enabled.
|
||||
# Default is true.
|
||||
enable: true
|
||||
# MaxConcurrentReconciles is the maximum number of concurrent Reconciles which can be run. Defaults to 1.
|
||||
maxConcurrentReconciles: 1
|
||||
|
||||
qdrant-cluster-manager:
|
||||
replicaCount: 1
|
||||
|
||||
image:
|
||||
repository: registry.cloud.qdrant.io/qdrant/cluster-manager
|
||||
pullPolicy: IfNotPresent
|
||||
# Overrides the image tag whose default is the chart appVersion.
|
||||
tag: ""
|
||||
|
||||
imagePullSecrets:
|
||||
- name: qdrant-registry-creds
|
||||
nameOverride: ""
|
||||
fullnameOverride: "qdrant-cluster-manager"
|
||||
|
||||
serviceAccount:
|
||||
# Specifies whether a service account should be created
|
||||
create: true
|
||||
# Automatically mount a ServiceAccount's API credentials?
|
||||
automount: true
|
||||
# Annotations to add to the service account
|
||||
annotations: {}
|
||||
# The name of the service account to use.
|
||||
# If not set and create is true, a name is generated using the fullname template
|
||||
name: ""
|
||||
|
||||
podAnnotations: {}
|
||||
podLabels: {}
|
||||
|
||||
podSecurityContext:
|
||||
runAsNonRoot: true
|
||||
runAsUser: 10001
|
||||
runAsGroup: 20001
|
||||
fsGroup: 30001
|
||||
|
||||
securityContext:
|
||||
capabilities:
|
||||
drop:
|
||||
- ALL
|
||||
readOnlyRootFilesystem: true
|
||||
runAsNonRoot: true
|
||||
runAsUser: 10001
|
||||
runAsGroup: 20001
|
||||
allowPrivilegeEscalation: false
|
||||
seccompProfile:
|
||||
type: RuntimeDefault
|
||||
|
||||
service:
|
||||
type: ClusterIP
|
||||
|
||||
networkPolicy:
|
||||
create: true
|
||||
|
||||
resources: {}
|
||||
# We usually recommend not to specify default resources and to leave this as a conscious
|
||||
# choice for the user. This also increases chances charts run on environments with little
|
||||
# resources, such as Minikube. If you do want to specify resources, uncomment the following
|
||||
# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
|
||||
# limits:
|
||||
# cpu: 100m
|
||||
# memory: 128Mi
|
||||
# requests:
|
||||
# cpu: 100m
|
||||
# memory: 128Mi
|
||||
|
||||
nodeSelector: {}
|
||||
|
||||
tolerations: []
|
||||
|
||||
affinity: {}
|
||||
```
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Logging & Monitoring
|
||||
weight: 4
|
||||
---
|
||||
|
||||
# Configuring Logging & Monitoring in Qdrant Private Cloud
|
||||
|
||||
## Logging
|
||||
|
||||
You can access the logs with kubectl or the Kubernetes log management tool of your choice. For example:
|
||||
|
||||
```bash
|
||||
kubectl -n qdrant-private-cloud logs -l app=qdrant,cluster-id=a7d8d973-0cc5-42de-8d7b-c29d14d24840
|
||||
```
|
||||
|
||||
**Configuring log levels:** You can configure log levels for the databases individually through the QdrantCluster spec. Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantCluster
|
||||
metadata:
|
||||
name: qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
version: "v1.11.3"
|
||||
size: 1
|
||||
resources:
|
||||
cpu: 100m
|
||||
memory: "1Gi"
|
||||
storage: "2Gi"
|
||||
config:
|
||||
log_level: "DEBUG"
|
||||
```
|
||||
|
||||
## Monitoring
|
||||
|
||||
The Qdrant database, and the operator both expose a Prometheus compatible metrics endpoint at `/metrics`. That provides telemetry on the operator and your Qdrant databases.
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Setup Private Cloud
|
||||
weight: 1
|
||||
---
|
||||
|
||||
# Qdrant Private Cloud Setup
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Kubernetes cluster:** To create a Hybrid Cloud Environment, you need a [standard compliant](https://www.cncf.io/training/certification/software-conformance/) Kubernetes cluster. You can run this cluster in any cloud, on-premise or edge environment, with distributions that range from AWS EKS to VMWare vSphere. See [Deployment Platforms](/documentation/hybrid-cloud/platform-deployment-options/) for more information.
|
||||
- **Storage:** For storage, you need to set up the Kubernetes cluster with a Container Storage Interface (CSI) driver that provides block storage. For vertical scaling, the CSI driver needs to support volume expansion. For backups and restores, the driver needs to support CSI snapshots and restores.
|
||||
|
||||
<aside role="status">Network storage systems like NFS or object storage systems such as S3 are not supported.</aside>
|
||||
|
||||
- **Permissions:** To install the Qdrant Kubernetes Operator you need to have `cluster-admin` access in your Kubernetes cluster.
|
||||
- **Locations:** By default, the Qdrant Cloud Agent and Operator pulls Helm charts and container images from `registry.cloud.qdrant.io`.
|
||||
|
||||
> **Note:** You can also mirror these images and charts into your own registry and pull them from there.
|
||||
|
||||
### CLI tools
|
||||
|
||||
During the onboarding, you will need to deploy the Qdrant Kubernetes Operator and Agent using Helm. Make sure you have the following tools installed:
|
||||
|
||||
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
|
||||
* [helm](https://helm.sh/docs/intro/install/)
|
||||
|
||||
You will need to have access to the Kubernetes cluster with `kubectl` and `helm` configured to connect to it. Please refer the documentation of your Kubernetes distribution for more information.
|
||||
|
||||
### Required artifacts
|
||||
|
||||
Container images:
|
||||
|
||||
- `registry.cloud.qdrant.io/qdrant/qdrant`
|
||||
- `registry.cloud.qdrant.io/qdrant/operator`
|
||||
- `registry.cloud.qdrant.io/qdrant/cluster-manager`
|
||||
|
||||
Open Containers Initiative (OCI) Helm charts:
|
||||
|
||||
- `registry.cloud.qdrant.io/qdrant-charts/qdrant-private-cloud`
|
||||
|
||||
### Mirroring images and charts
|
||||
|
||||
To mirror all necessary container images and Helm charts into your own registry, you can either use a replication feature that your registry provides, or you can manually sync the images with [Skopeo](https://github.com/containers/skopeo):
|
||||
|
||||
First login to the source registry:
|
||||
|
||||
```shell
|
||||
skopeo login registry.cloud.qdrant.io
|
||||
```
|
||||
|
||||
Then login to your own registry:
|
||||
|
||||
```shell
|
||||
skopeo login your-registry.example.com
|
||||
```
|
||||
|
||||
To sync all container images:
|
||||
|
||||
```shell
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/qdrant your-registry.example.com/qdrant/qdrant
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/cluster-manager your-registry.example.com/qdrant/cluster-manager
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant/operator your-registry.example.com/qdrant/operator
|
||||
```
|
||||
|
||||
To sync all helm charts:
|
||||
|
||||
```shell
|
||||
skopeo sync --all --src docker --dest docker registry.cloud.qdrant.io/qdrant-charts/qdrant-private-cloud your-registry.example.com/qdrant-charts/qdrant-private-cloud
|
||||
```
|
||||
|
||||
During the installation or upgrade, you will need to adapt the repository information in the Helm chart values. See [Private Cloud Configuration](/documentation/private-cloud/configuration/) for details.
|
||||
|
||||
## Installation and Upgrades
|
||||
|
||||
Once you are onboarded to Qdrant Private Cloud, you will receive credentials to access the Qdrant Cloud Registry. You can use these credentials to install the Qdrant Private Cloud solution using the following commands. You can choose the Kubernetes namespace freely.
|
||||
|
||||
```bash
|
||||
kubectl create namespace qdrant-private-cloud
|
||||
kubectl create secret docker-registry qdrant-registry-creds --docker-server=registry.cloud.qdrant.io --docker-username='your-username' --docker-password='your-password' --namespace qdrant-private-cloud
|
||||
helm registry login 'registry.cloud.qdrant.io' --username 'your-username' --password 'your-password'
|
||||
helm upgrade --install qdrant-private-cloud oci://registry.cloud.qdrant.io/qdrant-charts/qdrant-private-cloud --namespace qdrant-private-cloud --version 0.1.0
|
||||
```
|
||||
|
||||
For a list of available versions consult the [Private Cloud Changelog](/documentation/private-cloud/changelog/).
|
||||
|
||||
Especially ensure, that the default values to reference `StorageClasses` and the corresponding `VolumeSnapshotClass` are set correctly in your environment.
|
||||
|
||||
## Uninstallation
|
||||
|
||||
To uninstall the Qdrant Private Cloud solution, you can use the following command:
|
||||
|
||||
```bash
|
||||
helm uninstall qdrant-private-cloud --namespace qdrant-private-cloud
|
||||
kubectl delete namespace qdrant-private-cloud
|
||||
```
|
||||
@@ -0,0 +1,191 @@
|
||||
---
|
||||
title: Managing a Cluster
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# Managing a Qdrant Cluster
|
||||
|
||||
The most minimal QdrantCluster configuration is:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantCluster
|
||||
metadata:
|
||||
name: qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
version: "v1.11.3"
|
||||
size: 1
|
||||
resources:
|
||||
cpu: 100m
|
||||
memory: "1Gi"
|
||||
storage: "2Gi"
|
||||
```
|
||||
|
||||
The `id` should be unique across all Qdrant clusters in the same namespace, the `name` must follow the above pattern and the `cluster-id` and `customer-id` labels are mandatory.
|
||||
|
||||
There are lots more configuration options to configure scheduling, security, networking, and more. For full details see the [Qdrant Private Cloud API Reference](/documentation/private-cloud/api-reference/).
|
||||
|
||||
## Scaling a Cluster
|
||||
|
||||
To scale a cluster, update the CPU, memory and storage resources in the QdrantCluster spec. The Qdrant operator will automatically adjust the cluster configuration. This operation is highly available on a multi-node cluster with replicated collections.
|
||||
|
||||
<aside role="status">Vertical scaling is only possible if your CSI driver and StorageClass allows volume expansion. Disk storage can not be downscaled.</aside>
|
||||
|
||||
## Upgrading the Qdrant version
|
||||
|
||||
To upgrade the Qdrant version of a database cluster, update the `version` field in the QdrantCluster spec. The Qdrant operator will automatically upgrade the cluster to the new version. The upgrade process is highly available on a multi-node cluster with replicated collections.
|
||||
|
||||
Note, that you should not skip minor versions when upgrading. For example, if you are running version `v1.11.3`, you can upgrade to `v1.11.4` or `v1.12.2`, but not directly to `v1.13.0`.
|
||||
|
||||
## Exposing a Cluster
|
||||
|
||||
By default, a QdrantCluster will be exposed through an internal `ClusterIP` service. To expose the cluster to the outside world, you can create a `NodePort` service, a `LoadBalancer` service or an `Ingress` resource.
|
||||
|
||||
This is an example on how to create a QdrantCluster with a `LoadBalancer` service:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantCluster
|
||||
metadata:
|
||||
name: qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
version: "v1.11.3"
|
||||
size: 1
|
||||
resources:
|
||||
cpu: 100m
|
||||
memory: "1Gi"
|
||||
storage: "2Gi"
|
||||
service:
|
||||
type: LoadBalancer
|
||||
annotations:
|
||||
service.beta.kubernetes.io/aws-load-balancer-type: nlb
|
||||
```
|
||||
|
||||
Especially if you create a LoadBalancer Service, you may need to provide annotations for the loadbalancer configration. Please refer to the documention of your cloud provider for more details.
|
||||
|
||||
Examples:
|
||||
|
||||
* [AWS EKS LoadBalancer annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/)
|
||||
* [Azure AKS Public LoadBalancer annotations](https://learn.microsoft.com/en-us/azure/aks/load-balancer-standard)
|
||||
* [Azure AKS Internal LoadBalancer annotations](https://learn.microsoft.com/en-us/azure/aks/internal-lb)
|
||||
* [GCP GKE LoadBalancer annotations](https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer-parameters)
|
||||
|
||||
## Authentication and Authorization
|
||||
|
||||
Authentication information is provided by Kubernetes secrets.
|
||||
|
||||
One way to create a secret is with kubectl:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic qdrant-api-key --from-literal=api-key=your-secret-api-key --from-literal=read-only-api-key=your-secret-read-only-api-key --namespace qdrant-private-cloud
|
||||
```
|
||||
|
||||
The resulting secret will look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
api-key: ...
|
||||
read-only-api-key: ...
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: qdrant-api-key
|
||||
namespace: qdrant-private-cloud
|
||||
type: kubernetes.io/tls
|
||||
```
|
||||
|
||||
You can reference the secret in the QdrantCluster spec:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantCluster
|
||||
metadata:
|
||||
name: qdrant-a7d8d973-0cc5-42de-8d7b-c29d14d24840
|
||||
labels:
|
||||
cluster-id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
customer-id: "acme-industries"
|
||||
spec:
|
||||
id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
version: "v1.11.3"
|
||||
size: 1
|
||||
resources:
|
||||
cpu: 100m
|
||||
memory: "1Gi"
|
||||
storage: "2Gi"
|
||||
config:
|
||||
service:
|
||||
api_key:
|
||||
secretKeyRef:
|
||||
name: qdrant-api-key
|
||||
key: api-key
|
||||
read_only_api_key:
|
||||
secretKeyRef:
|
||||
name: qdrant-api-key
|
||||
key: read-only-api-key
|
||||
jwt_rbac: true
|
||||
```
|
||||
|
||||
If you set the `jwt_rbac` flag, you will also be able to create granular [JWT tokens for role based access control](/documentation/guides/security/#granular-access-control-with-jwt).
|
||||
|
||||
### Configuring TLS
|
||||
|
||||
If you want to configure TLS for accessing your Qdrant database, there are two options:
|
||||
|
||||
* You can offload TLS at the ingress or loadbalancer level.
|
||||
* You can configure TLS directly in the Qdrant database.
|
||||
|
||||
If you want to configure TLS directly in the Qdrant database, you can provide this as a secret.
|
||||
|
||||
To create such a secret, you can use `kubectl`:
|
||||
|
||||
```shell
|
||||
kubectl create secret tls qdrant-tls --cert=mydomain.com.crt --key=mydomain.com.key --namespace the-qdrant-namespace
|
||||
```
|
||||
|
||||
The resulting secret will look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
tls.crt: ...
|
||||
tls.key: ...
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: qdrant-tls
|
||||
namespace: the-qdrant-namespace
|
||||
type: kubernetes.io/tls
|
||||
```
|
||||
You can reference the secret in the QdrantCluster spec:
|
||||
|
||||
```yaml
|
||||
apiVersion: qdrant.io/v1
|
||||
kind: QdrantCluster
|
||||
metadata:
|
||||
name: test-cluster
|
||||
spec:
|
||||
id: "a7d8d973-0cc5-42de-8d7b-c29d14d24840"
|
||||
version: "v1.11.3"
|
||||
size: 1
|
||||
resources:
|
||||
cpu: 100m
|
||||
memory: "1Gi"
|
||||
storage: "2Gi"
|
||||
config:
|
||||
tls:
|
||||
cert:
|
||||
secretKeyRef:
|
||||
name: qdrant-tls
|
||||
key: tls.crt
|
||||
key:
|
||||
secretKeyRef:
|
||||
name: qdrant-tls
|
||||
key: tls.key
|
||||
```
|
||||
@@ -49,4 +49,6 @@ Use these endpoints to manage your cluster API keys.
|
||||
- **Delete API Key**: Revoke access by deleting a specific API key.
|
||||
- **Update API Key**: Modify attributes of an existing API key.
|
||||
|
||||
## Terraform Provider
|
||||
|
||||
Qdrant Cloud also provides a Terraform provider to manage your Qdrant Cloud resources. The provider is available on the official [Terraform Registry](https://registry.terraform.io/providers/qdrant/qdrant-cloud).
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Support
|
||||
weight: 10
|
||||
aliases:
|
||||
- /documentation/cloud/support/
|
||||
---
|
||||
|
||||
# Qdrant Cloud Support and Troubleshooting
|
||||
|
||||
## Community Support
|
||||
|
||||
All Qdrant Cloud users are welcome to join our [Discord community](https://qdrant.to/discord/).
|
||||
|
||||
|
||||
|
||||
## Qdrant Cloud Support
|
||||
|
||||
Paying customers have access to our Support team. Links to the support portal are available in the Qdrant Cloud Console.
|
||||
|
||||
|
||||
|
||||
When creating a support ticket, please provide as much information as possible to help us understand your issue.
|
||||
|
||||
This includes but is not limited to:
|
||||
|
||||
* The ID of your Qdrant Cloud cluster, if it's not filled out by the UI automatically. You can find the ID on your cluster's detail page.
|
||||
* Which collection(s) are affected
|
||||
* Code examples on how you are interacting with the Qdrant API
|
||||
* Logs or error messages from your application
|
||||
* Relevant telemetry from your application
|
||||
|
||||
You can also choose a severity, when creating a ticket. This helps us prioritize your issue correctly. Please refer to the [Qdrant Cloud SLA](https://qdrant.to/sla/) for a definition of these severity levels and their corresponding response time SLA for your respective [support tier](/documentation/cloud/enterprise/).
|
||||
|
||||
If you are opening a ticket for a Hybrid Cloud or Private Cloud environment, we may ask for additional information about your environment, such as detailed logs of the Qdrant databases or operator and the state of your Kubernetes cluster.
|
||||
|
||||
We have prepared a support bundle script that can help you with collecting all this information. A support bundle will not contain any user data or sensitive information like api keys. It will contain the names and configuration of Qdrant collections though. For more information see the [support bundle documentation](https://github.com/qdrant/qdrant-cloud-support-tools/tree/main/hybrid-cloud-support-bundle).
|
||||
Reference in New Issue
Block a user