Implantar um banco de dados de vetores do Elasticsearch no GKE

Autopilot Standard

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.

Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

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

gcloud components
      update

Crie ou selecione um projeto do Google Cloud.

Crie um projeto do Google Cloud:
```
gcloud projects create PROJECT_ID
```
Substitua PROJECT_ID por um nome para o projeto do Google Cloud que você está criando.
Selecione o projeto do Google Cloud que você criou:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo nome do projeto do Google Cloud.

Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Ative as APIs Cloud Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE:

gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

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

gcloud components
      update

Crie ou selecione um projeto do Google Cloud.

Crie um projeto do Google Cloud:
```
gcloud projects create PROJECT_ID
```
Substitua PROJECT_ID por um nome para o projeto do Google Cloud que você está criando.
Selecione o projeto do Google Cloud que você criou:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo nome do projeto do Google Cloud.

Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Ative as APIs Cloud Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE:

gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

Atribua os papéis à sua Conta do Google. Execute uma vez o seguinte comando para cada um dos seguintes papéis do IAM: 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:EMAIL_ADDRESS" --role=ROLE
```
- Substitua PROJECT_ID pela ID do seu projeto.
- Substitua EMAIL_ADDRESS pelo seu endereço de e-mail.
- Substitua ROLE por cada papel individual.

Configurar seu ambiente

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

Defina variáveis de ambiente para o projeto, a região e um prefixo de recurso de cluster do Kubernetes:
```
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.

Verifique a versão do Helm:

helm version

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

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

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

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

Acesse o diretório 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:

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

Implantar o operador de ECK:

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

Crie o namespace elastic para o banco de dados:
```
kubectl create ns elastic
```

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

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

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']

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.

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.

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>

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.

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

Aguarde o GKE iniciar o pod do Jupyter:

kubectl wait pods -l app=jupyter-notebook --for condition=Ready --timeout=300s -n elastic

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}|"

Abra o URL e clique no arquivo vector-database.ipynb.

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:

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

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

Acessar "Visão geral dos painéis"
Na lista de painéis, abra o painel 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.

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

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

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

Cuidado: excluir um projeto tem os seguintes efeitos:

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

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

Exclua um projeto do Google Cloud:

gcloud projects delete PROJECT_ID

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

Excluir recursos individuais

Defina variáveis de ambiente.

export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=elasticsearch
export REGION=us-central1

Execute o comando terraform destroy:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform  -chdir=terraform/FOLDER destroy \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Substitua FOLDER por gke-autopilot ou gke-standard, dependendo do tipo de cluster do GKE que você criou.

Quando solicitado, digite yes.

Encontre todos os discos desanexados:

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

Exclua os discos:

for i in $disk_list; do
 disk_name=$(echo $i| cut -d'|' -f1)
 disk_region=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
 echo "Deleting $disk_name"
 gcloud compute disks delete $disk_name --region $disk_region --quiet
done

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

A seguir

Conhecer o software de código aberto Elasticsearch.
Conheça as práticas recomendadas para implantar bancos de dados no GKE.
Descubra soluções para executar cargas de trabalho com uso intensivo de dados usando o GKE.