Implemente uma base de dados vetorial do Elasticsearch no GKE

Este tutorial mostra como implementar um cluster de base de dados vetorial do Elasticsearch no Google Kubernetes Engine (GKE).

As bases de dados vetoriais são armazenamentos de dados especificamente concebidos para gerir e pesquisar grandes coleções de vetores de alta dimensão. Estes vetores representam dados como texto, imagens, áudio, vídeo ou quaisquer dados que possam ser codificados numericamente. Ao contrário das bases de dados relacionais que se baseiam em correspondências exatas, as bases de dados vetoriais especializam-se em encontrar itens semelhantes ou identificar padrões em conjuntos de dados massivos.

O Elasticsearch é uma base de dados vetorial que combina funcionalidades de pesquisa e análise. Inclui uma API REST aberta para gerir o seu cluster e suporta consultas estruturadas, consultas de texto completo e consultas complexas. O Elasticsearch permite-lhe fazer pesquisas de expressões, de semelhanças e de prefixos, com sugestões de preenchimento automático.

Este tutorial destina-se a administradores e arquitetos da plataforma na nuvem, engenheiros de ML e profissionais de MLOps (DevOps) interessados na implementação de clusters de bases de dados do Elasticsearch no GKE.

Vantagens

O Elasticsearch oferece as seguintes vantagens:

  • Vasta gama de bibliotecas para várias linguagens de programação e API aberta para integração com outros serviços.
  • Escalabilidade horizontal e suporte para divisão e replicação que simplificam a escalabilidade e a alta disponibilidade.
  • Equilíbrio de clusters com vários nós para uma utilização ideal dos recursos.
  • Suporte de contentores e Kubernetes para uma integração perfeita em ambientes nativos da nuvem modernos.

Objetivos

Neste tutorial, vai aprender a:

  • Planeie e implemente a infraestrutura do GKE para o Elasticsearch.
  • Implemente e configure o Elasticsearch num cluster do GKE.
  • Implemente o operador StatefulHA para garantir a elevada disponibilidade do Elasticsearch.
  • Execute um notebook para gerar e armazenar exemplos de incorporações de vetores na sua base de dados e execute consultas de pesquisa baseadas em vetores.
  • Recolha e visualize métricas num painel de controlo.

Arquitetura de implementação

Neste tutorial, implementa um cluster do GKE regional de alta disponibilidade para o Elasticsearch, com vários nós do Kubernetes distribuídos por várias zonas de disponibilidade. Esta configuração ajuda a garantir a tolerância a falhas, a escalabilidade e a redundância geográfica. Permite atualizações contínuas e manutenção, ao mesmo tempo que oferece SLAs para tempo de atividade e disponibilidade. Para mais informações, consulte o artigo Clusters regionais.

Quando um nó fica inacessível, um pod nesse nó não é reagendado imediatamente. Com os pods a usar um StatefulSet, pode demorar mais de oito minutos para que os pods da aplicação sejam eliminados e reagendados para novos nós.

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

  • Resolve o atraso no reagendamento, processa as definições de comutação por falha e reduz o tempo de recuperação através das definições de .forceDeleteStrategy: AfterNodeUnreachable.
  • Garante que a aplicação StatefulSet está a usar o RePD.
  • Expande o GKE com um recurso HighAvailabilityApplication personalizado que é implementado no mesmo espaço de nomes que o Elasticsearch. Isto permite que o operador StatefulHA monitorize e responda a eventos de comutação por falha.

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

Arquitetura de implementação do Elasticsearch

Configure o seu ambiente

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

  1. Defina variáveis de ambiente para o seu projeto, região e um prefixo de recurso de cluster do Kubernetes:

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

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

  2. Verifique a versão do Helm:

    helm version

    Atualize a versão se for anterior à 3.13:

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

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

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

  4. Navegue para o elasticsearchdiretório para começar a criar recursos de implementação:

    cd kubernetes-engine-samples/databases/elasticsearch

Crie a infraestrutura do cluster

Nesta secção, executa um script do Terraform para criar um cluster do GKE regional privado e de elevada disponibilidade para implementar a sua base de dados do Elasticsearch.

Pode optar por implementar o Elasticsearch através de um cluster padrão ou do Autopilot. Cada um tem as suas próprias vantagens e modelos de preços diferentes.

Piloto automático

O diagrama seguinte mostra um cluster do GKE Autopilot implementado no projeto.

