Implantar um banco de dados de vetores do Elasticsearch no GKE

Neste tutorial, mostramos como implantar um cluster de banco de dados de vetores Elasticsearch 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.

O Elasticsearch é um banco de dados de vetores que combina funcionalidades de pesquisa e análise. Ele vem com uma API REST aberta para gerenciar seu cluster e oferece suporte a consultas estruturadas, consultas de texto completo e consultas complexas. O Elasticsearch permite realizar pesquisas de frase, similaridade e prefixo, com sugestões de preenchimento automático.

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 Elasticsearch no GKE.

Benefícios

O Elasticsearch 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.
  • Balanceamento de clusters de vários nós para utilização ideal de recursos.
  • Suporte a contêineres e Kubernetes para integração total com ambientes modernos nativos da nuvem.

Objetivos

Neste tutorial, você aprenderá a realizar as seguintes tarefas:

  • Planejar e implantar a infraestrutura do GKE para Elasticsearch.
  • Implantar e configurar o Elasticsearch em um cluster do GKE.
  • Implante o operador StatefulHA para garantir a alta disponibilidade do Elasticsearch.
  • Execute um notebook para gerar e armazenar exemplos de embeddings vetoriais no seu banco de dados e realizar consultas de pesquisa baseadas em vetores.
  • Coletar e visualizar métricas em um painel.

Arquitetura de implantação

Neste tutorial, você verá como implantar um cluster do GKE regional altamente disponível para o Elasticsearch, com vários nós do Kubernetes espalhados por várias zonas de disponibilidade. Essa configuração ajuda a garantir tolerância a falhas, escalonabilidade e redundância geográfica. Ele permite atualizações e manutenção graduais, fornecendo SLAs para tempo de atividade e disponibilidade. Para mais informações, consulte Clusters regionais.

Quando um nó se torna inacessível, um pod nesse nó não é reprogramado imediatamente. Com pods usando um StatefulSet, pode levar mais de oito minutos para que os pods do aplicativo sejam excluídos e reprogramados para novos nós.

Para resolver esse problema, o operador StatefulHA faz o seguinte:

  • Resolve o atraso de reprogramação, gerencia as configurações de failover e reduz o tempo de recuperação usando configurações .forceDeleteStrategy: AfterNodeUnreachable.
  • Garante que o aplicativo StatefulSet esteja usando o RePD.
  • Amplia o GKE com um recurso HighAvailabilityApplication personalizado que é implantado no mesmo namespace do Elasticsearch. Isso permite que o operador StatefulHA monitore e responda a eventos de failover.

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

Arquitetura de implantação do Elasticsearch

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.

O uso do Elasticsearch é gratuito de acordo com a licença pública do lado do servidor (SSPL).

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, 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 Cloud 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 Cloud 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: 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 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:

    export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=elasticsearch
export REGION=us-central1
    • Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

    Este tutorial usa a região us-central1 para criar seus recursos de implantação.

  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 elasticsearch para começar a criar recursos de implantação:

    cd kubernetes-engine-samples/databases/elasticsearch

Criar a infraestrutura do cluster

Nesta seção, você executa um script do Terraform para criar um cluster privado do GKE altamente disponível e regional para implantar seu banco de dados do Elasticsearch.

É 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 Autopilot implantado no projeto.

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}

O GKE substitui as seguintes variáveis no ambiente de execução:

  • GOOGLE_OAUTH_ACCESS_TOKEN usa o comando gcloud auth print-access-token para recuperar um token de acesso que autentique 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 elasticsearch-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}

O GKE substitui as seguintes variáveis no ambiente de execução:

  • GOOGLE_OAUTH_ACCESS_TOKEN usa o comando gcloud auth print-access-token para recuperar um token de acesso que autentique 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 elasticsearch-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 Elasticsearch e o operador StatefulHA

