Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di un database di vettori Qdrant su GKE

Autopilot Standard

Questa guida mostra come eseguire il deployment di un cluster di database vettoriale Qdrant su Google Kubernetes Engine (GKE).

I database vettoriali sono spazi di archiviazione dei dati progettati specificamente per gestire e cercare grandi raccolte di vettori ad alta dimensione. Questi vettori rappresentano dati come testo, immagini, audio, video o qualsiasi dato che può essere codificato numericamente. A differenza dei database tradizionali che si basano su corrispondenze esatte, i database vettoriali sono specializzati nella ricerca di elementi simili o nell'identificazione di pattern all'interno di set di dati di grandi dimensioni. Queste caratteristiche rendono Qdrant una scelta adatta a una serie di applicazioni, tra cui la corrispondenza basata su reti neurali o semantica, la ricerca per sfaccettature e altro ancora. Qdrant non funziona solo come database vettoriale, ma anche come motore di ricerca di somiglianze vettoriali.

Questo tutorial è destinato ad amministratori e architetti di piattaforme cloud, ingegneri ML e professionisti MLOps (DevOps) interessati al deployment di cluster di database Qdrant su GKE.

Vantaggi

Qdrant offre i seguenti vantaggi:

Ampia gamma di librerie per vari linguaggi di programmazione e API aperte da integrare con altri servizi.
Scalabilità orizzontale e supporto per sharding e replica che semplificano la scalabilità e l'alta disponibilità.
Supporto di container e Kubernetes che consente il deployment e la gestione in ambienti cloud-native moderni.
Payload flessibili con filtri avanzati per personalizzare con precisione i criteri di ricerca.
Diverse opzioni di quantizzazione e altre ottimizzazioni per ridurre i costi dell'infrastruttura e migliorare il rendimento.

Obiettivi

In questo tutorial imparerai a:

Pianifica ed esegui il deployment dell'infrastruttura GKE per Qdrant.
Esegui il deployment dell'operatore StatefulHA per garantire l'alta disponibilità di Qdrant.
Esegui il deployment e configura il cluster Qdrant.
Carica un set di dati demo ed esegui una semplice query di ricerca.
Raccogli metriche ed esegui una dashboard.

Architettura di deployment

Questa architettura configura un cluster GKE scalabile e tollerante agli errori per Qdrant in più zone di disponibilità, garantendo uptime e disponibilità con aggiornamenti continui e interruzioni minime. È incluso l'utilizzo dell'operatore StatefulHA per una gestione efficiente del failover. Per maggiori informazioni, consulta Cluster regionali.

Diagramma dell'architettura

Il seguente diagramma mostra un cluster Qdrant in esecuzione su più nodi e zone in un cluster GKE:

Architettura di deployment di Qdrant

In questa architettura, StatefulSet Qdrant viene distribuito su tre nodi in tre zone diverse.

Puoi controllare la modalità di distribuzione dei pod nei nodi da parte di GKE configurando le regole di affinità dei pod e i vincoli di distribuzione della topologia nel file dei valori del grafico Helm.
Se una zona non funziona, GKE riprogramma i pod su nuovi nodi in base alla configurazione consigliata.

Per la persistenza dei dati, l'architettura di questo tutorial presenta le seguenti caratteristiche:

Utilizza dischi SSD regionali (regional-pd StorageClass personalizzata) per rendere persistenti i dati. Consigliamo i dischi SSD regionali per i database grazie alla loro bassa latenza e alle IOPS elevate.
Tutti i dati del disco vengono replicati tra le zone primaria e secondaria nella regione, aumentando la tolleranza ai potenziali errori di zona.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prima di iniziare

In questo tutorial utilizzerai Cloud Shell per eseguire i comandi. Cloud Shell è un ambiente shell per la gestione delle risorse ospitate su Google Cloud. È preinstallato con gli strumenti a riga di comando Google Cloud CLI, kubectl, Helm e Terraform. Se non utilizzi Cloud Shell, devi installare Google Cloud CLI.

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Install the Google Cloud CLI.

