Esta página foi traduzida pela API Cloud Translation.

Implemente uma base de dados vetorial Qdrant no GKE

Autopilot Padrão

Este guia mostra como implementar um cluster de base de dados vetorial Qdrant no Google Kubernetes Engine (GKE).

As bases de dados vetoriais são armazenamentos de dados especificamente concebidos para gerir e pesquisar grandes coleções de vetores de alta dimensão. Estes vetores representam dados como texto, imagens, áudio, vídeo ou quaisquer dados que possam ser codificados numericamente. Ao contrário das bases de dados tradicionais que se baseiam em correspondências exatas, as bases de dados vetoriais especializam-se em encontrar itens semelhantes ou identificar padrões em conjuntos de dados massivos. Estas caraterísticas tornam o Qdrant uma escolha adequada para uma variedade de aplicações, incluindo a correspondência baseada em redes neurais ou semântica, a pesquisa facetada e muito mais. O Qdrant não funciona apenas como uma base de dados de vetores, mas também como um motor de pesquisa de similaridade de vetores.

Este tutorial destina-se a administradores e arquitetos da plataforma na nuvem, engenheiros de ML e profissionais de MLOps (DevOps) interessados na implementação de clusters da base de dados Qdrant no GKE.

Vantagens

O Qdrant oferece as seguintes vantagens:

Vasta gama de bibliotecas para várias linguagens de programação e API aberta para integração com outros serviços.
Escalabilidade horizontal e suporte para divisão e replicação que simplificam a escalabilidade e a alta disponibilidade.
Suporte de contentores e Kubernetes que permite a implementação e a gestão em ambientes modernos nativos da nuvem.
Payloads flexíveis com filtragem avançada para adaptar os critérios de pesquisa com precisão.
Diferentes opções de quantização e outras otimizações para reduzir os custos de infraestrutura e melhorar o desempenho.

Objetivos

Neste tutorial, vai aprender a:

Planeie e implemente a infraestrutura do GKE para o Qdrant.
Implemente o operador StatefulHA para garantir a alta disponibilidade do Qdrant.
Implemente e configure o cluster Qdrant.
Carregue um conjunto de dados de demonstração e execute uma consulta de pesquisa simples.
Recolha métricas e execute um painel de controlo.

Arquitetura de implementação

Esta arquitetura configura um cluster do GKE tolerante a falhas e escalável para o Qdrant em várias zonas de disponibilidade, garantindo o tempo de atividade e a disponibilidade com atualizações contínuas e interrupções mínimas. Inclui a utilização do operador StatefulHA para uma gestão eficiente da comutação por falha. Para mais informações, consulte o artigo Clusters regionais.

Diagrama de arquitetura

O diagrama seguinte mostra um cluster do Qdrant em execução em vários nós e zonas num cluster do GKE:

Arquitetura de implementação do Qdrant

Nesta arquitetura, o Qdrant StatefulSet é implementado em três nós em três zonas diferentes.

Pode controlar como o GKE distribui os pods pelos nós configurando as regras de afinidade de pods necessárias e as restrições de dispersão de topologia no ficheiro de valores do gráfico Helm.
Se uma zona falhar, o GKE reagenda os pods em novos nós com base na configuração recomendada.

Para a persistência de dados, a arquitetura neste tutorial tem as seguintes caraterísticas:

StorageClass personalizado) para persistir os dados. Recomendamos discos SSD regionais para bases de dados devido à sua baixa latência e elevado IOPS.
Todos os dados do disco são replicados entre as zonas primária e secundária na região, aumentando a tolerância a potenciais falhas de zonas.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização prevista, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

Neste tutorial, vai usar a Cloud Shell para executar comandos. O Cloud Shell é um ambiente de shell para gerir recursos alojados no Google Cloud. É fornecido pré-instalado com as ferramentas de linha de comandos CLI do Google Cloud, kubectl, Helm e Terraform. Se não usar o Cloud Shell, tem de instalar a CLI Google Cloud.

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 instalou a CLI gcloud anteriormente, certifique-se de que tem a versão mais recente executando gcloud components update.

Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

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 instalou a CLI gcloud anteriormente, certifique-se de que tem a versão mais recente executando gcloud components update.

Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

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, myemail@example.com.
- ROLE: The IAM role that you grant to your user account.

