Desplegar una base de datos de vectores de Elasticsearch en GKE

En este tutorial se explica cómo desplegar un clúster de base de datos de vectores de Elasticsearch en Google Kubernetes Engine (GKE).

Las bases de datos vectoriales son almacenes de datos diseñados específicamente para gestionar y buscar grandes colecciones de vectores de alta dimensión. Estos vectores representan datos como texto, imágenes, audio, vídeo o cualquier dato que se pueda codificar numéricamente. A diferencia de las bases de datos relacionales, que se basan en coincidencias exactas, las bases de datos vectoriales se especializan en encontrar elementos similares o identificar patrones en conjuntos de datos masivos.

Elasticsearch es una base de datos de vectores que combina funciones de búsqueda y analíticas. Incluye una API REST abierta para gestionar el clúster y admite consultas estructuradas, consultas de texto completo y consultas complejas. Elasticsearch te permite hacer búsquedas de frases, similitudes y prefijos, así como recibir sugerencias de Autocompletar.

Este tutorial está dirigido a administradores y arquitectos de plataformas en la nube, ingenieros de aprendizaje automático y profesionales de MLOps (DevOps) que estén interesados en desplegar clústeres de bases de datos de Elasticsearch en GKE.

Ventajas

Elasticsearch ofrece las siguientes ventajas:

  • Amplia gama de bibliotecas para varios lenguajes de programación y API abierta para integrarse con otros servicios.
  • Escalado horizontal y compatibilidad con la fragmentación y la replicación, lo que simplifica el escalado y la alta disponibilidad.
  • Equilibrio de clústeres de varios nodos para optimizar el uso de los recursos.
  • Compatibilidad con contenedores y Kubernetes para una integración perfecta en entornos nativos de la nube modernos.

Objetivos

En este tutorial, aprenderás a hacer lo siguiente:

  • Planifica y despliega la infraestructura de GKE para Elasticsearch.
  • Despliega y configura Elasticsearch en un clúster de GKE.
  • Despliega el operador StatefulHA para asegurar la alta disponibilidad de Elasticsearch.
  • Ejecuta un cuaderno para generar y almacenar incrustaciones de vectores de ejemplo en tu base de datos y realiza consultas de búsqueda basadas en vectores.
  • Recoger y visualizar métricas en un panel de control.

Arquitectura de despliegue

En este tutorial, desplegarás un clúster de GKE regional de alta disponibilidad para Elasticsearch con varios nodos de Kubernetes distribuidos en varias zonas de disponibilidad. Esta configuración ayuda a garantizar la tolerancia a fallos, la escalabilidad y la redundancia geográfica. Permite realizar actualizaciones y tareas de mantenimiento de forma gradual, al tiempo que ofrece acuerdos de nivel de servicio para el tiempo de actividad y la disponibilidad. Para obtener más información, consulta Clústeres regionales.

Cuando un nodo deja de estar disponible, un pod de ese nodo no se vuelve a programar inmediatamente. Si los pods usan un StatefulSet, pueden tardar más de ocho minutos en eliminarse y reprogramarse en nodos nuevos.

Para solucionar este problema, el operador StatefulHA hace lo siguiente:

  • Resuelve el problema de la latencia al reprogramar, gestiona los ajustes de conmutación por error y reduce el tiempo de recuperación mediante los ajustes de .forceDeleteStrategy: AfterNodeUnreachable.
  • Asegura que la aplicación StatefulSet usa RePD.
  • Amplía GKE con un recurso HighAvailabilityApplication personalizado que se despliega en el mismo espacio de nombres que Elasticsearch. Esto permite que el operador StatefulHA monitorice y responda a los eventos de conmutación por error.

En el siguiente diagrama se muestra un clúster de Elasticsearch que se ejecuta en varios nodos y zonas de un clúster de GKE:

Arquitectura de implementación de Elasticsearch

Configurar un entorno