Nesta seção, você implanta o banco de dados do Elasticsearch (no modo de cluster) e o operador StatefulHA no cluster do GKE usando o Gráfico do Helm do operador ECK.

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

  • Três réplicas dos nós do Elasticsearch.
  • DaemonSet para alterar as configurações de memória virtual, visando o desempenho ideal do Elasticsearch.
  • Configuração do NodeAffinity e do PodAntiAffinity para garantir a distribuição adequada entre nós do Kubernetes, otimizando o uso de pools de nós e maximizando a disponibilidade em diferentes zonas.
  • Um operador de alta disponibilidade com estado que gerencia processos de failover e garante alta disponibilidade.
  • Para autenticação, o banco de dados cria secrets do Kubernetes com credenciais, senhas e certificados de autenticação.

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

  1. 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} \
    --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. Crie uma definição de recurso personalizada (CRD, na sigla em inglês) do Elastic Cloud no Kubernetes (ECK):

    kubectl apply -f https://download.elastic.co/downloads/eck/2.11.1/crds.yaml

  3. Implantar o operador de ECK:

    kubectl apply -f https://download.elastic.co/downloads/eck/2.11.1/operator.yaml

  4. Crie o namespace elastic para o banco de dados:

    kubectl create ns elastic

  5. Instale o recurso HighAvailabilityApplication (HAA), que define regras de failover para o Elasticsearch.

    kubectl apply -n elastic -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: elasticsearch-ha-es-main
  namespace: elastic
spec:
  resourceSelection:
    resourceKind: StatefulSet
  policy:
    storageSettings:
      requireRegionalStorage: false
    failoverSettings:
      forceDeleteStrategy: AfterNodeUnreachable
      afterNodeUnreachable:
        afterNodeUnreachableSeconds: 20 # 60 seconds total

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

    kubectl apply -n elastic -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

  7. Implante o recurso DaemonSet para definir a memória virtual em cada nó:

    kubectl apply -n elastic -f manifests/02-elasticsearch/mmap-count.yaml

    O manifesto mmap-count.yaml descreve o DaemonSet:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: max-map-count-setter
  labels:
    k8s-app: max-map-count-setter
spec:
  selector:
    matchLabels:
      name: max-map-count-setter
  template:
    metadata:
      labels:
        name: max-map-count-setter
    spec:
      initContainers:
        - name: max-map-count-setter
          image: docker.io/bash:5.2.21
          resources:
            limits:
              cpu: 100m
              memory: 32Mi
          securityContext:
            privileged: true
            runAsUser: 0
          command: ['/usr/local/bin/bash', '-e', '-c', 'echo 262144 > /proc/sys/vm/max_map_count']
      containers:
        - name: sleep
          image: docker.io/bash:5.2.21
          command: ['sleep', 'infinity']

  8. Aplique o manifesto para implantar o cluster do Elasticsearch:

    kubectl apply -n elastic -f manifests/02-elasticsearch/elasticsearch.yaml

    O manifesto elasticsearch.yaml descreve a implantação:

    apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: elasticsearch-ha
spec:
  version: 8.11.4
  nodeSets:
  - name: main
    count: 3
    volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data 
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: ha-regional
    config:
    podTemplate:
      metadata:
        labels:
          app.stateful/component: elasticsearch
      spec:
        initContainers:
        - name: max-map-count-check
          command: ['sh', '-c', "while true; do mmc=$(cat /proc/sys/vm/max_map_count); if [ ${mmc} -eq 262144 ]; then exit 0; fi; sleep 1; done"]
        containers:
        - name: metrics
          image: quay.io/prometheuscommunity/elasticsearch-exporter:v1.7.0
          command:
            - /bin/elasticsearch_exporter
            - --es.ssl-skip-verify
            - --es.uri=https://$(ES_USER):$(ES_PASSWORD)@localhost:9200
          securityContext:
            runAsNonRoot: true
            runAsGroup: 10000
            runAsUser: 10000
          resources:
            requests:
              memory: "128Mi"
              cpu: "25m"
            limits:
              memory: "128Mi"
              cpu: "100m"
          ports:
          - containerPort: 9114
          env:
          - name: ES_USER
            value: "elastic"
          - name: ES_PASSWORD
            valueFrom:
              secretKeyRef:
                name: elasticsearch-ha-es-elastic-user
                key: elastic
        - name: elasticsearch
          resources:
            limits:
              memory: 4Gi
              cpu: 1
        affinity:
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 1
                preference:
                  matchExpressions:
                  - key: app.stateful/component
                    operator: In
                    values:
                    - elasticsearch
          podAntiAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.stateful/component: elasticsearch
                topologyKey: topology.kubernetes.io/zone

    Aguarde alguns minutos até que o cluster do Elasticsearch seja totalmente iniciado.

  9. Verifique o status da implantação:

    kubectl get elasticsearch -n elastic --watch

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

    NAME               HEALTH   NODES   VERSION   PHASE   AGE