Nota:se hai installato gcloud CLI in precedenza, assicurati di avere l'ultima versione eseguendo gcloud components update.

Se utilizzi un provider di identità (IdP) esterno, devi prima accedere alla gcloud CLI con la tua identità federata.

Per inizializzare gcloud CLI, esegui questo comando:

gcloud init

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Verify that billing is enabled for your Google Cloud project.

Enable the Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE APIs:

gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

Install the Google Cloud CLI.

Nota:se hai installato gcloud CLI in precedenza, assicurati di avere l'ultima versione eseguendo gcloud components update.

Se utilizzi un provider di identità (IdP) esterno, devi prima accedere alla gcloud CLI con la tua identità federata.

Per inizializzare gcloud CLI, esegui questo comando:

gcloud init

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Verify that billing is enabled for your Google Cloud project.

Enable the Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE APIs:

gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/storage.objectViewer, roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
```
Replace the following:
- PROJECT_ID: your project ID.
- USER_IDENTIFIER: the identifier for your user account—for example, [email protected].
- ROLE: the IAM role that you grant to your user account.

Configura l'ambiente

Per configurare l'ambiente con Cloud Shell:

Imposta le variabili di ambiente per il progetto, la regione e un prefisso della risorsa del cluster Kubernetes:

Ai fini di questo tutorial, utilizza la regione us-central1 per creare le risorse di deployment.
```
export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=qdrant
export REGION=us-central1
```
- Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

Controlla la versione di Helm:

helm version

Aggiorna la versione se è precedente alla 3.13:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Clona il repository del codice campione da GitHub:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

Vai alla directory qdrant per iniziare a creare risorse di deployment:
```
cd kubernetes-engine-samples/databases/qdrant
```

Crea l'infrastruttura del cluster

Questa sezione prevede l'esecuzione di uno script Terraform per creare un cluster GKE regionale privato e a disponibilità elevata per eseguire il deployment del database Qdrant.

Puoi scegliere di eseguire il deployment di Qdrant utilizzando un cluster standard o Autopilot. Ognuno ha i suoi vantaggi e modelli di determinazione dei prezzi diversi.

Autopilot

Il seguente diagramma mostra un cluster GKE regionale Autopilot di cui è stato eseguito il deployment in tre zone diverse.

Cluster GKE Autopilot

Per eseguire il deployment dell'infrastruttura del cluster, esegui questi comandi in Cloud Shell:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Le seguenti variabili vengono sostituite in fase di runtime:

GOOGLE_OAUTH_ACCESS_TOKEN: sostituito da un token di accesso recuperato dal comando gcloud auth print-access-token per autenticare le interazioni con varie API Google Cloud
PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX sono le variabili di ambiente definite nella sezione Configura l'ambiente e assegnate alle nuove variabili pertinenti per il cluster Autopilot che stai creando.

Quando richiesto, digita yes.

L'output è simile al seguente:

...
Apply complete! Resources: 9 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials qdrant-cluster --region us-central1"

Terraform crea le seguenti risorse:

Una rete VPC personalizzata e una subnet privata per i nodi Kubernetes.
Un router Cloud per accedere a internet tramite Network Address Translation (NAT).
Un cluster GKE privato nella regione us-central1.
Un ServiceAccount con autorizzazioni di logging e monitoraggio per il cluster.
Configurazione di Google Cloud Managed Service per Prometheus per il monitoraggio e gli avvisi dei cluster.

Standard

Il seguente diagramma mostra un cluster GKE regionale privato Standard di cui è stato eseguito il deployment in tre zone diverse.

Cluster GKE Standard

Per eseguire il deployment dell'infrastruttura del cluster, esegui questi comandi in Cloud Shell:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Le seguenti variabili vengono sostituite in fase di runtime:

GOOGLE_OAUTH_ACCESS_TOKEN viene sostituito da un token di accesso recuperato dal comando gcloud auth print-access-token per autenticare le interazioni con varie API Google Cloud.
PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX sono le variabili di ambiente definite nella sezione Configura l'ambiente e assegnate alle nuove variabili pertinenti per il cluster Standard che stai creando.

Quando richiesto, digita yes. Potrebbero essere necessari diversi minuti prima che questi comandi vengano completati e che il cluster mostri lo stato Pronto.

L'output è simile al seguente:

...
Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials qdrant-cluster --region us-central1"

Terraform crea le seguenti risorse:

Una rete VPC personalizzata e una subnet privata per i nodi Kubernetes.
Un router Cloud per accedere a internet tramite Network Address Translation (NAT).
Un cluster GKE privato nella regione us-central1 con la scalabilità automatica abilitata (da uno a due nodi per zona).
Un ServiceAccount con autorizzazioni di logging e monitoraggio per il cluster.
Configurazione di Google Cloud Managed Service per Prometheus per il monitoraggio e gli avvisi dei cluster.

Connettiti al cluster

Configura kubectl per recuperare le credenziali e comunicare con il nuovo cluster GKE:

gcloud container clusters get-credentials \
    ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

Esegui il deployment del database Qdrant nel cluster

In questo tutorial, esegui il deployment del database Qdrant (in modalità distribuita) e dell'operatore Stateful HA nel cluster GKE utilizzando il grafico Helm.

Il deployment crea un cluster GKE con la seguente configurazione:

Tre repliche dei nodi Qdrant.
Le tolleranze, le affinità dei nodi e i vincoli di distribuzione della topologia sono configurati per garantire una distribuzione corretta tra i nodi Kubernetes. Sfrutta i pool di nodi e le diverse zone di disponibilità.
Viene eseguito il provisioning di un volume RePD con il tipo di disco SSD per l'archiviazione dei dati.
Un operatore HA stateful viene utilizzato per gestire i processi di failover e garantire l'alta disponibilità. Uno StatefulSet è un controller Kubernetes che mantiene un'identità univoca permanente per ciascuno dei suoi pod.
Per l'autenticazione, il database crea un secret Kubernetes contenente la chiave API.

Per utilizzare il grafico Helm per eseguire il deployment del database Qdrant:

Attiva il componente aggiuntivo StatefulHA:
Autopilot
GKE abilita automaticamente il componente aggiuntivo StatefulHA al momento della creazione del cluster.
Standard
Esegui questo comando:
```
gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --update-addons=StatefulHA=ENABLED
```
Il completamento di questo comando e la visualizzazione dello stato pronto del cluster potrebbero richiedere 15 minuti.
Aggiungi il repository del grafico Helm del database Qdrant prima di poterlo eseguire il deployment sul tuo cluster GKE:
```
helm repo add qdrant https://qdrant.github.io/qdrant-helm
```
Crea lo spazio dei nomi qdrant per il database:
```
kubectl create ns qdrant
```

Applica il manifest per creare un disco SSD permanente regionale StorageClass:

kubectl apply -n qdrant -f manifests/01-regional-pd/regional-pd.yaml

Il manifest regional-pd.yaml descrive il disco SSD permanente StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
allowVolumeExpansion: true
metadata:
  name: ha-regional
parameters:
  replication-type: regional-pd
  type: pd-ssd
  availability-class: regional-hard-failover
provisioner: pd.csi.storage.gke.io
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Esegui il deployment di un configmap Kubernetes con una configurazione sidecar metrics e un cluster Qdrant utilizzando Helm:

kubectl apply -n qdrant -f manifests/03-prometheus-metrics/metrics-cm.yaml
helm install qdrant-database qdrant/qdrant -n qdrant \
-f manifests/02-values-file/values.yaml

Il manifest metrics-cm.yaml descrive il sidecar metrics ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  default.conf.template: |
    server {
      listen 80;
      location / {
        proxy_pass http://localhost:6333/metrics;
        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header api-key ${QDRANT_APIKEY};
        proxy_set_header X-Forwarded-For $remote_addr;
      }
    }

Il manifest values.yaml descrive la configurazione del cluster Qdrant :

replicaCount: 3

config:
  service:
    enable_tls: false
  cluster:
    enabled: true
  storage:
    optimizers:
      deleted_threshold: 0.5
      vacuum_min_vector_number: 1500
      default_segment_number: 2
      max_segment_size_kb: null
      memmap_threshold_kb: null
      indexing_threshold_kb: 25000
      flush_interval_sec: 5
      max_optimization_threads: 1

livenessProbe:
  enabled: true
  initialDelaySeconds: 60

resources:
  limits:
    cpu: "2"
    memory: 4Gi
  requests:
    cpu: "1"
    memory: 4Gi

tolerations:
  - key: "app.stateful/component"
    operator: "Equal"
    value: "qdrant"
    effect: NoSchedule

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: "app.stateful/component"
          operator: In
          values:
          - "qdrant"

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app.kubernetes.io/name: qdrant
        app.kubernetes.io/instance: qdrant

podDisruptionBudget:
  enabled: true
  maxUnavailable: 1

persistence:
  accessModes: ["ReadWriteOnce"]
  size: 10Gi
  storageClassName: ha-regional

apiKey: true

sidecarContainers:
  - name: metrics
    image: nginx:1.28
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
    - containerPort: 80
    env:
    - name: QDRANT_APIKEY 
      valueFrom:
        secretKeyRef:
          name: qdrant-database-apikey          
          key: api-key
    volumeMounts:
        - name: nginx-conf
          mountPath: /etc/nginx/templates/default.conf.template
          subPath: default.conf.template
          readOnly: true
additionalVolumes:
  - name: nginx-conf
    configMap:
      name: nginx-conf
      items:
        - key: default.conf.template
          path: default.conf.template

Questa configurazione attiva la modalità cluster, consentendoti di configurare un cluster Qdrant distribuito e a disponibilità elevata.

Aggiungi un'etichetta al set con stato Qdrant:

kubectl label statefulset qdrant-database examples.ai.gke.io/source=qdrant-guide -n qdrant

Esegui il deployment di un bilanciatore del carico interno per accedere al database Qdrant in esecuzione nello stesso VPC del cluster GKE:

kubectl apply -n qdrant -f manifests/02-values-file/ilb.yaml

Il manifest ilb.yaml descrive il servizio LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  annotations:
    #cloud.google.com/neg: '{"ingress": true}'
    networking.gke.io/load-balancer-type: "Internal"
  labels:
    app.kubernetes.io/name: qdrant
  name: qdrant-ilb
spec:
  ports:
  - name: http
    port: 6333
    protocol: TCP
    targetPort: 6333
  - name: grpc
    port: 6334
    protocol: TCP
    targetPort: 6334
  selector:
    app: qdrant
    app.kubernetes.io/instance: qdrant-database
  type: LoadBalancer

Controlla lo stato del deployment:

helm ls -n qdrant

Se il deployment del database qdrant è riuscito, l'output è simile al seguente:

NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
qdrant-database  qdrant          1               2024-02-06 20:21:15.737307567 +0000 UTC deployed        qdrant-0.7.6    v1.7.4

Attendi che GKE avvii i carichi di lavoro richiesti:

kubectl wait pods -l app.kubernetes.io/instance=qdrant-database --for condition=Ready --timeout=300s -n qdrant

Il completamento di questo comando potrebbe richiedere alcuni minuti.

Una volta avviati i workload da GKE, verifica che GKE abbia creato i workload Qdrant:
```
kubectl get pod,svc,statefulset,pdb,secret -n qdrant
```
Avvia la risorsa HighAvailabilityApplication (HAA) per Qdrant:
```
kubectl apply -n qdrant -f manifests/01-regional-pd/ha-app.yaml
```
Il file manifest ha-app.yaml descrive la risorsa HighAvailabilityApplication:
```
kind: HighAvailabilityApplication
apiVersion: ha.gke.io/v1
metadata:
  name: qdrant-database
  namespace: qdrant