Cluster do GKE Autopilot

Para implementar a infraestrutura do cluster, execute os seguintes comandos no Cloud Shell:

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

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

  • GOOGLE_OAUTH_ACCESS_TOKEN usa o comando gcloud auth print-access-token para obter um token de acesso que autentica as interações com várias APIs Google Cloud
  • PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX são as variáveis de ambiente definidas na secção Configure o seu ambiente e atribuídas às novas variáveis relevantes para o cluster do Autopilot que está a criar.

Quando lhe for pedido, escreva yes.

O resultado é semelhante ao seguinte:

...
Apply complete! Resources: 9 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials elasticsearch-cluster --region us-central1"

O Terraform cria os seguintes recursos:

  • Uma rede VPC personalizada e uma sub-rede privada para os nós do Kubernetes.
  • Um Cloud Router para aceder à Internet através da tradução de endereços de rede (NAT).
  • Um cluster do GKE privado na região us-central1.
  • Um ServiceAccount com autorizações de registo e monitorização para o cluster.
  • Configuração do serviço gerido Google Cloud para o Prometheus para monitorização e alertas de clusters.

Standard

O diagrama seguinte mostra um cluster GKE regional privado padrão implementado em três zonas diferentes.

Cluster padrão do GKE

Para implementar a infraestrutura do cluster, execute os seguintes comandos no Cloud Shell:

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

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

  • GOOGLE_OAUTH_ACCESS_TOKEN usa o comando gcloud auth print-access-token para obter um token de acesso que autentica as interações com várias APIs Google Cloud.
  • PROJECT_ID, REGION e KUBERNETES_CLUSTER_PREFIX são as variáveis de ambiente definidas na secção Configure o seu ambiente e atribuídas às novas variáveis relevantes para o cluster padrão que está a criar.

Quando lhe for pedido, escreva yes. Estes comandos podem demorar vários minutos a serem concluídos e o cluster pode demorar a apresentar o estado pronto.

O resultado é semelhante ao seguinte:

...
Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials elasticsearch-cluster --region us-central1"

O Terraform cria os seguintes recursos:

  • Uma rede VPC personalizada e uma sub-rede privada para os nós do Kubernetes.
  • Um Cloud Router para aceder à Internet através da tradução de endereços de rede (NAT).
  • Um cluster do GKE privado na região us-central1 com a escala automática ativada (um a dois nós por zona).
  • Um ServiceAccount com autorizações de registo e monitorização para o cluster.
  • Configuração do Google Cloud Managed Service for Prometheus para monitorização e alertas de clusters.

Estabeleça ligação ao cluster

Configure o kubectl para obter credenciais e comunicar com o seu novo cluster do GKE:

gcloud container clusters get-credentials \
    ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

Implemente a base de dados Elasticsearch e o operador StatefulHA

Nesta secção, implementa a base de dados Elasticsearch (no modo de cluster) e o operador StatefulHA no cluster do GKE através do gráfico Helm do operador ECK.

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

  • Três réplicas dos nós do Elasticsearch.
  • DaemonSet para alterar as definições de memória virtual, para um desempenho ideal do Elasticsearch. Um DaemonSet é um controlador do Kubernetes que garante que uma cópia de um Pod é executada em cada nó num cluster.
  • Configuração de NodeAffinity e PodAntiAffinity para garantir a distribuição adequada em nós do Kubernetes, otimizando a utilização de node pools e maximizando a disponibilidade em diferentes zonas.
  • Um operador de HA com estado que gere processos de comutação por falha e garanta a alta disponibilidade. Um StatefulSet é um controlador do Kubernetes que mantém uma identidade única persistente para cada um dos respetivos pods.
  • Para a autenticação, a base de dados cria Secrets do Kubernetes com credenciais de autenticação, palavras-passe e certificados.

Para usar o gráfico Helm para implementar a base de dados Elasticsearch, siga estes passos:

  1. Ative o suplemento StatefulHA:

    Piloto automático

    O GKE ativa automaticamente o suplemento StatefulHA aquando da criação do cluster.

    Standard

    Execute o seguinte comando:

    gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --update-addons=StatefulHA=ENABLED

    Este comando pode demorar 15 minutos a ser concluído e o cluster pode demorar 15 minutos a apresentar o estado pronto.

  2. Crie uma definição de recurso personalizado (CRD) do Elastic Cloud on Kubernetes (ECK):

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

  3. Implemente o operador ECK:

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

  4. Crie o espaço de nomes elastic para a base de dados:

    kubectl create ns elastic

  5. Instale o recurso HighAvailabilityApplication (HAA), que define regras de comutação por falha 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 persistente regional StorageClass:

    kubectl apply -n elastic -f manifests/01-regional-pd/regional-pd.yaml

    O manifesto regional-pd.yaml descreve o disco SSD persistente StorageClass:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