Para configurar tu entorno con Cloud Shell, sigue estos pasos:

  1. Define las variables de entorno de tu proyecto, región y prefijo de recurso de clúster de Kubernetes:

    export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=elasticsearch
export REGION=us-central1
    • Sustituye PROJECT_ID por el ID de tu proyecto. Google Cloud

    En este tutorial se usa la región us-central1 para crear los recursos de implementación.

  2. Comprueba la versión de Helm:

    helm version

    Actualiza la versión si es anterior a la 3.13:

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

  3. Clona el repositorio de código de ejemplo de GitHub:

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

  4. Ve al directorio elasticsearch para empezar a crear recursos de implementación:

    cd kubernetes-engine-samples/databases/elasticsearch

Crear la infraestructura del clúster

En esta sección, ejecutarás una secuencia de comandos de Terraform para crear un clúster de GKE privado, de alta disponibilidad y regional para desplegar tu base de datos de Elasticsearch.

Puedes desplegar Elasticsearch con un clúster estándar o de Autopilot. Cada una tiene sus propias ventajas y modelos de precios diferentes.

Autopilot

En el siguiente diagrama se muestra un clúster de Autopilot de GKE desplegado en el proyecto.

Clúster de Autopilot de GKE

Para desplegar la infraestructura del clúster, ejecuta los siguientes comandos en 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}

GKE sustituye las siguientes variables en el tiempo de ejecución:

  • GOOGLE_OAUTH_ACCESS_TOKEN usa el comando gcloud auth print-access-token para obtener un token de acceso que autentica las interacciones con varias APIs de Google Cloud.
  • PROJECT_ID, REGION y KUBERNETES_CLUSTER_PREFIX son las variables de entorno definidas en la sección Configurar el entorno y asignadas a las nuevas variables relevantes del clúster de Autopilot que estás creando.

Cuando se te solicite, escribe yes.

El resultado debería ser similar al siguiente:

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

Outputs:

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

Terraform crea los siguientes recursos:

  • Una red de VPC personalizada y una subred privada para los nodos de Kubernetes.
  • Un Cloud Router para acceder a Internet a través de la traducción de direcciones de red (NAT).
  • Un clúster de GKE privado en la región us-central1.
  • Un ServiceAccount con permisos de registro y monitorización para el clúster.
  • Configuración de Google Cloud Managed Service para Prometheus para la monitorización y las alertas de clústeres.

Estándar

En el siguiente diagrama se muestra un clúster de GKE regional privado estándar desplegado en tres zonas diferentes.

Clúster de GKE Standard

Para desplegar la infraestructura del clúster, ejecuta los siguientes comandos en 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}

GKE sustituye las siguientes variables en el tiempo de ejecución:

  • GOOGLE_OAUTH_ACCESS_TOKEN usa el comando gcloud auth print-access-token para obtener un token de acceso que autentica las interacciones con varias APIs de Google Cloud.
  • PROJECT_ID, REGION y KUBERNETES_CLUSTER_PREFIX son las variables de entorno definidas en la sección Configurar el entorno y asignadas a las nuevas variables relevantes del clúster estándar que estás creando.

Cuando se te solicite, escribe yes. Estos comandos pueden tardar varios minutos en completarse y el clúster en mostrar el estado "Listo".

El resultado debería ser similar al siguiente:

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

Outputs:

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

Terraform crea los siguientes recursos:

  • Una red de VPC personalizada y una subred privada para los nodos de Kubernetes.
  • Un Cloud Router para acceder a Internet a través de la traducción de direcciones de red (NAT).
  • Un clúster privado de GKE en la región us-central1 con el autoescalado habilitado (de uno a dos nodos por zona).
  • Un ServiceAccount con permisos de registro y monitorización para el clúster.
  • Configuración de Google Cloud Managed Service para Prometheus para la monitorización y las alertas de clústeres.

Conéctate al clúster

Configura kubectl para obtener las credenciales y comunicarte con tu nuevo clúster de GKE:

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

