Implantar um banco de dados de vetores Qdrant no GKE


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.

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ê 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 CLI do Google Cloud, kubectl, Helm e ferramentas de linha de comando do Terraform. Se você não estiver usando o Cloud Shell, instale a CLI do Google Cloud.

  1. 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.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. 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.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. 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
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. 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.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. 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
  12. Grant roles to your user account. Run the following command once for each of the following IAM roles: role/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_IDENTIFIER" --role=ROLE
    • Replace PROJECT_ID with your project ID.
    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.

    • Replace ROLE with each individual role.

Configurar seu ambiente

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

  1. 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 o PROJECT_ID pelo ID do projeto do Google Cloud.
  2. 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
    
  3. Clone o repositório de exemplo de código do GitHub:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    
  4. 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.

Autopilot

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 --region ${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.
  • 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:

  1. Ativar o complemento StatefulHA:

    Autopilot

    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} \
        --region=${REGION} \
        --update-addons=StatefulHA=ENABLED
    

    Pode levar vários minutos para que esse comando seja concluído e o cluster mostre um status pronto.

  2. 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
    
  3. Crie o namespace qdrant para o banco de dados:

    kubectl create ns qdrant
    
  4. 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
  5. 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:
      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.26
        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.

  6. 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
    
  7. 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.

  8. 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
    
  9. 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.
  10. 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
    

Fazer upload do conjunto de dados e executar consultas de pesquisa com o Jupyter Notebook

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 simples.

Neste exemplo, você usa um conjunto de dados de um arquivo CSV que contém uma lista de livros de diferentes gêneros. O Qdrant funcionará como um mecanismo de pesquisa, e o pod criado será o cliente que consulta o banco de dados do Qdrant.

  1. Crie os ConfigMaps books-dataset e demo-app e implante o notebook do Jupyter:

    kubectl create -n qdrant configmap books-dataset --from-file=manifests/04-notebook/dataset.csv
    kubectl create -n qdrant configmap notebook --from-file=manifests/04-notebook/vector-database.ipynb
    kubectl apply -n qdrant -f manifests/04-notebook/jupyter.yaml
    
    • O secret chamado qdrant-apikey criado anteriormente é ativado no pod do cliente como uma variável de ambiente chamada APIKEY.
    • O ConfigMap books-dataset contém um arquivo csv com dados de livros para a coleção do Qdrant
    • O ConfigMap notebook contém o notebook do Jupyter para criar a coleção Qdrant de books-dataset.

  2. Aguarde o GKE iniciar o pod Jupyter:

    kubectl wait pods -l app=jupyter-notebook --for condition=Ready --timeout=300s -n qdrant
    
  3. Abra esse URL e clique no arquivovector-database.ipynb. Pressione Executar -> Executar todas as células. O Jupyter vai executar todo o código e realizar uma consulta de pesquisa.

    Essa consulta executa uma pesquisa semântica na coleção my_books no Qdrant, recuperando no máximo dois resultados com a maior pontuação de correspondência relevante para o texto da consulta.

    Ela imprime cada resultado separado por uma linha de traços, no seguinte formato:

    • Title: título do livro
    • Author: autor do livro
    • Description: conforme armazenado no campo de metadados description do documento
    • Published: data de publicação do livro
    • Score: pontuação de relevância da Qdrant

    O resultado será assim:

    Title: Romeo and Juliet
    Author: William Shakespeare, Paul Werstine (Editor), Barbara A. Mowat (Editor),
    Paavo Emil Cajander (Translator)
    Description: In Romeo and Juliet, Shakespeare creates a violent world, in which
    two young people fall in love. It is not simply that their families disapprove;
    the Montagues and the Capulets are engaged in a blood feud.In this death-filled
    setting, the movement from love at first sight to the lovers' final union in
    death seems almost inevitable. And yet, this play set in an extraordinary world
    has become the quintessential story of young love. In part because of its exquisite
    language, it is easy to respond as if it were about all young lovers. Published: 01/01/04
    Score: 0.8935013
    -----
    Title: The Unbearable Lightness of Being
    Author: Milan Kundera, Michael Henry Heim (Translator)
    Description: In The Unbearable Lightness of Being, Milan Kundera tells the story
    of a young woman in love with a man torn between his love for her and his incorrigible
    womanizing and one of his mistresses and her humbly faithful lover. This magnificent
    novel juxtaposes geographically distant places, brilliant and playful reflections,
    and a variety of styles, to take its place as perhaps the major achievement of
    one of the world's truly great writers. Published: 10/27/09
    Score: 0.8931863
    -----
    

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:

  1. 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: / 
  2. 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
    
  3. Depois que o comando for executado, acesse os Painéis do Cloud Monitoring:

    Acessar "Visão geral dos painéis"

  4. 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:

  1. Ative o recurso Backup para GKE para seu cluster:

    gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --region=${REGION} \
    --update-addons=BackupRestore=ENABLED
    
  2. 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].
    
  3. É 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.

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

  1. Defina variáveis de ambiente.

    export PROJECT_ID=${PROJECT_ID}
    export KUBERNETES_CLUSTER_PREFIX=qdrant
    export REGION=us-central1
    
  2. 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.

  3. 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)")
    
  4. 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
    
  5. Para excluir o repositório do GitHub, faça o seguinte:

    rm -r ~/kubernetes-engine-samples/
    

A seguir