allowVolumeExpansion: true
metadata:
  name: ha-regional
parameters:
  replication-type: regional-pd
  type: pd-ssd
  availability-class: regional-hard-failover
provisioner: pd.csi.storage.gke.io
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

  7. Implemente 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 implementar o cluster do Elasticsearch:

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

    O manifesto elasticsearch.yaml descreve a implementaçã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 iniciado totalmente.

  9. Verifique o estado da implementação:

    kubectl get elasticsearch -n elastic --watch

    O resultado é semelhante ao seguinte, se a base de dados elasticsearch for implementada com êxito:

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

    Aguarde até que HEALTH seja apresentado como green. Prima Ctrl+C para sair do comando, se necessário.

  10. Implemente um equilibrador de carga interno para aceder à sua base de dados do Elasticsearch que está a ser executada na mesma VPC que o seu 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 comutação por falha são aplicadas, descreva o recurso e confirme Status: Message: Application is protected.

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

    O resultado é 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. Assim que o GKE iniciar as cargas de trabalho, verifique se o GKE criou as cargas de trabalho do Elasticsearch:

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

    O resultado é semelhante ao seguinte:

    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 Elasticsearch StatefulSet que controla três réplicas de pods.
  • Um DaemonSet para configurar as definições de memória virtual.
  • Serviços para estabelecer ligação ao Elasticsearch.
  • Informações secretas com credenciais de superutilizador e certificados relacionados com o serviço.
  • Pod do operador de HA com estado e recurso HighlyAvailableApplication, a monitorizar ativamente a aplicação Elasticsearch.

Execute consultas com o bloco de notas do Vertex AI Colab Enterprise

Esta secção explica como gerar incorporações em documentos do Elasticsearch e executar consultas de pesquisa semântica usando o cliente Python oficial do Elasticsearch no bloco de notas do Colab Enterprise. Um documento no Elasticsearch é composto por vários campos, cada um associado ao respetivo valor.

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

Prática recomendada:

Para usar o Elasticsearch de forma eficaz, recomendamos que estruture os seus dados nestes documentos, que são depois indexados para fins de pesquisa.

Neste exemplo, usa um conjunto de dados de um ficheiro CSV que contém uma lista de livros de diferentes géneros. O Elasticsearch funciona como um motor de pesquisa e o pod que cria funciona como um cliente que consulta a base de dados do Elasticsearch.

Pode usar um modelo de tempo de execução dedicado para implementar na elasticsearch-vpcVPC (nuvem privada virtual), para que o bloco de notas possa comunicar com os recursos no seu cluster do GKE.

Crie um modelo de tempo de execução

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

  1. Na Google Cloud consola, aceda à página Modelos de tempo de execução do Colab Enterprise e certifique-se de que o seu projeto está selecionado:

    Aceda aos modelos do ambiente de execução

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

  3. Na secção Noções básicas do ambiente de execução:

    • No campo Nome a apresentar, introduza elastic-connect.
    • Na lista pendente Região, selecione us-central1. É a mesma região que o seu cluster do GKE.

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

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

  5. Na secção Redes e segurança:

    • Na lista pendente Rede, selecione a rede onde o seu cluster do GKE reside.
    • Na lista pendente Sub-rede, selecione uma sub-rede correspondente.
    • Desmarque a caixa de verificação Ativar acesso público à Internet.

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

Crie um tempo de execução

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

  1. Na lista de modelos de tempo de execução do modelo que acabou de criar, na coluna Ações, clique em e, de seguida, clique em Criar tempo de execução. É apresentado o painel Criar tempo de execução do Vertex AI.

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

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

Importe o bloco de notas

Para importar o bloco de notas no Colab Enterprise:

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

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

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

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

  4. Clique em Importar.

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

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

  1. No bloco de notas, junto ao botão Associar, clique em Opções de associação adicionais. É apresentado o painel Ligar ao tempo de execução do Vertex AI.

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

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

  4. Para executar as células do bloco de notas, clique no botão Executar célula junto a cada célula de código.

