Esta página foi traduzida pela API Cloud Translation.

Implantar um banco de dados de vetores Qdrant no GKE

Autopilot Standard

Neste guia, mostramos como implantar um cluster de banco de dados de vetores Qdrant no Google Kubernetes Engine (GKE).

Bancos de dados vetoriais são armazenamentos de dados projetados especificamente para gerenciar e pesquisar em grandes coleções de vetores de alta dimensão. Esses vetores representam dados como texto, imagens, áudio, vídeo ou quaisquer dados que possam ser codificados numericamente. Ao contrário dos bancos de dados tradicionais, que dependem de correspondências exatas, os bancos de dados vetoriais se especializam em encontrar itens semelhantes ou identificar padrões em conjuntos de dados enormes. Essas características fazem do Qdrant uma escolha adequada para uma variedade de aplicativos, incluindo correspondência de rede neural ou baseada em semântica, pesquisa facetada e muito mais. O Qdrant não funciona apenas como um banco de dados vetorial, mas também como um mecanismo de pesquisa de similaridade vetorial.

Este tutorial é destinado a administradores e arquitetos da plataforma de nuvem, engenheiros de ML e profissionais de MLOps (DevOps) interessados em implantar clusters de banco de dados Qdrant no GKE.

Benefícios

A Qdrant oferece os seguintes benefícios:

Ampla variedade de bibliotecas para diversas linguagens de programação e API aberta para integração com outros serviços.
Escalonamento horizontal e suporte para fragmentação e replicação que simplificam o escalonamento e a alta disponibilidade.
Suporte a contêineres e Kubernetes que permite a implantação e o gerenciamento em ambientes modernos nativos da nuvem.
Payloads flexíveis com filtragem avançada para personalizar 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, você aprenderá a realizar as seguintes tarefas:

Planejar e implantar a infraestrutura do GKE para Qdrant.
Implante o operador StatefulHA para garantir a alta disponibilidade do Qdrant.
Implantar e configurar o cluster do Qdrant.
Faça upload de um conjunto de dados de demonstração e execute uma consulta de pesquisa simples.
Coletar métricas e gerar um painel.

Arquitetura de implantação

Essa arquitetura configura um cluster do GKE escalonável e tolerante a falhas para o Qdrant em várias zonas de disponibilidade, garantindo o tempo de atividade e a disponibilidade com atualizações graduais e o mínimo de interrupção. Ela inclui o uso do operador StatefulHA para um gerenciamento eficiente de failover. Para mais informações, consulte Clusters regionais.

Diagrama da arquitetura

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

Arquitetura de implantação do Qdrant

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

É possível controlar como o GKE distribui pods entre nós configurando as regras de afinidade e as restrições de distribuição de topologia necessárias no arquivo de valores do gráfico do Helm.
Se uma zona falhar, o GKE vai reprogramar 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 características:

Ela usa discos SSD regionais (StorageClass personalizado regional-pd) para armazenar dados. Recomendamos discos SSD regionais para bancos de dados devido à baixa latência e alta 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 possíveis falhas de zona.

Custos

Neste documento, você vai usar os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.

Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

Neste tutorial, use o Cloud Shell para executar os comandos. O Cloud Shell é um ambiente shell para gerenciar recursos hospedados no Google Cloud. Ele vem pré-instalado com a Google Cloud CLI, o kubectl, o Helm e ferramentas de linha de comando do Terraform. Se você não estiver usando o Cloud Shell, instale a CLI do 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.

Observação:se você instalou a CLI gcloud anteriormente, verifique se tem a versão mais recente executando gcloud components update.

Se você estiver usando um provedor de identidade externo (IdP), primeiro faça login na CLI gcloud com sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte 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.

Observação:se você instalou a CLI gcloud anteriormente, verifique se tem a versão mais recente executando gcloud components update.

Se você estiver usando um provedor de identidade externo (IdP), primeiro faça login na CLI gcloud com sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte 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, myemail@example.com.
- ROLE: the IAM role that you grant to your user account.

Configurar o ambiente

Para configurar o ambiente com o Cloud Shell, siga estas etapas:

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

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

Verifique a versão do Helm:

helm version

Atualize a versão se ela for anterior à 3.13:

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

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

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

Acesse o diretório qdrant para começar a criar recursos de implantação:
```
cd kubernetes-engine-samples/databases/qdrant
```