Configure o seu ambiente

Para configurar o seu ambiente com o Cloud Shell, siga estes passos:

Defina variáveis de ambiente para o seu projeto, região e um prefixo de recurso de cluster do Kubernetes:

Para efeitos deste tutorial, use a região us-central1 para criar os recursos de implementação.
```
export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=qdrant
export REGION=us-central1
```
- Substitua PROJECT_ID pelo seu Google Cloud ID do projeto.

Verifique a versão do Helm:

helm version

Atualize a versão se for anterior à 3.13:

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

Clone o repositório de código de exemplo do GitHub:

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

Navegue para o qdrantdiretório para começar a criar recursos de implementação:
```
cd kubernetes-engine-samples/databases/qdrant
```

Crie a infraestrutura do cluster

Esta secção envolve a execução de um script do Terraform para criar um cluster do GKE regional privado e de elevada disponibilidade para implementar a sua base de dados Qdrant.

Pode optar por implementar o Qdrant através de um cluster padrão ou do Autopilot. Cada um tem as suas próprias vantagens e modelos de preços diferentes.

Piloto automático

O diagrama seguinte mostra um cluster do GKE regional do Autopilot implementado em três zonas diferentes.

Cluster do GKE Autopilot

Para implementar a infraestrutura do cluster, execute os seguintes comandos no 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}

As seguintes variáveis são substituídas no momento da execução:

GOOGLE_OAUTH_ACCESS_TOKEN: substituído por um token de acesso obtido através do comando gcloud auth print-access-token para autenticar interações com várias APIs Google Cloud
PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX são as variáveis de ambiente definidas na secção Configure o seu ambiente e atribuídas às novas variáveis relevantes para o cluster do Autopilot que está a criar.

Quando lhe for pedido, escreva yes.

O resultado é semelhante ao seguinte:

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

Outputs:

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

O Terraform cria os seguintes recursos:

Uma rede VPC personalizada e uma sub-rede privada para os nós do Kubernetes.
Um Cloud Router para aceder à Internet através da tradução de endereços de rede (NAT).
Um cluster do GKE privado na região us-central1.
Um ServiceAccount com autorizações de registo e monitorização para o cluster.
Configuração do Google Cloud Managed Service for Prometheus para monitorização e alertas de clusters.

Standard

O diagrama seguinte mostra um cluster GKE regional privado padrão implementado em três zonas diferentes.

Cluster padrão do GKE

Para implementar a infraestrutura do cluster, execute os seguintes comandos no 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}

As seguintes variáveis são substituídas no momento da execução:

GOOGLE_OAUTH_ACCESS_TOKEN é substituído por um token de acesso obtido através do comando gcloud auth print-access-token para autenticar interações com várias APIs Google Cloud.
PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX são as variáveis de ambiente definidas na secção Configure o seu ambiente e atribuídas às novas variáveis relevantes para o cluster padrão que está a criar.

Quando lhe for pedido, escreva yes. Estes comandos podem demorar vários minutos a serem concluídos e o cluster a apresentar o estado pronto.

O resultado é semelhante ao seguinte:

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

Outputs:

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

O Terraform cria os seguintes recursos:

Uma rede VPC personalizada e uma sub-rede privada para os nós do Kubernetes.
Um Cloud Router para aceder à Internet através da tradução de endereços de rede (NAT).
Um cluster do GKE privado na região us-central1 com a escala automática ativada (um a dois nós por zona).
Um ServiceAccount com autorizações de registo e monitorização para o cluster.
Configuração do Google Cloud Managed Service for Prometheus para monitorização e alertas de clusters.

Estabeleça ligação ao cluster

Configure o kubectl para obter credenciais e comunicar com o seu novo cluster do GKE:

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

Implemente a base de dados Qdrant no seu cluster

Neste tutorial, implementa a base de dados Qdrant (no modo distribuído) e o operador de HA com estado no cluster do GKE através do gráfico Helm.

A implementação cria um cluster do GKE com a seguinte configuração:

Três réplicas dos nós Qdrant.
As tolerâncias, as afinidades de nós e as restrições de propagação da topologia estão configuradas para garantir a distribuição adequada pelos nós do Kubernetes. Isto tira partido dos conjuntos de nós e das diferentes zonas de disponibilidade.
É aprovisionado um volume RePD com o tipo de disco SSD para o armazenamento de dados.
Um operador de HA com estado é usado para gerir processos de comutação por falha e garantir a elevada disponibilidade. Um StatefulSet é um controlador do Kubernetes que mantém uma identidade exclusiva persistente para cada um dos respetivos pods.
Para a autenticação, a base de dados cria um segredo do Kubernetes que contém a chave da API.

Para usar o gráfico Helm para implementar a base de dados Qdrant, siga estes passos:

Ative o suplemento StatefulHA:
Piloto automático
O GKE ativa automaticamente o suplemento StatefulHA aquando da criação do cluster.
Standard
Execute o seguinte comando:
```
gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --update-addons=StatefulHA=ENABLED
```
Este comando pode demorar 15 minutos a ser concluído e o cluster a apresentar o estado pronto.
Adicione o repositório do gráfico Helm da base de dados Qdrant antes de o poder implementar no seu cluster do GKE:
```
helm repo add qdrant https://qdrant.github.io/qdrant-helm
```
Crie o espaço de nomes qdrant para a base de dados:
```
kubectl create ns qdrant
```

Aplique o manifesto para criar um disco SSD persistente regional StorageClass:

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

O manifesto regional-pd.yaml descreve o disco SSD persistente 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

Implemente um configmap do Kubernetes com uma configuração de metrics sidecar e um cluster do Qdrant através do 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

O manifesto metrics-cm.yaml descreve o ficheiro auxiliar 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;
      }
    }

O manifesto values.yaml descreve a configuração do 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.29
    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

Esta configuração ativa o modo de cluster, o que lhe permite configurar um cluster do Qdrant distribuído e de elevada disponibilidade.

Adicione uma etiqueta ao conjunto de estado do Qdrant:

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

Implemente um equilibrador de carga interno para aceder à sua base de dados Qdrant que está a ser executada na mesma VPC que o seu cluster do GKE:

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

O manifesto ilb.yaml descreve o serviço 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

Verifique o estado da implementação:

helm ls -n qdrant

O resultado é semelhante ao seguinte, se a base de dados qdrant for implementada com êxito:

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