O bloco de notas contém células de código e texto que descrevem cada bloqueio de código. A execução de uma célula de código executa os respetivos comandos e apresenta um resultado. Pode executar as células por ordem ou executar células individuais conforme necessário.

Veja as métricas do Prometheus para o seu cluster

O cluster do GKE está configurado com o Google Cloud Managed Service for Prometheus, que permite a recolha de métricas no formato Prometheus. Este serviço oferece uma solução totalmente gerida para monitorização e alertas, permitindo a recolha, o armazenamento e a análise de métricas do cluster e das respetivas aplicações.

O diagrama seguinte mostra como o Prometheus recolhe métricas para o seu cluster:

Recolha de métricas do Prometheus

O cluster privado do GKE no diagrama contém os seguintes componentes:

  • Pods do Elasticsearch que expõem métricas no caminho / e na porta 9114. Estas métricas são fornecidas pelo contentor sidecar denominado metrics que contém o elasticsearch_exporter.
  • Coletores baseados no Prometheus que processam as métricas do pod do Elasticsearch.
  • Um recurso PodMonitoring que envia as métricas para o Cloud Monitoring.

A configuração do cluster define um contentor sidecar com o exportador de métricas no formato 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 ver as métricas, siga estes passos:

  1. Crie o recurso PodMonitoring para extrair 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

    Após alguns minutos, é apresentado o painel de controlo incorporado "Elasticsearch Prometheus Overview" (Vista geral do Elasticsearch Prometheus).

  2. Para ver mais gráficos relacionados com dados, importe um painel de controlo do Cloud Monitoring personalizado com as configurações definidas em dashboard.json:

    gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json

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

    Aceda à vista geral dos painéis de controlo

  4. Na lista de painéis de controlo, abra o painel de controlo ElasticSearch Overview. Pode demorar 1 a 2 minutos a recolher e apresentar métricas.

    O painel de controlo mostra uma contagem das principais métricas:

    • Índices
    • Documentos e fragmentos
    • Operações pendentes
    • Executar nós com os respetivos estados de saúde

Faça uma cópia de segurança da configuração do cluster

A funcionalidade Cópia de segurança do GKE permite-lhe agendar cópias de segurança regulares da configuração completa do cluster do GKE, incluindo as cargas de trabalho implementadas e os respetivos dados.

Neste tutorial, vai configurar um plano de cópia de segurança para o seu cluster do GKE para fazer cópias de segurança de todas as cargas de trabalho, incluindo segredos e volumes, todos os dias às 03:00. Para garantir uma gestão de armazenamento eficiente, as cópias de segurança com mais de três dias são eliminadas automaticamente.

  1. Ative a funcionalidade Cópia de segurança do GKE para o seu cluster:

    gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --update-addons=BackupRestore=ENABLED

  2. Crie um plano de cópia de segurança com uma programação diária para todos os espaços de nomes no cluster:

    gcloud beta container backup-restore backup-plans create ${KUBERNETES_CLUSTER_PREFIX}-cluster-backup \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --cluster="projects/${PROJECT_ID}/locations/${REGION}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster" \
    --all-namespaces \
    --include-secrets \
    --include-volume-data \
    --cron-schedule="0 3 * * *" \
    --backup-retain-days=3

    O comando usa as variáveis de ambiente relevantes no tempo de execução.

    O formato do nome do cluster é relativo ao seu projeto e região, da seguinte forma:

    projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

    Quando lhe for pedido, escreva y.O resultado é semelhante ao seguinte:

    Create request issued for: [elasticsearch-cluster-backup]
Waiting for operation [projects/PROJECT_ID/locations/us-central1/operations/operation-1706528750815-610142ffdc9ac-71be4a05-f61c99fc] to complete...⠹

    Esta operação pode demorar alguns minutos a ser concluída com êxito. Após a conclusão da execução, o resultado é semelhante ao seguinte:

    Created backup plan [elasticsearch-cluster-backup].

  3. Pode ver o plano de cópia de segurança recém-criado elasticsearch-cluster-backup listado na consola de cópia de segurança do GKE.

    Aceder à Cópia de segurança do GKE

Se quiser restaurar as configurações de cópia de segurança guardadas, consulte o artigo Restaure uma cópia de segurança.