Criar a infraestrutura do cluster

Esta seção envolve a execução de um script do Terraform para criar um cluster do GKE privado altamente disponível e regional para implantar seu banco de dados Qdrant.

É possível implantar o Qdrant usando um cluster Standard ou Autopilot. Cada um tem vantagens específicas e modelos de preços diferentes.

Piloto automático

O diagrama a seguir mostra um cluster do GKE do Autopilot regional implantado em três zonas diferentes.

Cluster do Autopilot do GKE

Para implantar 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 variáveis abaixo são substituídas no ambiente de execução:

GOOGLE_OAUTH_ACCESS_TOKEN: substituído por um token de acesso recuperado pelo comando gcloud auth print-access-token para autenticar interações com várias APIs do Google Cloud.
PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX são as variáveis de ambiente definidas na seção Configurar seu ambiente e atribuídas às novas variáveis relevantes para o cluster do Autopilot que você está criando.

Quando solicitado, digite yes.

O resultado será assim:

...
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 particular para os nós do Kubernetes.
Um Cloud Router para acessar a Internet por meio da conversão de endereços de rede (NAT).
Um cluster do GKE particular na região us-central1.
Um ServiceAccount com permissões de geração de registros e monitoramento para o cluster.
Configuração do Google Cloud Managed Service para Prometheus para monitoramento e alertas de clusters.

Padrão

O diagrama a seguir mostra um cluster do GKE regional particular padrão implantado em três zonas diferentes.

Cluster do GKE Standard

Para implantar 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 variáveis abaixo são substituídas no ambiente de execução:

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

Quando solicitado, digite yes. Pode levar vários minutos para que esses comandos sejam concluídos e o cluster mostre um status pronto.

O resultado será assim:

...
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 particular para os nós do Kubernetes.
Um Cloud Router para acessar a Internet por meio da conversão de endereços de rede (NAT).
Um cluster do GKE particular na região us-central1 com escalonamento automático ativado (de um a dois nós por zona).
Um ServiceAccount com permissões de geração de registros e monitoramento para o cluster.
Configuração do Google Cloud Managed Service para Prometheus para monitoramento e alerta de clusters.

Conectar ao cluster

Configure kubectl para buscar credenciais e se comunicar com o novo cluster do GKE:

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

Implantar o banco de dados Qdrant no cluster

Neste tutorial, você vai implantar o banco de dados Qdrant (em modo distribuído) e o operador de alta disponibilidade com estado ao cluster do GKE usando o Gráfico do Helm.

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

Três réplicas dos nós do Qdrant.
As tolerâncias, afinidades de nó e restrições de distribuição de topologia são configuradas para garantir a distribuição adequada em todos os nós do Kubernetes. Os pools de nós e as diferentes zonas de disponibilidade são aproveitados.
Um volume RePD com o tipo de disco SSD é provisionado para o armazenamento de dados.
Um operador de alta disponibilidade com estado é usado para gerenciar processos de failover e garantir alta disponibilidade. Um StatefulSet é um controlador do Kubernetes que mantém uma identidade exclusiva e permanente para cada um dos pods.
Para autenticação, o banco de dados cria um secret do Kubernetes que contém a chave de API.

Para usar o gráfico do Helm e implantar o banco de dados Qdrant, siga estas etapas:

Ativar o complemento StatefulHA:
Piloto automático
O GKE ativa automaticamente o complemento StatefulHA na criação do cluster.
Padrão
Execute este comando:
```
gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --update-addons=StatefulHA=ENABLED
```
Pode levar vários minutos para que esse comando seja concluído e o cluster mostre um status pronto.
Adicione o repositório Helm do banco de dados da Qdrant antes de implantá-lo no cluster do GKE:
```
helm repo add qdrant https://qdrant.github.io/qdrant-helm
```
Crie o namespace qdrant para o banco de dados:
```
kubectl create ns qdrant
```

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

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

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

Implante um configmap do Kubernetes com uma configuração de arquivo secundário metrics e um cluster Qdrant usando o 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 arquivo secundário 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 do 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

Essa configuração ativa o modo de cluster, permitindo que você configure um cluster do Qdrant altamente disponível e distribuído.

Adicione um rótulo ao StatefulSet do Qdrant:

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

Implante um balanceador de carga interno para acessar o banco de dados Qdrant em execução na mesma VPC que o 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 status da implantação:

helm ls -n qdrant

Se o banco de dados qdrant for implantado com sucesso, a saída será semelhante à seguinte:

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 o GKE iniciar as cargas de trabalho necessárias:

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

Isso pode demorar alguns minutos.

Depois que o GKE iniciar as cargas de trabalho, verifique se ele criou as cargas de trabalho do Qdrant:
```
kubectl get pod,svc,statefulset,pdb,secret -n qdrant
```
Inicie o recurso HighAvailabilityApplication (HAA) para 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 StatefulSet do Qdrant que controla três réplicas de pod.
- A PodDisruptionBudget, garantindo no máximo uma réplica indisponível.
- O serviço qdrant-database, expondo a porta Qdrant para conexões de entrada e replicação entre nós.
- o serviço qdrant-database-headless, que fornece a lista de pods do Qdrant em execução.
- O secret qdrant-database-apikey, facilitando a conexão segura do banco de dados.
- Pod do operador de alta disponibilidade com estado e o recurso HighlyAvailableApplication, monitorando ativamente o aplicativo Qdrant. O recurso HighlyAvailableApplication define regras de failover para aplicar ao Qdrant.

Para verificar se as regras de failover foram aplicadas, descreva o recurso e confirme Status: Message: Application is protected.

kubectl describe highavailabilityapplication qdrant-database -n qdrant

O resultado será assim:

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

Executar consultas com o notebook do Colab Enterprise da Vertex AI

O Qdrant organiza vetores e payloads em coleções. O embedding de vetores é uma técnica que representa palavras ou entidades como vetores numéricos e mantém as relações semânticas delas. Isso é importante para pesquisas por similaridade, já que permite encontrar semelhanças com base no significado em vez de correspondências exatas, tornando tarefas como sistemas de pesquisa e recomendação mais eficazes e diferenciadas.

Esta seção mostra como fazer upload de vetores em uma nova coleção do Qdrant e executar consultas de pesquisa.

Neste exemplo, você usa um conjunto de dados de um arquivo CSV que contém uma lista de livros de diferentes gêneros. Você cria um notebook do Colab Enterprise para realizar uma consulta de pesquisa no banco de dados do Qdrant.

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

Criar um modelo de ambiente de execução

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

No console Google Cloud , acesse a página Modelos de ambiente de execução do Colab Enterprise e verifique se o projeto está selecionado:

Acessar "Modelos de ambiente de execução"
Clique em Novo modelo. A página Criar novo modelo de ambiente de execução é exibida.
Na seção Fundamentos do ambiente de execução:
- No campo Nome de exibição, insira qdrant-connect.
- Na lista suspensa Região, selecione us-central1. É a mesma região do seu cluster do GKE.
Na seção Configurar computação:
- Na lista suspensa Tipo de máquina, selecione e2-standard-2.
- No campo Tamanho do disco, digite 30.
Na seção Rede e segurança:
- Na lista suspensa Rede, selecione a rede em que o cluster do GKE está localizado.
- Na lista suspensa Sub-rede, selecione uma sub-rede correspondente.
- Desmarque a caixa de seleção Ativar acesso à Internet pública.
Para concluir a criação do modelo de ambiente de execução, clique em Criar. Seu modelo de ambiente de execução aparece na lista da guia Modelos de ambiente de execução.

Criar um ambiente de execução

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

Na lista de modelos de ambiente de execução do modelo que você acabou de criar, na coluna Ações, clique em e em Criar ambiente de execução. O painel Criar ambiente de execução da Vertex AI será exibido.
Para criar um ambiente de execução com base no modelo, clique em Criar.
Na guia Ambientes de execução que é aberta, aguarde até que o status mude para Íntegro.

Importar o notebook

Para importar o notebook no Colab Enterprise:

Acesse a guia Meus notebooks e clique em Importar. O painel Importar notebooks aparece.
Em Origem da importação, selecione URL.

Em URLs do notebook, insira 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.

Conectar-se ao ambiente de execução e executar consultas

Para se conectar ao ambiente de execução e executar consultas:

No notebook, ao lado do botão Conectar, clique em Opções de conexão adicionais. O painel Conectar ao ambiente de execução da Vertex AI é exibido.
Selecione Conectar a um ambiente de execução e Conectar a um ambiente de execução.
Selecione o ambiente de execução iniciado e clique em Conectar.
Para executar as células do notebook, clique no botão Executar célula ao lado de cada célula de código.