spec:
  resourceSelection:
    resourceKind: StatefulSet
  policy:
    storageSettings:
      requireRegionalStorage: true
    failoverSettings:
      forceDeleteStrategy: AfterNodeUnreachable
      afterNodeUnreachable:
        afterNodeUnreachableSeconds: 20 # 60 seconds total
```
Per il cluster Qdrant vengono create le seguenti risorse GKE:
- Il controller Qdrant StatefulSet che controlla tre repliche di pod.
- A PodDisruptionBudget, garantendo un massimo di una replica non disponibile.
- Il servizio qdrant-database, che espone la porta Qdrant per le connessioni in entrata e la replica tra i nodi.
- Il servizio qdrant-database-headless che fornisce l'elenco dei pod Qdrant in esecuzione.
- Il secret qdrant-database-apikey, che facilita la connessione sicura al database.
- Pod operatore HA stateful e risorsa HighlyAvailableApplication, che monitorano attivamente l'applicazione Qdrant. La risorsa HighlyAvailableApplication definisce le regole di failover da applicare a Qdrant.

Per verificare se le regole di failover sono applicate, descrivi la risorsa e conferma Status: Message: Application is protected.

kubectl describe highavailabilityapplication qdrant-database -n qdrant

L'output è simile al seguente:

Status:
Conditions:
    Last Transition Time:  2023-11-30T09:54:52Z
    Message:               Application is protected
    Observed Generation:   1
    Reason:                ApplicationProtected
    Status:                True
    Type:                  Protected

Esegui query con il notebook Vertex AI Colab Enterprise

Qdrant organizza vettori e payload in raccolte. L'incorporamento vettoriale è una tecnica che rappresenta parole o entità come vettori numerici mantenendo le loro relazioni semantiche. Ciò è importante per le ricerche per similarità, in quanto consente di trovare somiglianze in base al significato anziché a corrispondenze esatte, rendendo più efficaci e sfumate attività come i sistemi di ricerca e raccomandazione.

Questa sezione mostra come caricare i vettori in una nuova raccolta Qdrant ed eseguire query di ricerca.

In questo esempio, utilizzi un set di dati di un file CSV che contiene un elenco di libri di generi diversi. Crea un notebook Colab Enterprise per eseguire una query di ricerca nel database Qdrant.

Per saperne di più su Vertex AI Colab Enterprise, consulta la documentazione di Colab Enterprise.

Creare un modello di runtime

Per creare un modello di runtime Colab Enterprise:

Nella console Google Cloud , vai alla pagina Modelli di runtime di Colab Enterprise e assicurati che il tuo progetto sia selezionato:

Vai a Modelli di runtime
Fai clic su Nuovo modello. Viene visualizzata la pagina Crea nuovo modello di runtime.
Nella sezione Informazioni di base del runtime:
- Nel campo Nome visualizzato, inserisci qdrant-connect.
- Nell'elenco a discesa Regione, seleziona us-central1. Si tratta della stessa regione del cluster GKE.
Nella sezione Configura il calcolo:
- Nell'elenco a discesa Tipo di macchina, seleziona e2-standard-2.
- Nel campo Dimensione disco, inserisci 30.
Nella sezione Networking e sicurezza:
- Nell'elenco a discesa Rete, seleziona la rete in cui si trova il cluster GKE.
- Nell'elenco a discesa Subnet, seleziona una subnet corrispondente.
- Deseleziona la casella di controllo Abilita l'accesso a internet pubblico.
Per completare la creazione del modello di runtime, fai clic su Crea. Il modello di runtime viene visualizzato nell'elenco della scheda Modelli di runtime.

Crea un runtime

Per creare un runtime Colab Enterprise:

Nell'elenco dei modelli di runtime per il modello appena creato, nella colonna Azioni, fai clic su e poi su Crea runtime. Viene visualizzato il riquadro Crea runtime di Vertex AI.
Per creare un runtime basato sul tuo modello, fai clic su Crea.
Nella scheda Runtime che si apre, attendi che lo stato diventi In buono stato.

Importa il notebook

Per importare il notebook in Colab Enterprise:

Vai alla scheda I miei notebook e fai clic su Importa. Viene visualizzato il riquadro Importa blocchi note.
In Origine importazione, seleziona URL.

In URL notebook, inserisci il seguente link:

https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/databases/qdrant/manifests/04-notebook/vector-database.ipynb

Fai clic su Importa.

Connettiti al runtime ed esegui query

Per connetterti al runtime ed eseguire query:

Nel notebook, accanto al pulsante Connetti, fai clic su Opzioni di connessione aggiuntive. Viene visualizzato il riquadro Connetti al runtime di Vertex AI.
Seleziona Connetti a un runtime e poi Connetti a un runtime esistente.
Seleziona il runtime che hai avviato e fai clic su Connetti.
Per eseguire le celle del blocco note, fai clic sul pulsante Esegui cella accanto a ogni cella di codice.

Il blocco note contiene sia celle di codice sia testo che descrive ogni blocco di codice. L'esecuzione di una cella di codice esegue i relativi comandi e mostra un output. Puoi eseguire le celle in ordine o singole celle in base alle esigenze.

Visualizzare le metriche Prometheus per il cluster

Il cluster GKE è configurato con Google Cloud Managed Service per Prometheus, che consente la raccolta delle metriche nel formato Prometheus. Questo servizio fornisce una soluzione completamente gestita per il monitoraggio e gli avvisi, consentendo la raccolta, l'archiviazione e l'analisi delle metriche del cluster e delle relative applicazioni.

Il seguente diagramma mostra come Prometheus raccoglie le metriche per il tuo cluster:

Raccolta delle metriche Prometheus

Il cluster GKE privato nel diagramma contiene i seguenti componenti:

Pod Qdrant che espongono le metriche sul percorso / e sulla porta 80. Queste metriche sono fornite dal container collaterale denominato metrics.
Raccoglitori basati su Prometheus che elaborano le metriche dei pod Qdrant.
Una risorsa PodMonitoring che invia le metriche a Cloud Monitoring.

Per esportare e visualizzare le metriche, segui questi passaggi:

Crea la risorsa PodMonitoring per estrarre le metriche in base a labelSelector:

kubectl apply -n qdrant -f manifests/03-prometheus-metrics/pod-monitoring.yaml

Il file manifest pod-monitoring.yaml descrive la risorsa PodMonitoring:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: qdrant
spec:
  selector:
    matchLabels:
      app: qdrant
      app.kubernetes.io/instance: qdrant-database
  endpoints:
  - port: 80
    interval: 30s
    path: /

Crea una dashboard Cloud Monitoring con le configurazioni definite in dashboard.json :

gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json

Una volta eseguito correttamente il comando, vai alle dashboard di Cloud Monitoring:

Vai alla panoramica delle dashboard
Nell'elenco delle dashboard, apri la dashboard Qdrant Overview. Potrebbero essere necessari 1-2 minuti per raccogliere e visualizzare le metriche.

La dashboard mostra un conteggio delle metriche chiave:
- Raccolte
- Vettori incorporati
- Operazioni in attesa
- Nodi in esecuzione

Esegui il backup della configurazione del cluster

La funzionalità Backup per GKE consente di pianificare backup regolari dell'intera configurazione del cluster GKE, inclusi i workload di cui è stato eseguito il deployment e i relativi dati.

In questo tutorial, configuri un piano di backup per il tuo cluster GKE per eseguire backup di tutti i workload, inclusi secret e volumi, ogni giorno alle 3:00. Per garantire una gestione efficiente dello spazio di archiviazione, i backup più vecchi di tre giorni verranno eliminati automaticamente.

Per configurare i piani di backup, segui questi passaggi:

Abilita la funzionalità Backup per GKE per il cluster:

gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
--project=${PROJECT_ID} \
--location=${REGION} \
--update-addons=BackupRestore=ENABLED

Crea un piano di backup con una pianificazione giornaliera per tutti gli spazi dei nomi all'interno del cluster:

gcloud beta container backup-restore backup-plans create ${KUBERNETES_CLUSTER_PREFIX}-cluster-backup \
--project=${PROJECT_ID} \
--location=${REGION} \
--cluster="projects/${PROJECT_ID}/locations/${REGION}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster" \
--all-namespaces \
--include-secrets \
--include-volume-data \
--cron-schedule="0 3 * * *" \
--backup-retain-days=3

Il comando utilizza le variabili di ambiente pertinenti al runtime.

Il formato del nome del cluster è relativo al progetto e alla regione come segue:

projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

Quando richiesto, digita y.L'output è simile al seguente:

Create request issued for: [qdrant-cluster-backup]
Waiting for operation [projects/PROJECT_ID/locations/us-central1/operations/operation-1706528750815-610142ffdc9ac-71be4a05-f61c99fc] to complete...⠹

Il completamento di questa operazione potrebbe richiedere alcuni minuti. Al termine dell'esecuzione, l'output è simile al seguente:

Created backup plan [qdrant-cluster-backup].

Puoi vedere il piano di backup appena creato qdrant-cluster-backup elencato nella console di Backup per GKE.

Vai a Backup per GKE

Se vuoi ripristinare le configurazioni di backup salvate, consulta Ripristinare un backup.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

Il modo più semplice per evitare la fatturazione è eliminare il progetto creato per questo tutorial.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini, elimini anche tutto il lavoro che hai svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Se hai eliminato il progetto, la pulizia è completata. Se non hai eliminato il progetto, procedi con l'eliminazione delle singole risorse.

Elimina singole risorse

Imposta le variabili di ambiente.

export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=qdrant
export REGION=us-central1

Esegui il comando terraform destroy:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform  -chdir=terraform/FOLDER destroy \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Sostituisci FOLDER con gke-autopilot o gke-standard, a seconda del tipo di cluster GKE che hai creato.

Quando richiesto, digita yes.

Trova tutti i dischi scollegati:

export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,region)")

Elimina i dischi:

for i in $disk_list; do
 disk_name=$(echo $i| cut -d'|' -f1)
 disk_region=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
 echo "Deleting $disk_name"
 gcloud compute disks delete $disk_name --region $disk_region --quiet
done

Elimina il repository GitHub:
```
rm -r ~/kubernetes-engine-samples/
```

Passaggi successivi

Esplora Qdrant nel marketplace GKE.
Esplora il software open source Qdrant.
Prova l'operatore Qdrant che offre gestione delle chiavi API, supporto TLS con gestione dei certificati e pianificazione dei backup.
Scopri le best practice per il deployment dei database su GKE.
Scopri le soluzioni per l'esecuzione di carichi di lavoro a uso intensivo di dati con GKE.

Esegui il deployment di un database di vettori Qdrant su GKE Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Vantaggi

Obiettivi

Architettura di deployment

Diagramma dell'architettura

Costi

Prima di iniziare

Configura l'ambiente

Crea l'infrastruttura del cluster

Autopilot

Standard

Connettiti al cluster

Esegui il deployment del database Qdrant nel cluster

Autopilot

Standard

Esegui query con il notebook Vertex AI Colab Enterprise

Creare un modello di runtime

Crea un runtime

Importa il notebook

Connettiti al runtime ed esegui query

Visualizzare le metriche Prometheus per il cluster

Esegui il backup della configurazione del cluster

Esegui la pulizia

Elimina il progetto

Elimina singole risorse

Passaggi successivi

Esegui il deployment di un database di vettori Qdrant su GKE