elasticsearch-ha   green    3       8.11.4    Ready   2m30s

    Aguarde até que HEALTH apareça como green. Pressione Ctrl+C para sair do comando, se necessário.

  10. Implante um balanceador de carga interno para acessar o banco de dados do Elasticsearch que está sendo executado na mesma VPC do cluster do GKE:

    kubectl apply -n elastic -f manifests/02-elasticsearch/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: elasticsearch
  name: elastic-ilb
spec:
  ports:
  - name: https
    port: 9200
    protocol: TCP
    targetPort: 9200
  selector:
    common.k8s.elastic.co/type: elasticsearch
    elasticsearch.k8s.elastic.co/cluster-name: elasticsearch-ha
  type: LoadBalancer

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

    kubectl describe highavailabilityapplication elasticsearch-ha-es-main -n elastic

    A saída é semelhante ao seguinte

    Status:
  Conditions:
    Last Transition Time:  2024-02-01T13:27:50Z
    Message:               Application is protected
    Observed Generation:   1
    Reason:                ApplicationProtected
    Status:                True
    Type:                  Protected
Events:                    <none>

  12. Depois que o GKE iniciar as cargas de trabalho, verifique se ele criou as cargas de trabalho do Elasticsearch:

    kubectl get pod,svc,statefulset,pdb,secret,daemonset -n elastic

    O resultado será assim:

    NAME                             READY   STATUS    RESTARTS   AGE
pod/elasticsearch-ha-es-main-0   2/2     Running   0          7m16s
pod/elasticsearch-ha-es-main-1   2/2     Running   0          7m16s
pod/elasticsearch-ha-es-main-2   2/2     Running   0          7m16s
pod/max-map-count-setter-28wt9   1/1     Running   0          7m27s
pod/max-map-count-setter-cflsw   1/1     Running   0          7m27s
pod/max-map-count-setter-gzq9k   1/1     Running   0          7m27s

NAME                                        TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/elasticsearch-ha-es-http            ClusterIP   10.52.8.28   <none>        9200/TCP   7m18s
service/elasticsearch-ha-es-internal-http   ClusterIP   10.52.3.48   <none>        9200/TCP   7m18s
service/elasticsearch-ha-es-main            ClusterIP   None         <none>        9200/TCP   7m16s
service/elasticsearch-ha-es-transport       ClusterIP   None         <none>        9300/TCP   7m18s

NAME                                        READY   AGE
statefulset.apps/elasticsearch-ha-es-main   3/3     7m16s

NAME                                                     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/elasticsearch-ha-es-default   2               N/A               1                     7m16s

NAME                                                 TYPE     DATA   AGE
secret/elasticsearch-ha-es-elastic-user              Opaque   1      7m18s
secret/elasticsearch-ha-es-file-settings             Opaque   1      7m16s
secret/elasticsearch-ha-es-http-ca-internal          Opaque   2      7m17s
secret/elasticsearch-ha-es-http-certs-internal       Opaque   3      7m17s
secret/elasticsearch-ha-es-http-certs-public         Opaque   2      7m17s
secret/elasticsearch-ha-es-internal-users            Opaque   4      7m18s
secret/elasticsearch-ha-es-main-es-config            Opaque   1      7m16s
secret/elasticsearch-ha-es-main-es-transport-certs   Opaque   7      7m16s
secret/elasticsearch-ha-es-remote-ca                 Opaque   1      7m16s
secret/elasticsearch-ha-es-transport-ca-internal     Opaque   2      7m16s
secret/elasticsearch-ha-es-transport-certs-public    Opaque   1      7m16s
secret/elasticsearch-ha-es-xpack-file-realm          Opaque   4      7m18s

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/max-map-count-setter   6         6         6       6            6           <none>          13m

Os seguintes recursos do GKE são criados para o cluster do Elasticsearch:

  • O StatefulSet do Elasticsearch que controla três réplicas de pod.
  • Um DaemonSet para as configurações de memória virtual.
  • Serviços para se conectar ao Elasticsearch.
  • Secrets com credenciais de superusuário e certificados relacionados a serviços.
  • Pod do operador de alta disponibilidade com estado e o recurso HighlyAvailableApplication, monitorando ativamente o aplicativo Elasticsearch.

Executar consultas com o notebook do Colab Enterprise da Vertex AI

