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.
  • Faça upload de um conjunto de dados de demonstração e execute uma consulta de pesquisa simples.
  • 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 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 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: 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:

    export PROJECT_ID=PROJECT_ID
    export KUBERNETES_CLUSTER_PREFIX=elasticsearch
    export REGION=us-central1
    
    • Substitua o 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.

Autopilot

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:

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

Faça upload do conjunto de dados de demonstração e execute consultas de pesquisa com o Jupyter Notebook

Nesta seção, você faz o upload de vetores em documentos do Elasticsearch e executa consultas de pesquisa semântica usando o cliente Python oficial do Elasticsearch. Um documento no Elasticsearch é composto de vários campos, cada um pareado com seu valor correspondente. 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 serve como um cliente consultando o banco de dados do Elasticsearch.

  1. Crie os ConfigMaps books-dataset e notebook e execute o pod do Jupyter para interagir com o cluster do Elasticsearch:

    kubectl create -n elastic configmap books-dataset --from-file=manifests/03-notebook/dataset.csv
    kubectl create -n elastic configmap notebook --from-file=manifests/03-notebook/vector-database.ipynb
    kubectl apply -n elastic -f manifests/03-notebook/jupyter.yaml
    
    • O secret chamado elasticsearch-ha-es-elastic-user criado anteriormente é ativado no pod do cliente como uma variável de ambiente chamada PW.
    • O ConfigMap books-dataset contém um arquivo csv com dados de livros para o índice do Elasticsearch.
    • O ConfigMap notebook contém o notebook do Jupyter para criar o índice do Elasticsearch de books-dataset.

    O manifesto jupyter.yaml descreve a implantação de notebook e o respectivo serviço:

    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels: &labels
        app: jupyter-notebook
      name: notebook
    spec:
      ports:
      - port: 8888
      selector: *labels
      type: LoadBalancer
      # type: ClusterIP
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: notebook
      labels: &labels
        app: jupyter-notebook
    spec:
      selector:
        matchLabels: *labels
      template:
        metadata: 
          labels: *labels
        spec:
          containers:
          - name: jupyter
            image: tensorflow/tensorflow:2.15.0-jupyter
            resources:
              requests:
                memory: "4500Mi"
                cpu: "1"
              limits:
                memory: "4500Mi"
                cpu: "1"
            ports:
            - containerPort: 8888
            env:
            - name: PW
              valueFrom:
                secretKeyRef:
                  name: elasticsearch-ha-es-elastic-user
                  key: elastic
            volumeMounts:
            - name: books-dataset
              mountPath: /usr/local/dataset
            - name: notebook
              mountPath: /tf
            - name: elastic-cert
              mountPath: /usr/local/cert
          volumes:
          - name: books-dataset
            configMap:
              name: books-dataset
          - name: notebook
            configMap:
              name: notebook
          - name: elastic-cert
            secret:
              secretName: elasticsearch-ha-es-http-certs-public
  2. Aguarde o GKE iniciar o pod do Jupyter:

    kubectl wait pods -l app=jupyter-notebook --for condition=Ready --timeout=300s -n elastic
    
  3. Consiga o URL com o token de acesso para se conectar ao Jupyter:

    export EXTERNAL_IP=$(kubectl -n elastic get svc notebook --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
    kubectl logs deploy/notebook -n elastic| grep '^ .*http://127'|sed "s|127.0.0.1|${EXTERNAL_IP}|"
    
  4. Abra o URL e clique no arquivo vector-database.ipynb.

  5. Clique em Run > Run all Cells. O Jupyter executa o código e faz uma consulta de pesquisa para o texto drama about people and unhappy love.

    Essa consulta realiza uma pesquisa semântica no índice books no Elasticsearch, recuperando no máximo dois resultados com a maior pontuação de correspondência relevante para sua consulta.

    O resultado será assim:

    Title: Romeo and Juliet, Author: William Shakespeare, Paul Werstine (Editor),
    Barbara A. Mowat (Editor), Paavo Emil Cajander (Translator), score: 1.8473973
    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.
    ---------
    Title: A Midsummer Night's Dream, Author: William Shakespeare, Paul Werstine
    (Editor), Barbara A. Mowat (Editor), Catherine Belsey (Contributor), score: 1.8415744
    Shakespeare's intertwined love polygons begin to get complicated from the
    start--Demetrius and Lysander both want Hermia but she only has eyes for Lysander.
    Bad news is, Hermia's father wants Demetrius for a son-in-law. On the outside
    is Helena, whose unreturned love burns hot for Demetrius. Hermia and Lysander
    plan to flee from the city under cover of darkness but are pursued by an enraged
    Demetrius (who is himself pursued by an enraptured Helena). In the forest, unbeknownst
    to the mortals, Oberon and Titania (King and Queen of the faeries) are having a
    spat over a servant boy. The plot twists up when Oberon's head mischief-maker,
    Puck, runs loose with a flower which causes people to fall in love with the first
    thing they see upon waking. Throw in a group of labourers preparing a play for
    the Duke's wedding (one of whom is given a donkey's head and Titania for a lover
    by Puck) and the complications become fantastically funny.
    ---------
    

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