Aguarde que o GKE inicie as cargas de trabalho necessárias:
```
kubectl wait pods -l app.kubernetes.io/instance=qdrant-database --for condition=Ready --timeout=300s -n qdrant
```
Este comando pode demorar alguns minutos a ser concluído com êxito.
Assim que o GKE iniciar as cargas de trabalho, verifique se o GKE criou as cargas de trabalho do Qdrant:
```
kubectl get pod,svc,statefulset,pdb,secret -n qdrant
```
Inicie o recurso HighAvailabilityApplication (HAA) para o Qdrant:
```
kubectl apply -n qdrant -f manifests/01-regional-pd/ha-app.yaml
```
O manifesto ha-app.yaml descreve o recurso 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
```
Os seguintes recursos do GKE são criados para o cluster do Qdrant:
- O Qdrant StatefulSet que controla três réplicas de pods.
- A PodDisruptionBudget, garantindo um máximo de uma réplica indisponível.
- O serviço qdrant-database, que expõe a porta Qdrant para ligações recebidas e replicação entre nós.
- O serviço qdrant-database-headless, que fornece a lista de pods do Qdrant em execução.
- O segredo qdrant-database-apikey facilita a ligação segura à base de dados.
- Pod do operador de HA com estado e recurso HighlyAvailableApplication, que monitoriza ativamente a aplicação Qdrant. O recurso HighlyAvailableApplication define regras de alternativa a aplicar ao Qdrant.

Para verificar se as regras de comutação por falha são aplicadas, descreva o recurso e confirme Status: Message: Application is protected.

kubectl describe highavailabilityapplication qdrant-database -n qdrant

O resultado é semelhante ao seguinte:

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

Execute consultas com o bloco de notas do Vertex AI Colab Enterprise

O Qdrant organiza vetores e payloads em coleções. A incorporação de vetores é uma técnica que representa palavras ou entidades como vetores numéricos, mantendo as respetivas relações semânticas. Isto é importante para as pesquisas de semelhanças, pois permite encontrar semelhanças com base no significado e não em correspondências exatas, o que torna tarefas como os sistemas de pesquisa e recomendação mais eficazes e detalhadas.

Esta secção mostra como carregar vetores para uma nova coleção do Qdrant e executar consultas de pesquisa.

Neste exemplo, usa um conjunto de dados de um ficheiro CSV que contém uma lista de livros de diferentes géneros. Cria um bloco de notas do Colab Enterprise para executar uma consulta de pesquisa na base de dados Qdrant.

Para mais informações sobre o Vertex AI Colab Enterprise, consulte a documentação do Colab Enterprise.

Crie um modelo de tempo de execução

Para criar um modelo de tempo de execução do Colab Enterprise:

Na Google Cloud consola, aceda à página Modelos de tempo de execução do Colab Enterprise e certifique-se de que o seu projeto está selecionado:

Aceda aos modelos do ambiente de execução
Clique em Novo modelo. É apresentada a página Criar novo modelo de tempo de execução.
Na secção Noções básicas do ambiente de execução:
- No campo Nome a apresentar, introduza qdrant-connect.
- Na lista pendente Região, selecione us-central1. É a mesma região que o seu cluster do GKE.
Na secção Configurar computação:
- Na lista pendente Tipo de máquina, selecione e2-standard-2.
- No campo Tamanho do disco, introduza 30.
Na secção Redes e segurança:
- Na lista pendente Rede, selecione a rede onde o seu cluster do GKE reside.
- Na lista pendente Sub-rede, selecione uma sub-rede correspondente.
- Desmarque a caixa de verificação Ativar acesso público à Internet.
Para concluir a criação do modelo de tempo de execução, clique em Criar. O modelo do ambiente de execução aparece na lista no separador Modelos do ambiente de execução.

Crie um tempo de execução

Para criar um tempo de execução do Colab Enterprise:

Na lista de modelos de tempo de execução do modelo que acabou de criar, na coluna Ações, clique em e, de seguida, clique em Criar tempo de execução. É apresentado o painel Criar tempo de execução do Vertex AI.
Para criar um tempo de execução com base no seu modelo, clique em Criar.
No separador Tempos de execução que é aberto, aguarde que o estado passe a Em bom estado.

Importe o bloco de notas

Para importar o bloco de notas no Colab Enterprise:

Aceda ao separador Os meus blocos de notas e clique em Importar. É apresentado o painel Importar blocos de notas.
Em Origem da importação, selecione URL.

Em URLs do notebook, introduza o seguinte link:

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

Clique em Importar.

Ligue-se ao tempo de execução e execute consultas

Para se ligar ao tempo de execução e executar consultas:

No bloco de notas, junto ao botão Associar, clique em Opções de associação adicionais. É apresentado o painel Ligar ao tempo de execução do Vertex AI.
Selecione Ligar a um tempo de execução e, de seguida, selecione Ligar a um tempo de execução existente.
Selecione o tempo de execução que iniciou e clique em Associar.
Para executar as células do bloco de notas, clique no botão Executar célula junto a cada célula de código.

O bloco de notas contém células de código e texto que descrevem cada bloqueio de código. A execução de uma célula de código executa os respetivos comandos e apresenta uma saída. Pode executar as células por ordem ou executar células individuais conforme necessário.

Veja as métricas do Prometheus para o seu cluster

O cluster do GKE está configurado com o Google Cloud Managed Service for Prometheus, o que permite a recolha de métricas no formato Prometheus. Este serviço oferece uma solução totalmente gerida para monitorização e alertas, permitindo a recolha, o armazenamento e a análise de métricas do cluster e das respetivas aplicações.

O diagrama seguinte mostra como o Prometheus recolhe métricas para o seu cluster:

Recolha de métricas do Prometheus

O cluster privado do GKE no diagrama contém os seguintes componentes:

Pods do Qdrant que expõem métricas no caminho / e na porta 80. Estas métricas são fornecidas pelo contentor auxiliar denominado metrics.
Coletores baseados no Prometheus que processam as métricas dos pods do Qdrant.
Um recurso PodMonitoring que envia as métricas para o Cloud Monitoring.

Para exportar e ver as métricas, siga estes passos:

Crie o recurso PodMonitoring para extrair métricas por labelSelector:

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

O manifesto pod-monitoring.yaml descreve o recurso 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: /

Crie um painel de controlo do Cloud Monitoring com as configurações definidas em dashboard.json :

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

Depois de o comando ser executado com êxito, aceda a Cloud Monitoring Painéis de controlo:

Aceda à vista geral dos painéis de controlo
Na lista de painéis de controlo, abra o painel de controlo Qdrant Overview. Pode demorar 1 a 2 minutos a recolher e apresentar métricas.

O painel de controlo mostra uma contagem das principais métricas:
- Coleções
- Vetores incorporados
- Operações pendentes
- Nós em execução

Faça uma cópia de segurança da configuração do cluster

A funcionalidade Cópia de segurança do GKE permite-lhe agendar cópias de segurança regulares da configuração completa do cluster do GKE, incluindo as cargas de trabalho implementadas e os respetivos dados.

Neste tutorial, vai configurar um plano de cópia de segurança para o seu cluster do GKE de modo a fazer cópias de segurança de todas as cargas de trabalho, incluindo segredos e volumes, todos os dias às 03:00. Para garantir uma gestão de armazenamento eficiente, as cópias de segurança com mais de três dias são eliminadas automaticamente.

Para configurar planos de yedekleme, siga estes passos:

Ative a funcionalidade Cópia de segurança do GKE para o seu cluster:

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

Crie um plano de cópia de segurança com uma programação diária para todos os espaços de nomes no 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

O comando usa as variáveis de ambiente relevantes no tempo de execução.

O formato do nome do cluster é relativo ao seu projeto e região da seguinte forma:

projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

Quando lhe for pedido, escreva y.O resultado é semelhante ao seguinte:

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

Esta operação pode demorar alguns minutos a ser concluída com êxito. Após a conclusão da execução, o resultado é semelhante ao seguinte:

Created backup plan [qdrant-cluster-backup].

Pode ver o plano de cópia de segurança recém-criado qdrant-cluster-backup listado na consola de cópia de segurança do GKE.

Aceder à Cópia de segurança do GKE

Se quiser restaurar as configurações de cópia de segurança guardadas, consulte o artigo Restaure uma cópia de segurança.

Limpar

Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

Elimine o projeto

A forma mais fácil de evitar a faturação é eliminar o projeto que criou para este tutorial.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Se eliminou o projeto, a limpeza está concluída. Se não eliminou o projeto, avance para a eliminação dos recursos individuais.

Elimine recursos individuais

Defina variáveis de ambiente.

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

Execute o 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}

Substitua FOLDER por gke-autopilot ou gke-standard, consoante o tipo de cluster do GKE que criou.

Quando lhe for pedido, escreva yes.

Encontre todos os discos não anexados:

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

Elimine os discos:

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

Elimine o repositório do GitHub:
```
rm -r ~/kubernetes-engine-samples/
```

O que se segue?

Explore o Qdrant no GKE Marketplace.
Explore o software Qdrant de código aberto.
Experimente o operador Qdrant que oferece gestão de chaves de API, compatibilidade com TLS com gestão de certificados> e agendamento de cópias de segurança.
Saiba mais sobre as práticas recomendadas para implementar bases de dados no GKE.
Descubra soluções para executar cargas de trabalho com grande volume de dados com o GKE.

Implemente uma base de dados vetorial Qdrant no GKE Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Vantagens

Objetivos

Arquitetura de implementação

Diagrama de arquitetura

Custos

Antes de começar

Configure o seu ambiente

Crie a infraestrutura do cluster

Piloto automático

Standard

Estabeleça ligação ao cluster

Implemente a base de dados Qdrant no seu cluster

Piloto automático

Standard

Execute consultas com o bloco de notas do Vertex AI Colab Enterprise

Crie um modelo de tempo de execução

Crie um tempo de execução

Importe o bloco de notas

Ligue-se ao tempo de execução e execute consultas

Veja as métricas do Prometheus para o seu cluster

Faça uma cópia de segurança da configuração do cluster

Limpar

Elimine o projeto

Elimine recursos individuais

O que se segue?

Implemente uma base de dados vetorial Qdrant no GKE