Esta seção explica como gerar embeddings em documentos do Elasticsearch e executar consultas de pesquisa semântica usando o cliente Python oficial do Elasticsearch no notebook do Colab Enterprise. Um documento no Elasticsearch é composto por vários campos, cada um pareado com o valor correspondente.

Prática recomendada:

Para utilizar o Elasticsearch de maneira eficaz, recomendamos que você estruture seus dados nesses documentos, que são então indexados para fins 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. O Elasticsearch funciona como um mecanismo de pesquisa, e o pod criado funciona como um cliente que consulta o banco de dados do Elasticsearch.

É possível usar um modelo de ambiente de execução dedicado para implantar na VPC elasticsearch-vpc (nuvem privada virtual), para que o notebook possa se comunicar com os recursos no cluster do GKE.

Criar um modelo de ambiente de execução

Para criar um modelo de ambiente de execução:

  1. No console do 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"

  2. Clique em Novo modelo. A página Criar novo modelo de ambiente de execução será exibida.

  3. Na seção Fundamentos do ambiente de execução:

    • No campo Nome de exibição, insira elastic-connect.
    • Na lista suspensa Região, selecione us-central1. É a mesma região do cluster do GKE.

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

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

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

  6. Clique em Criar para concluir a criação do modelo de ambiente de execução. 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:

  1. Na lista de modelos de ambiente de execução, para o modelo que você acabou de criar, clique em na coluna Ações e, em seguida, clique em Criar ambiente de execução. O painel Criar ambiente de execução da Vertex AI será exibido.

  2. Clique em Criar para criar um ambiente de execução com base no modelo.

  3. Na guia Ambientes de execução que é aberta, aguarde até que o status mude para Íntegro.

Importar o notebook

Para importar o notebook:

  1. Acesse a guia Notebooks e clique em Importar notebook de URLs.

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

  3. Em URLs do notebook, insira o seguinte link:

    https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/main/databases/elasticsearch/manifests/03-notebook/vector-database.ipynb

  4. Clique em Importar.

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

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

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

  2. Selecione Conectar a um ambiente de execução e Conectar a um ambiente de execução.

  3. Selecione o ambiente de execução iniciado e clique em Conectar.

  4. Clique no botão Executar célula à esquerda de cada célula de código para executar as células do notebook.

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.

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

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 Elasticsearch que expõem métricas no caminho / e na porta 9114. Essas métricas são fornecidas pelo contêiner de arquivo secundário chamado metrics, que contém o elasticsearch_exporter.
  • Coletores baseados em Prometheus que processam as métricas do pod do Elasticsearch.
  • Um recurso de PodMonitoring que envia métricas ao Cloud Monitoring.

A configuração do cluster define um contêiner de arquivo secundário com exportador de métricas no formato do Prometheus:

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: elasticsearch-ha
spec:
  ...
  nodeSets:
  - name: main
    ...
    podTemplate:
      spec:
        containers:
        ...
        - name: metrics
          image: quay.io/prometheuscommunity/elasticsearch-exporter:v1.7.0
          command:
          - /bin/elasticsearch_exporter
          - --es.ssl-skip-verify
          - --es.uri=https://$(ES_USER):$(ES_PASSWORD)@localhost:9200
          ...
          env:
          - name: ES_USER
            value: "elastic"
          - name: ES_PASSWORD
            valueFrom:
            secretKeyRef:
              name: elasticsearch-ha-es-elastic-user
              key: elastic

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

  1. Crie o recurso PodMonitoring para coletar métricas por labelSelector:

    kubectl apply -n elastic -f manifests/04-prometheus-metrics/pod-monitoring.yaml

    O manifesto pod-monitoring.yaml descreve o recurso PodMonitoring:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: elasticsearch
spec:
  selector:
    matchLabels:
      app.stateful/component: elasticsearch
      elasticsearch.k8s.elastic.co/cluster-name: elasticsearch-ha
  endpoints:
  - port: 9114
    interval: 30s
    path: /metrics

    Depois de alguns minutos, é exibido o painel integrado "Elasticsearch Prometheus Overview".

  2. Para acessar mais gráficos relacionados a dados, importe um painel personalizado 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 ElasticSearch 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:

    • Índices
    • Documentos e fragmentos
    • Operações pendentes
    • Nós em execução com os respectivos status de integridade

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.

  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: [elasticsearch-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 [elasticsearch-cluster-backup].

  3. É possível ver o plano de backup recém-criado elasticsearch-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=elasticsearch
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