O notebook contém células de código e texto que descrevem cada bloco de código. A execução de uma célula de código executa os comandos e mostra uma saída. É possível executar as células em ordem ou individualmente, conforme necessário.

Conferir as métricas do Prometheus para seu cluster

O cluster do GKE é configurado com o Google Cloud Managed Service para Prometheus, que permite a coleta de métricas no formato do Prometheus. Esse serviço oferece uma solução totalmente gerenciada para monitoramento e alerta, permitindo a coleta, o armazenamento e a análise de métricas do cluster e dos aplicativos dele.

O diagrama a seguir mostra como o Prometheus coleta métricas para o cluster:

Coleta de métricas do Prometheus

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

Pods Qdrant que expõem métricas no caminho / e na porta 80. Essas métricas são fornecidas pelo contêiner de arquivo secundário chamado metrics.
Coletores baseados em Prometheus que processam as métricas dos pods do Qdrant.
Um recurso de PodMonitoring que envia métricas ao Cloud Monitoring.

Para exportar e visualizar as métricas, siga estas etapas:

Crie o recurso PodMonitoring para coletar 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 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 que o comando for executado, acesse os Painéis do Cloud Monitoring:

Acessar "Visão geral dos painéis"
Na lista de painéis, abra o painel Qdrant Overview. A coleta e exibição das métricas pode levar de um a dois minutos.

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

Fazer backup da configuração do cluster

O recurso Backup para GKE permite programar backups regulares de toda a configuração do cluster do GKE, incluindo as cargas de trabalho implantadas e os dados delas.

Neste tutorial, você configura um plano de backup para o cluster do GKE a fim de executar backups de todas as cargas de trabalho, incluindo secrets e volumes, todos os dias às 3h. Para garantir um gerenciamento de armazenamento eficiente, os backups com mais de três dias seriam excluídos automaticamente.

Para configurar planos de backup, siga estas etapas:

Ative o recurso Backup para GKE para seu cluster:

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

Crie um plano de backup com uma programação diária para todos os namespaces 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 ambiente de execução.

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

projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

Quando solicitado, digite y.. A saída será assim:

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

Essa operação pode levar alguns minutos para ser concluída. Depois que a execução for concluída, a saída será semelhante à seguinte:

Created backup plan [qdrant-cluster-backup].

É possível ver o plano de backup recém-criado qdrant-cluster-backup listado no console do Backup para GKE.

Acessar o Backup para GKE

Para restaurar as configurações de backup salvas, consulte Restaurar um backup.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

A maneira mais fácil de evitar o faturamento é excluir o projeto criado para o tutorial.

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Se você tiver excluído o projeto, a limpeza estará completa. Se você não excluiu o projeto, exclua os recursos individuais.

Excluir 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, dependendo do tipo de cluster do GKE que você criou.

Quando solicitado, digite yes.

Encontre todos os discos desanexados:

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

Exclua 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

Para excluir o repositório do GitHub, faça o seguinte:
```
rm -r ~/kubernetes-engine-samples/
```

A seguir

Conheça o Qdrant no GKE Marketplace.
Conheça o software de código aberto Qdrant.
Experimente o Operador de Qdrant que oferece Gerenciamento de chaves de API, suporte a TLS com gerenciamento de certificados eprogramação de backup.
Conheça as práticas recomendadas para implantar bancos de dados no GKE.
Descubra soluções para executar cargas de trabalho com uso intensivo de dados usando o GKE.

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

Benefícios

Objetivos

Arquitetura de implantação

Diagrama da arquitetura

Custos

Antes de começar

Configurar o ambiente

Criar a infraestrutura do cluster

Piloto automático

Padrão

Conectar ao cluster

Implantar o banco de dados Qdrant no cluster

Piloto automático

Padrão

Executar consultas com o notebook do Colab Enterprise da Vertex AI

Criar um modelo de ambiente de execução

Criar um ambiente de execução

Importar o notebook

Conectar-se ao ambiente de execução e executar consultas

Conferir as métricas do Prometheus para seu cluster

Fazer backup da configuração do cluster

Limpar

Exclua o projeto

Excluir recursos individuais

A seguir

Implantar um banco de dados de vetores Qdrant no GKE