Implementar la base de datos Elasticsearch y el operador StatefulHA

En esta sección, desplegarás la base de datos de Elasticsearch (en modo clúster) y el operador StatefulHA en tu clúster de GKE mediante el gráfico de Helm del operador ECK.

La implementación crea un clúster de GKE con la siguiente configuración:

  • Tres réplicas de los nodos de Elasticsearch.
  • DaemonSet para cambiar la configuración de la memoria virtual y optimizar el rendimiento de Elasticsearch. Un DaemonSet es un controlador de Kubernetes que se asegura de que se ejecute una copia de un Pod en cada nodo de un clúster.
  • Configuración de NodeAffinity y PodAntiAffinity para asegurar una distribución adecuada entre los nodos de Kubernetes, optimizar el uso de los grupos de nodos y maximizar la disponibilidad en diferentes zonas.
  • Un operador de alta disponibilidad con estado que gestiona los procesos de conmutación por error y garantiza la alta disponibilidad. Un StatefulSet es un controlador de Kubernetes que mantiene una identidad única y persistente para cada uno de sus pods.
  • Para la autenticación, la base de datos crea secretos de Kubernetes con credenciales de autenticación, contraseñas y certificados.

Para usar el gráfico de Helm e implementar la base de datos de Elasticsearch, sigue estos pasos:

  1. Habilita el complemento StatefulHA:

    Autopilot

    GKE habilita automáticamente el complemento StatefulHA al crear el clúster.

    Estándar

    Ejecuta el siguiente comando:

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

    Este comando puede tardar 15 minutos en completarse y el clúster en mostrar el estado "Listo".

  2. Crea una definición de recurso personalizado (CRD) de Elastic Cloud on Kubernetes (ECK):

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

  3. Implementa el operador de ECK:

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

  4. Crea el espacio de nombres elastic para la base de datos:

    kubectl create ns elastic

  5. Instala el recurso HighAvailabilityApplication (HAA), que define las reglas de conmutación por error de Elasticsearch.

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

    El manifiesto ha-app.yaml describe el 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. Aplica el manifiesto para crear un disco SSD persistente regional StorageClass:

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

    El manifiesto regional-pd.yaml describe el 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. Implementa el recurso DaemonSet para definir la memoria virtual en cada nodo:

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

    El manifiesto mmap-count.yaml describe el 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. Aplica el manifiesto para desplegar el clúster de Elasticsearch:

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

    El manifiesto elasticsearch.yaml describe la implementación:

    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

    Espera unos minutos a que el clúster de Elasticsearch se inicie por completo.

  9. Comprueba el estado del despliegue:

    kubectl get elasticsearch -n elastic --watch

    El resultado será similar al siguiente si la base de datos elasticsearch se implementa correctamente:

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

    Espera a que HEALTH se muestre como green. Pulsa Ctrl+C para salir del comando si es necesario.

  10. Implementa un balanceador de carga interno para acceder a tu base de datos de Elasticsearch que se ejecuta en la misma VPC que tu clúster de GKE:

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

    El manifiesto de ilb.yaml describe el servicio 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 comprobar si se aplican las reglas de conmutación por error, describe el recurso y confirma Status: Message: Application is protected.

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

    La salida es similar a la siguiente:

    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. Una vez que GKE inicie las cargas de trabajo, comprueba que GKE ha creado las cargas de trabajo de Elasticsearch:

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

    El resultado debería ser similar al siguiente:

    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

Se crean los siguientes recursos de GKE para el clúster de Elasticsearch:

  • El StatefulSet de Elasticsearch que controla tres réplicas de Pod.
  • Un DaemonSet para configurar los ajustes de memoria virtual.
  • Servicios para conectarse a Elasticsearch.
  • Secretos con credenciales de superusuario y certificados relacionados con el servicio.
  • Pod del operador de alta disponibilidad con estado y recurso HighlyAvailableApplication, que monitoriza activamente la aplicación Elasticsearch.

