mirror of
https://github.com/qdrant/landing_page.git
synced 2026-09-28 23:48:31 +02:00
Improvement to Cloud and Hybrid Cloud docs
This significantly improves our cloud and hybrid cloud docs: * Adds screenshots * Better structure * More information about payments, including stripe and azure marketplace * Better cluster creation docs * Account setup and invitation docs * Monitoring docs * Cluster upgrade docs * Support docs * Removed duplications
This commit is contained in:
Bastian Hofmann
@@ -9,11 +9,11 @@ Seamlessly deploy and manage your vector database across diverse environments, e
|
||||
|
||||
[Qdrant Hybrid Cloud](/hybrid-cloud/) integrates Kubernetes clusters from any setting - cloud, on-premises, or edge - into a unified, enterprise-grade managed service.
|
||||
|
||||
You can use [Qdrant Cloud's UI](/documentation/cloud/create-cluster/) to create and manage your database clusters, while they still remain within your infrastructure. **All Qdrant databases will operate solely within your network, using your storage and compute resources.**
|
||||
You can use [Qdrant Cloud's UI](/documentation/cloud/create-cluster/) to create and manage your database clusters, while they still remain within your infrastructure. **All Qdrant databases will operate solely within your network, using your storage and compute resources. All user data will stay securely within your environment and won't be accessible by the Qdrant Cloud platform, or anyone else outside your organization.**
|
||||
|
||||
Qdrant Hybrid Cloud ensures data privacy, deployment flexibility, low latency, and delivers cost savings, elevating standards for vector search and AI applications.
|
||||
|
||||
**How it works:** When you onboard a Kubernetes cluster as a Hybrid Cloud Environment, you can deploy the Qdrant Kubernetes Operator and Cloud Agent into this cluster. These will manage Qdrant databases within your Kubernetes cluster and establish an outgoing connection to Qdrant Cloud at `cloud.qdrant.io` on port `443`. You can then benefit from the same cloud management features and transport telemetry as is available with any managed Qdrant Cloud cluster.
|
||||
**How it works:** Qdrant Hybrid Cloud relies on Kubernetes and works with any standard compliant Kubernetes distribution. When you onboard a Kubernetes cluster as a Hybrid Cloud Environment, you can deploy the Qdrant Kubernetes Operator and Cloud Agent into this cluster. These will manage Qdrant databases within your Kubernetes cluster and establish an outgoing connection to Qdrant Cloud to transport telemetry and receive management instructions. You can then benefit from the same cloud management features and transport telemetry as is available with any managed Qdrant Cloud cluster.
|
||||
|
||||
<aside role="status">Qdrant Cloud does not connect to the API of your Kubernetes cluster, cloud provider, or any other platform APIs.</aside>
|
||||
|
||||
@@ -21,17 +21,16 @@ Qdrant Hybrid Cloud ensures data privacy, deployment flexibility, low latency, a
|
||||
|
||||
## Hybrid Cloud architecture
|
||||
|
||||
The Hybrid Cloud onboarding will install a Kubernetes Operator and Cloud Agent into your Kubernetes cluster.
|
||||
|
||||
The Cloud Agent will establish an outgoing connection to `cloud.qdrant.io` on port `443` to transport telemetry and receive management instructions. It will also interact with the Kubernetes API through a ServiceAccount to create, read, update and delete the necessary Qdrant CRs (Custom Resources) based on the configuration setup in the Qdrant Cloud Console.
|
||||
|
||||
The Qdrant Kubernetes Operator will manage the Qdrant databases within your Kubernetes cluster. Based on the Qdrant CRs, it will interact with the Kubernetes API through a ServiceAccount to create and manage the necessary resources to deploy and run Qdrant databases, such as Pods, Services, ConfigMaps, and Secrets.
|
||||
|
||||
Both component's access is limited to the Kubernetes namespace that you chose during the onboarding process.
|
||||
|
||||
After the initial onboarding, the lifecycle of these components will be controlled by the Qdrant Cloud platform through a built-in Helm controller.
|
||||
|
||||
You don't need to expose your Kubernetes Cluster to the Qdrant Cloud platform, you don't need to open any ports for incoming traffic and you don't need to provide any Kubernetes or cloud provider credentials to the Qdrant Cloud platform.
|
||||
|
||||
|
||||
|
||||
## Upcoming roadmap items
|
||||
|
||||
We plan to introduce the following configuration options directly in the Qdrant Cloud Console in the future. If you need any of them beforehand, please contact our Support team.
|
||||
|
||||
* Node selectors
|
||||
* Tolerations
|
||||
* Affinities and anti-affinities
|
||||
* Service types and annotations
|
||||
* Ingresses
|
||||
* Network policies
|
||||
* Storage classes
|
||||
* Volume snapshot classes
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
title: Cluster creation
|
||||
weight: 2
|
||||
---
|
||||
|
||||
# Creating a Qdrant cluster in Hybrid Cloud
|
||||
|
||||
Once you have created a Hybrid Cloud Environment, you can create a Qdrant cluster in that enviroment. Use the same process to [Create a cluster](/documentation/cloud/create-cluster/). Make sure to select your Hybrid Cloud Environment as the target.
|
||||
|
||||
Note that in the "Kubernetes Configuration" section you can additionally configure:
|
||||
|
||||
* Node selectors for the Qdrant database pods
|
||||
* Toleration for the Qdrant database pods
|
||||
* Additional labels for the Qdrant database pods
|
||||
* A service type and annotations for the Qdrant database service
|
||||
|
||||
These settings can also be changed after the cluster is created on the cluster detail page.
|
||||
|
||||
### Authentication at your Qdrant clusters
|
||||
|
||||
In Hybrid Cloud the authentication information is provided with Kubernetes secrets.
|
||||
|
||||
You can configure authentication for your Qdrant clusters in the "Configuration" section of the Qdrant Cluster detail page. There you can configure the Kubernetes secret name and key to be used as an API key and/or read-only API key.
|
||||
|
||||
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 --namespace the-qdrant-namespace
|
||||
```
|
||||
|
||||
The resulting secret will look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
api-key: ...
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: qdrant-api-key
|
||||
namespace: the-qdrant-namespace
|
||||
type: kubernetes.io/tls
|
||||
```
|
||||
|
||||
With this command the secret name would be `qdrant-api-key` and the key would be `api-key`.
|
||||
|
||||
If you want to retrieve the secret again, you can also use `kubectl`:
|
||||
|
||||
```shell
|
||||
kubectl get secret qdrant-api-key -o jsonpath="{.data.api-key}" --namespace the-qdrant-namespace | base64 --decode
|
||||
```
|
||||
|
||||
### Exposing Qdrant clusters to your client applications
|
||||
|
||||
You can expose your Qdrant clusters to your client applications using Kubernetes services and ingresses. By default, a `ClusterIP` service is created for each Qdrant cluster.
|
||||
|
||||
Within your Kubernetes cluster, you can access the Qdrant cluster using the service name and port:
|
||||
|
||||
```
|
||||
http://qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24.qdrant-namespace.svc:6333
|
||||
```
|
||||
|
||||
This endpoint is also visible on the cluster detail page.
|
||||
|
||||
If you want to access the database from your local developer machine, you can use `kubectl port-forward` to forward the service port to your local machine:
|
||||
|
||||
```
|
||||
kubectl --namespace your-qdrant-namespace port-forward service/qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24 6333:6333
|
||||
```
|
||||
|
||||
You can also expose the database outside the Kubernetes cluster with a `LoadBalancer` (if supported in your Kubernetes environment) or `NodePort` service or an ingress.
|
||||
|
||||
The service type and necessary annotations can be configured in the "Kubernetes Configuration" section during cluster creation, or on the cluster detail page.
|
||||
|
||||
Especially if you create a LoadBalancer Service, you may need to provider 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)
|
||||
|
||||
You could also create a Loadbalancer service manually like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24-lb
|
||||
namespace: qdrant-namespace
|
||||
spec:
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- name: http
|
||||
port: 6333
|
||||
- name: grpc
|
||||
port: 6334
|
||||
selector:
|
||||
app: qdrant
|
||||
cluster-id: 9a9f48c7-bb90-4fb2-816f-418a46a74b24
|
||||
```
|
||||
|
||||
An ingress could look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24
|
||||
namespace: qdrant-namespace
|
||||
spec:
|
||||
rules:
|
||||
- host: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24.your-domain.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24
|
||||
port:
|
||||
number: 6333
|
||||
```
|
||||
|
||||
Please refer to the Kubernetes, ingress controller and cloud provider documention for more details.
|
||||
|
||||
If you expose the database with such a way, you will be able to see this also reflected as an endpoint on the cluster detail page. And will see the Qdrant database dashboard link pointing to it.
|
||||
|
||||
### Configuring TLS
|
||||
|
||||
If you want to configure TLS for accessing your Qdrant database in Hybrid Cloud, 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 a secret with the TLS certificate and key in the "Configuration" section of the Qdrant Cluster detail page. There you can configure the Kubernetes secret name and key to be used as the certificate and key.
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
With this command the secret name to enter into the UI would be `qdrant-tls` and the keys would be `tls.crt` and `tls.key`.
|
||||
@@ -69,10 +69,9 @@ You can also configure the StorageClass and VolumeSnapshotClass to use for the Q
|
||||
|
||||
5. (Optional) If you have special requirements for any of the following, activate the **Show advanced configuration** option:
|
||||
|
||||
- Proxy server
|
||||
- If you require to use a proxy to connect from your infrastructure to the Qdrant Cloud API, you can specify the proxy URL, credentials and cetificates.
|
||||
- Container registry URL for Qdrant Operator and Agent images. The default is <https://registry.cloud.qdrant.io/qdrant/>.
|
||||
- Helm chart repository URL for the Qdrant Operator and Agent. The default is <oci://registry.cloud.qdrant.io/qdrant-charts>.
|
||||
- CA certificate
|
||||
- Log level for the operator and agent
|
||||
|
||||
6. Once complete, click **Create**.
|
||||
@@ -83,168 +82,14 @@ You can also configure the StorageClass and VolumeSnapshotClass to use for the Q
|
||||
|
||||
After creating your Hybrid Cloud, select **Generate Installation Command** to generate a script that you can run in your Kubernetes cluster which will perform the initial installation of the Kubernetes operator and agent. It will:
|
||||
|
||||
- Create the Kubernetes namespace
|
||||
- Create the Kubernetes namespace, if not present
|
||||
- Set up the necessary secrets with credentials to access the Qdrant container registry and the Qdrant Cloud API.
|
||||
- Sign in to the Helm registry at `registry.cloud.qdrant.io`
|
||||
- Install the Qdrant cloud agent and Kubernetes operator chart
|
||||
|
||||
You need this command only for the initial installation. After that, you can update the agent and operator using the Qdrant Cloud Console.
|
||||
|
||||
> **Note:** If you generate the installation command a second time, it will re-generate the included secrets and you will have to apply the command again to update them.
|
||||
|
||||
## Creating a Qdrant cluster
|
||||
|
||||
Once you have created a Hybrid Cloud Environment, you can create a Qdrant cluster in that enviroment. Use the same process to [Create a cluster](/documentation/cloud/create-cluster/). Make sure to select your Hybrid Cloud Environment as the target.
|
||||
|
||||
Note that in the "Kubernetes Configuration" section you can configure:
|
||||
|
||||
* Node selectors for the Qdrant database pods
|
||||
* Toleration for the Qdrant database pods
|
||||
* Additional labels for the Qdrant database pods
|
||||
* A service type and annotations for the Qdrant database service
|
||||
|
||||
These settings can also be changed after the cluster is created on the cluster detail page.
|
||||
|
||||
### Authentication at your Qdrant clusters
|
||||
|
||||
In Hybrid Cloud the authentication information is provided with Kubernetes secrets.
|
||||
|
||||
You can configure authentication for your Qdrant clusters in the "Configuration" section of the Qdrant Cluster detail page. There you can configure the Kubernetes secret name and key to be used as an API key and/or read-only API key.
|
||||
|
||||
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 --namespace the-qdrant-namespace
|
||||
```
|
||||
|
||||
The resulting secret will look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
api-key: ...
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: qdrant-api-key
|
||||
namespace: the-qdrant-namespace
|
||||
type: kubernetes.io/tls
|
||||
```
|
||||
|
||||
With this command the secret name would be `qdrant-api-key` and the key would be `api-key`.
|
||||
|
||||
If you want to retrieve the secret again, you can also use `kubectl`:
|
||||
|
||||
```shell
|
||||
kubectl get secret qdrant-api-key -o jsonpath="{.data.api-key}" --namespace the-qdrant-namespace | base64 --decode
|
||||
```
|
||||
|
||||
### Exposing Qdrant clusters to your client applications
|
||||
|
||||
You can expose your Qdrant clusters to your client applications using Kubernetes services and ingresses. By default, a `ClusterIP` service is created for each Qdrant cluster.
|
||||
|
||||
Within your Kubernetes cluster, you can access the Qdrant cluster using the service name and port:
|
||||
|
||||
```
|
||||
http://qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24.qdrant-namespace.svc:6333
|
||||
```
|
||||
|
||||
This endpoint is also visible on the cluster detail page.
|
||||
|
||||
If you want to access the database from your local developer machine, you can use `kubectl port-forward` to forward the service port to your local machine:
|
||||
|
||||
```
|
||||
kubectl --namespace your-qdrant-namespace port-forward service/qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24 6333:6333
|
||||
```
|
||||
|
||||
You can also expose the database outside the Kubernetes cluster with a `LoadBalancer` (if supported in your Kubernetes environment) or `NodePort` service or an ingress.
|
||||
|
||||
The service type and necessary annotations can be configured in the "Kubernetes Configuration" section during cluster creation, or on the cluster detail page.
|
||||
|
||||
Especially if you create a LoadBalancer Service, you may need to provider 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)
|
||||
|
||||
You could also create a Loadbalancer service manually like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24-lb
|
||||
namespace: qdrant-namespace
|
||||
spec:
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- name: http
|
||||
port: 6333
|
||||
- name: grpc
|
||||
port: 6334
|
||||
selector:
|
||||
app: qdrant
|
||||
cluster-id: 9a9f48c7-bb90-4fb2-816f-418a46a74b24
|
||||
```
|
||||
|
||||
An ingress could look like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24
|
||||
namespace: qdrant-namespace
|
||||
spec:
|
||||
rules:
|
||||
- host: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24.your-domain.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: qdrant-9a9f48c7-bb90-4fb2-816f-418a46a74b24
|
||||
port:
|
||||
number: 6333
|
||||
```
|
||||
|
||||
Please refer to the Kubernetes, ingress controller and cloud provider documention for more details.
|
||||
|
||||
If you expose the database with such a way, you will be able to see this also reflected as an endpoint on the cluster detail page. And will see the Qdrant database dashboard link pointing to it.
|
||||
|
||||
### Configuring TLS
|
||||
|
||||
If you want to configure TLS for accessing your Qdrant database in Hybrid Cloud, 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 a secret with the TLS certificate and key in the "Configuration" section of the Qdrant Cluster detail page. There you can configure the Kubernetes secret name and key to be used as the certificate and key.
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
With this command the secret name to enter into the UI would be `qdrant-tls` and the keys would be `tls.crt` and `tls.key`.
|
||||
> **Note:** If you generate the installation command a second time, it will re-generate the included secrets, and you will have to apply the command again to update them.
|
||||
|
||||
## Deleting a Hybrid Cloud Environment
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Networking, logging & monitoring
|
||||
weight: 3
|
||||
weight: 4
|
||||
---
|
||||
# Networking, logging & monitoring
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Advanced Qdrant Operator configuration
|
||||
weight: 2
|
||||
weight: 3
|
||||
---
|
||||
|
||||
# Advanced Qdrant Operator configuration
|
||||
@@ -21,14 +21,6 @@ backOff:
|
||||
minDelay: 5
|
||||
maxDelay: 300
|
||||
increment: 5
|
||||
# Cluster-manager configuration for a Qdrant cluster (experimental)
|
||||
clusterManager:
|
||||
image:
|
||||
repository: qdrant/qdrant-cloud-cluster-manager
|
||||
tag: 0.1.2
|
||||
pullInterval: 10
|
||||
logSize: 10
|
||||
debug: false
|
||||
# node_selector: {}
|
||||
# tolerations: []
|
||||
# Default ingress configuration for a Qdrant cluster
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Deployment platforms
|
||||
weight: 4
|
||||
weight: 5
|
||||
---
|
||||
|
||||
# Platform Deployment Options
|
||||
|
||||
Reference in New Issue
Block a user