Implemente uma base de dados vetorial Qdrant no GKE

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 vetorial, mas também como um motor de pesquisa de similaridade vetorial.

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.
  • Recolher métricas e executar 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 zona.

Configure o seu ambiente

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

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

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

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

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

  4. 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 modo automático. 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 serviço gerido Google Cloud para o 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 pode demorar 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 única 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:

  1. 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 pode demorar 15 minutos a apresentar o estado pronto.

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

  3. Crie o espaço de nomes qdrant para a base de dados:

    kubectl create ns qdrant

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

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

  6. Adicione uma etiqueta ao conjunto de estado do Qdrant:

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

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

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

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

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

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

  12. 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, uma vez que 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:

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

  2. Clique em Novo modelo. É apresentada a página Criar novo modelo de tempo de execução.

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

  4. Na secção Configurar computação:

    • Na lista pendente Tipo de máquina, selecione e2-standard-2.
    • No campo Tamanho do disco, introduza 30.

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

  6. Para concluir a criação do modelo de tempo de execução, clique em Criar. O modelo de tempo de execução aparece na lista no separador Modelos de tempo de execução.

Crie um tempo de execução

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

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

  2. Para criar um tempo de execução com base no seu modelo, clique em Criar.

  3. No separador Tempos de execução que é aberto, aguarde até que o estado passe a Em bom estado.

Importe o bloco de notas

Para importar o bloco de notas no Colab Enterprise:

  1. Aceda ao separador Os meus blocos de notas e clique em Importar. É apresentado o painel Importar blocos de notas.

  2. Em Origem da importação, selecione URL.

  3. Em URLs do bloco de notas, introduza o seguinte link:

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

  4. Clique em Importar.

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

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

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

  2. Selecione Ligar a um tempo de execução e, de seguida, selecione Ligar a um tempo de execução existente.

  3. Selecione o tempo de execução que iniciou e clique em Associar.

  4. 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 um resultado. 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, 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:

  1. 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: /

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

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

    Aceda à vista geral dos painéis de controlo

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

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

  2. 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].

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