Ejecutar consultas con un cuaderno de Vertex AI Colab Enterprise

En esta sección se explica cómo generar inserciones en documentos de Elasticsearch y realizar consultas de búsqueda semántica con el cliente oficial de Python de Elasticsearch en un cuaderno de Colab Enterprise. Un documento de Elasticsearch se compone de varios campos, cada uno de ellos emparejado con su valor correspondiente.

Para obtener más información sobre Vertex AI Colab Enterprise, consulta la documentación de Colab Enterprise.

Práctica recomendada:

Para utilizar Elasticsearch de forma eficaz, te recomendamos que estructures tus datos en estos documentos, que se indexan para poder realizar búsquedas.

En este ejemplo, se usa un conjunto de datos de un archivo CSV que contiene una lista de libros de diferentes géneros. Elasticsearch actúa como motor de búsqueda y el pod que creas actúa como cliente que consulta la base de datos de Elasticsearch.

Puedes usar una plantilla de tiempo de ejecución dedicada para implementar en la elasticsearch-vpc VPC (nube privada virtual), de forma que el cuaderno pueda comunicarse con los recursos de tu clúster de GKE.

Crear una plantilla de tiempo de ejecución

Para crear una plantilla de entorno de ejecución de Colab Enterprise, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Plantillas de tiempo de ejecución de Colab Enterprise y asegúrate de que tu proyecto esté seleccionado:

    Ir a Plantillas de entorno de ejecución

  2. Haz clic en Nueva plantilla. Aparecerá la página Crear plantilla de tiempo de ejecución.

  3. En la sección Información básica de Runtime:

    • En el campo Nombre visible, introduce elastic-connect.
    • En la lista desplegable Región, selecciona us-central1. Es la misma región que tu clúster de GKE.

  4. En la sección Configurar recursos de computación:

    • En la lista desplegable Tipo de máquina, selecciona e2-standard-2.
    • En el campo Tamaño del disco, introduce 30.

  5. En la sección Redes y seguridad:

    • En la lista desplegable Red, selecciona la red en la que se encuentra tu clúster de GKE.
    • En la lista desplegable Subred, selecciona la subred correspondiente.
    • Desmarca la casilla Habilitar el acceso público a Internet.

  6. Para terminar de crear la plantilla de tiempo de ejecución, haga clic en Crear. Tu plantilla de entorno de ejecución aparece en la lista de la pestaña Plantillas de entorno de ejecución.

Crear un tiempo de ejecución

Para crear un entorno de ejecución de Colab Enterprise, sigue estos pasos:

  1. En la lista de plantillas de tiempo de ejecución de la plantilla que acaba de crear, vaya a la columna Acciones, haga clic en y, a continuación, en Crear tiempo de ejecución. Aparecerá el panel Crear tiempo de ejecución de Vertex AI.

  2. Para crear un tiempo de ejecución basado en tu plantilla, haz clic en Crear.

  3. En la pestaña Tiempos de ejecución que se abre, espera a que el estado cambie a Correcto.

Importar el cuaderno

Para importar el cuaderno en Colab Enterprise, sigue estos pasos:

  1. Ve a la pestaña Mis cuadernos y haz clic en Importar. Aparecerá el panel Importar cuadernos.

  2. En Importar fuente, selecciona URL.

  3. En URLs de cuadernos, introduce el siguiente enlace:

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

  4. Haz clic en Importar.

Conectarse al entorno de ejecución y ejecutar consultas

Para conectarte al entorno de ejecución y ejecutar consultas, sigue estos pasos:

  1. En el cuaderno, junto al botón Conectar, haz clic en Opciones de conexión adicionales. Aparecerá el panel Conectar con el entorno de ejecución de Vertex AI.

  2. Selecciona Conectar con un tiempo de ejecución y, a continuación, Conectar con un tiempo de ejecución.

  3. Selecciona el tiempo de ejecución que has iniciado y haz clic en Conectar.

  4. Para ejecutar las celdas del cuaderno, haz clic en el botón Ejecutar celda situado junto a cada celda de código.

El cuaderno contiene celdas de código y texto que describe cada bloque de código. Al ejecutar una celda de código, se ejecutan sus comandos y se muestra un resultado. Puedes ejecutar las celdas en orden o ejecutar celdas concretas según sea necesario.

Ver las métricas de Prometheus de un clúster

El clúster de GKE está configurado con Managed Service para Prometheus de Google Cloud, lo que permite recoger métricas en formato Prometheus. Este servicio proporciona una solución totalmente gestionada para la monitorización y las alertas, lo que permite recoger, almacenar y analizar métricas del clúster y sus aplicaciones.

En el siguiente diagrama se muestra cómo recopila Prometheus las métricas de tu clúster:

Recogida de métricas de Prometheus

El clúster privado de GKE del diagrama contiene los siguientes componentes:

  • Pods de Elasticsearch que exponen métricas en la ruta / y el puerto 9114. Estas métricas las proporciona el contenedor sidecar llamado metrics, que contiene el elasticsearch_exporter.
  • Recogedores basados en Prometheus que procesan las métricas del pod de Elasticsearch.
  • Un recurso PodMonitoring que envía las métricas a Cloud Monitoring.

La configuración del clúster define un contenedor sidecar con un exportador de métricas en 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 y ver las métricas, sigue estos pasos:

  1. Crea el recurso PodMonitoring para recoger métricas por labelSelector:

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

    El manifiesto pod-monitoring.yaml describe el 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

    Al cabo de unos minutos, se mostrará el panel de control integrado "Elasticsearch Prometheus Overview" (Resumen de Elasticsearch Prometheus).

  2. Para ver más gráficos relacionados con los datos, importa un panel de Cloud Monitoring personalizado con las configuraciones definidas en dashboard.json:

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

  3. Una vez que se haya ejecutado correctamente el comando, vaya a Paneles de control de Cloud Monitoring:

    Ir a Información general sobre los paneles de control

  4. En la lista de paneles de control, abre el panel ElasticSearch Overview. Las métricas pueden tardar entre 1 y 2 minutos en recogerse y mostrarse.

    El panel muestra un recuento de las métricas clave:

    • Índices
    • Documentos y fragmentos
    • Operaciones pendientes
    • Ejecuta nodos con sus estados de salud

Crear una copia de seguridad de la configuración del clúster

La función Copia de seguridad de GKE te permite programar copias de seguridad periódicas de toda la configuración de tu clúster de GKE, incluidas las cargas de trabajo implementadas y sus datos.

En este tutorial, configurarás un plan de copia de seguridad para tu clúster de GKE con el fin de crear copias de seguridad de todas las cargas de trabajo, incluidos los secretos y los volúmenes, todos los días a las 3:00. Para garantizar una gestión eficiente del almacenamiento, las copias de seguridad de más de tres días se eliminan automáticamente.

  1. Habilita la función de copia de seguridad de GKE en el clúster:

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

  2. Crea un plan de copia de seguridad con una programación diaria para todos los espacios de nombres del clúster:

    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

    El comando usa las variables de entorno pertinentes en el tiempo de ejecución.

    El formato del nombre del clúster es relativo a tu proyecto y región, como se indica a continuación:

    projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

    Cuando se te pida, escribe y.El resultado es similar al siguiente:

    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 operación puede tardar unos minutos en completarse correctamente. Una vez completada la ejecución, el resultado será similar al siguiente:

    Created backup plan [elasticsearch-cluster-backup].

  3. Puedes ver el plan de copia de seguridad que acabas de crear elasticsearch-cluster-backupen la consola de Copia de seguridad de GKE.

    Ir a Copia de seguridad de GKE

Si quieres restaurar las configuraciones de copia de seguridad guardadas, consulta Restaurar una copia de seguridad.