En este instructivo, se muestra cómo implementar un clúster de base de datos vectorial de Elasticsearch en Google Kubernetes Engine (GKE).
Las bases de datos vectoriales son almacenes de datos diseñados específicamente para administrar y buscar en grandes colecciones de vectores de alta dimensión. Estos vectores representan datos como texto, imágenes, audio, video o cualquier dato que se pueda codificar de forma numérica. 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 dentro de conjuntos de datos masivos.
Elasticsearch es una base de datos vectorial que combina funciones de búsqueda y estadísticas. Viene con una API de REST abierta para administrar tu clúster y admite consultas estructuradas, consultas de texto completo y consultas complejas. Elasticsearch te permite realizar búsquedas de frases, similitudes y prefijos con sugerencias de autocompletar.
Este instructivo está dirigido a administradores y arquitectos de plataformas de nube, ingenieros de AA y profesionales de MLOps (DevOps) interesados en implementar clústeres de bases de datos de Elasticsearch en GKE.
Ventajas
Elasticsearch ofrece los siguientes beneficios:
- Amplia variedad de bibliotecas para varios lenguajes de programación y API abierta para integrar en otros servicios.
- Escalamiento horizontal y compatibilidad con la fragmentación y la replicación que simplifica el escalamiento y la alta disponibilidad.
- Balanceo de clústeres de varios nodos para un uso óptimo de los recursos.
- Compatibilidad con contenedores y Kubernetes para una integración perfecta en entornos modernos nativos de la nube.
Objetivos
En este instructivo, aprenderás a realizar lo siguiente:
- Planificar y, además, implementar la infraestructura de GKE para Elasticsearch.
- Implementar y configurar Elasticsearch en un clúster de GKE.
- Implementar el operador StatefulHA para garantizar la alta disponibilidad de Elasticsearch.
- Ejecuta un notebook para generar y almacenar embeddings de vectores de ejemplo en tu base de datos, y realiza consultas de búsqueda basadas en vectores.
- Recopilar y visualizar métricas en un panel.
Arquitectura de implementación
En este instructivo, implementarás un clúster de GKE regional con alta disponibilidad para Elasticsearch, con varios nodos de Kubernetes distribuidos en varias zonas de disponibilidad. Esta configuración ayuda a garantizar la tolerancia a errores, la escalabilidad y la redundancia geográfica. Permite realizar actualizaciones y mantenimiento progresivos, a la vez que proporciona ANS de tiempo de actividad y disponibilidad. Para obtener más información, consulta Clústeres regionales.
Cuando un nodo se vuelve inaccesible, un Pod de ese nodo no se reprograma de inmediato. Con los Pods que usan un StatefulSet, pueden pasar más de ocho minutos hasta que los Pods de la aplicación se borren y se reprogramen en nodos nuevos.
Para abordar este problema, el operador StatefulHA hace lo siguiente:
- Resuelve el retraso de reprogramación, controla la configuración de la conmutación por error y acorta el tiempo de recuperación; para ello, usa la configuración de
.forceDeleteStrategy
:AfterNodeUnreachable
. - Garantiza que la aplicación StatefulSet use RePD.
- Extiende GKE con un recurso HighAvailabilityApplication personalizado que se implementa en el mismo espacio de nombres que Elasticsearch. Esto permite que el operador de StatefulHA supervise 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 múltiples nodos y zonas de un clúster de GKE:
Configura tu entorno
Para configurar tu entorno con Cloud Shell, sigue estos pasos:
Configura las variables de entorno del proyecto, la región y el prefijo de recursos del clúster de Kubernetes:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=elasticsearch export REGION=us-central1
- Reemplaza
PROJECT_ID
por el ID del proyecto Google Cloud.
En este instructivo, se usa la región
us-central1
para crear los recursos de implementación.- Reemplaza
Verifica 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
Clona el repositorio de código de muestra de GitHub:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Navega al directorio
elasticsearch
para comenzar a crear recursos de implementación:cd kubernetes-engine-samples/databases/elasticsearch
Crea la infraestructura del clúster
En esta sección, debes ejecutar una secuencia de comandos de Terraform para crear un clúster de GKE regional, con alta disponibilidad y privado para implementar tu base de datos de Elasticsearch.
Puedes implementar Elasticsearch mediante un clúster de Standard o Autopilot. Cada uno tiene sus propias ventajas y diferentes modelos de precios.
Autopilot
En el siguiente diagrama, se muestra un clúster de GKE Autopilot implementado en el proyecto.
Para implementar 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 reemplaza las siguientes variables en el entorno de ejecución:
GOOGLE_OAUTH_ACCESS_TOKEN
usa el comandogcloud auth print-access-token
para recuperar un token de acceso que autentica las interacciones con varias APIs de Google CloudPROJECT_ID
,REGION
yKUBERNETES_CLUSTER_PREFIX
son las variables de entorno definidas en la sección Configura tu entorno y asignadas a las nuevas variables relevantes para el clúster de Autopilot que creas.
Cuando se te solicite, escribe yes
.
El resultado es 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 supervisión para el clúster. - Configuración de Google Cloud Managed Service para Prometheus para la supervisión y las alertas de clústeres.
Estándar
En el siguiente diagrama, se muestra un clúster de GKE regional privado de Standard implementado en tres zonas diferentes.
Para implementar 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 reemplaza las siguientes variables en el entorno de ejecución:
GOOGLE_OAUTH_ACCESS_TOKEN
usa el comandogcloud auth print-access-token
para recuperar un token de acceso que autentica las interacciones con varias APIs de Google Cloud.PROJECT_ID
,REGION
yKUBERNETES_CLUSTER_PREFIX
son las variables de entorno definidas en la sección Configura tu entorno y asignadas a las nuevas variables relevantes para el clúster de Standard que creas.
Cuando se te solicite, escribe yes
. Es posible que estos comandos tarden varios minutos en completarse y que el clúster muestre un estado de preparación.
El resultado es 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 de GKE privado en la región
us-central1
con el ajuste de escala automático habilitado (de uno a dos nodos por zona). - Un
ServiceAccount
con permisos de registro y supervisión para el clúster. - Configuración de Google Cloud Managed Service para Prometheus para la supervisión y las alertas de clústeres.
Conéctate al clúster
Configura kubectl
para recuperar credenciales y comunicarte con tu clúster de GKE nuevo:
gcloud container clusters get-credentials \
${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}
Implementa la base de datos de Elasticsearch y el operador StatefulHA
En esta sección, implementarás la base de datos de Elasticsearch (en modo de clúster) y el operador StatefulHA en tu clúster de GKE con el Gráfico de Helm para operadores de ECK.
El objeto Deployment 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 memoria virtual para obtener un rendimiento óptimo de Elasticsearch. Un DaemonSet es un controlador de Kubernetes que garantiza que se ejecute una copia de un Pod en cada nodo de un clúster.
- Configuración de NodeAffinity y PodAntiAffinity para garantizar una distribución adecuada entre los nodos de Kubernetes, lo que optimiza el uso de grupos de nodos y maximiza la disponibilidad en las diferentes zonas.
- Un operador de HA con estado que administra los procesos de conmutación por error y garantiza una 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 objetos Secret de Kubernetes con credenciales de autenticación, contraseñas y certificados.
Para usar el gráfico de Helm para implementar la base de datos de Elasticsearch, sigue estos pasos:
Habilita el complemento StatefulHA:
Autopilot
GKE habilita automáticamente el complemento
StatefulHA
durante la creación del 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
Es posible que este comando tarde 15 minutos en completarse y que el clúster muestre un estado de preparación.
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
Implementar el operador de ECK:
kubectl apply -f https://download.elastic.co/downloads/eck/2.11.1/operator.yaml
Crea el espacio de nombres
elastic
para la base de datos:kubectl create ns elastic
Instala el recurso
HighAvailabilityApplication
(HAA), que define las reglas de conmutación por error para Elasticsearch.kubectl apply -n elastic -f manifests/01-regional-pd/ha-app.yaml
El manifiesto
ha-app.yaml
describe el recursoHighAvailabilityApplication
:Aplica el manifiesto para crear un disco SSD persistente regional
StorageClass
:kubectl apply -n elastic -f manifests/01-regional-pd/regional-pd.yaml
En el manifiesto de
regional-pd.yaml
, se describe el disco SSD persistenteStorageClass
:Implementa el recurso DaemonSet para establecer la memoria virtual en cada nodo:
kubectl apply -n elastic -f manifests/02-elasticsearch/mmap-count.yaml
El manifiesto
mmap-count.yaml
describe elDaemonSet
:Aplica el manifiesto para implementar el clúster de Elasticsearch:
kubectl apply -n elastic -f manifests/02-elasticsearch/elasticsearch.yaml
En el manifiesto
elasticsearch.yaml
, se describe el Deployment:Espera unos minutos para que el clúster de Elasticsearch se inicie por completo.
Verifica el estado de la implementación:
kubectl get elasticsearch -n elastic --watch
El resultado es similar al siguiente, si la base de datos
elasticsearch
se implementó de forma correcta:NAME HEALTH NODES VERSION PHASE AGE elasticsearch-ha green 3 8.11.4 Ready 2m30s
Espera a que
HEALTH
se muestre comogreen
. Presiona Ctrl+C para salir del comando si es necesario.Implementa un balanceador de cargas 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
En el manifiesto de
ilb.yaml
, se describe el ServiceLoadBalancer
:Para verificar 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
El resultado es similar al 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>
Una vez que GKE inicie las cargas de trabajo, verifica que GKE haya creado las cargas de trabajo de Elasticsearch:
kubectl get pod,svc,statefulset,pdb,secret,daemonset -n elastic
El resultado es 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
Los siguientes recursos de GKE se crean para el clúster de Elasticsearch:
- El
StatefulSet
de Elasticsearch que controla tres réplicas de Pods. - Un DaemonSet para establecer la configuración de memoria virtual.
- Servicios para conectarse a Elasticsearch.
- Secrets con credenciales de superusuario y certificados relacionados con el servicio.
- Pod de operador de HA con estado y recurso
HighlyAvailableApplication
, que supervisan de forma activa la aplicación de Elasticsearch.
Ejecuta consultas con el notebook de Colab Enterprise de Vertex AI
En esta sección, se explica cómo generar incorporaciones en documentos de Elasticsearch y realizar búsquedas semánticas con el cliente oficial de Python de Elasticsearch en el notebook de Colab Enterprise. Un documento en Elasticsearch se compone de varios campos, cada uno vinculado con su valor correspondiente.
Para obtener más información sobre Vertex AI Colab Enterprise, consulta la documentación de Colab Enterprise.
Para utilizar Elasticsearch de manera eficaz, te recomendamos estructurar los datos en estos documentos, que luego se indexarán para fines de búsqueda.
En este ejemplo, se usa un conjunto de datos de un archivo CSV que contiene una lista de libros de diferentes géneros. Elasticsearch sirve como motor de búsqueda y el Pod que creas sirve como un cliente que consulta la base de datos de Elasticsearch.
Puedes usar una plantilla de entorno de ejecución dedicada para realizar la implementación en la VPC (nube privada virtual) de elasticsearch-vpc
, de modo que el notebook pueda comunicarse con los recursos de tu clúster de GKE.
Crea una plantilla de entorno de ejecución
Para crear una plantilla de entorno de ejecución de Colab Enterprise, sigue estos pasos:
En la consola de Google Cloud , ve a la página Plantillas de entorno de ejecución de Colab Enterprise y asegúrate de que tu proyecto esté seleccionado:
Haz clic en add_box New Template. Aparecerá la página Crear nueva plantilla de entorno de ejecución.
En la sección Conceptos básicos del entorno de ejecución, haz lo siguiente:
- En el campo Nombre visible, escribe
elastic-connect
- En la lista desplegable Región, selecciona
us-central1
. Es la misma región que tu clúster de GKE.
- En el campo Nombre visible, escribe
En la sección Configurar procesamiento, haz lo siguiente:
- En la lista desplegable Tipo de máquina, selecciona
e2-standard-2
. - En el campo Tamaño del disco, ingresa
30
.
- En la lista desplegable Tipo de máquina, selecciona
En la sección Herramientas de redes y seguridad, haz lo siguiente:
- En la lista desplegable Red, selecciona la red en la que reside tu clúster de GKE.
- En la lista desplegable Subred, selecciona una subred correspondiente.
- Desmarca la casilla de verificación Habilitar el acceso a Internet pública.
Para terminar de crear la plantilla de entorno de ejecución, haz clic en Crear. Tu plantilla de entorno de ejecución aparece en la lista en la pestaña Plantillas de entorno de ejecución.
Crea un entorno de ejecución
Para crear un entorno de ejecución de Colab Enterprise, haz lo siguiente:
En la lista de plantillas de ejecución de la plantilla que acabas de crear, en la columna Acciones, haz clic en more_vert y, luego, en Crear tiempo de ejecución. Aparecerá el panel Crear entorno de ejecución de Vertex AI.
Para crear un entorno de ejecución basado en tu plantilla, haz clic en Crear.
En la pestaña Tiempos de ejecución que se abre, espera a que el estado cambie a Correcto.
Importa el notebook
Para importar el notebook en Colab Enterprise, haz lo siguiente:
Ve a la pestaña Mis notebooks y haz clic en Importar. Aparecerá el panel Import notebooks.
En Fuente de importación, selecciona URL.
En URLs de notebooks, ingresa el siguiente vínculo:
https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/main/databases/elasticsearch/manifests/03-notebook/vector-database.ipynb
Haz clic en Importar.
Conéctate al entorno de ejecución y ejecuta consultas
Para conectarte al entorno de ejecución y ejecutar consultas, sigue estos pasos:
En el notebook, junto al botón Conectar, haz clic en arrow_drop_down Opciones de conexión adicionales. Aparecerá el panel Conéctate al entorno de ejecución de Vertex AI.
Selecciona Conectar a un entorno de ejecución y, luego, Conectar a un entorno de ejecución existente.
Selecciona el entorno de ejecución que iniciaste y haz clic en Conectar.
Para ejecutar las celdas del notebook, haz clic en el botón
Ejecutar celda junto a cada celda de código.
El notebook contiene celdas de código y texto que describe cada bloque de código. Cuando se ejecuta una celda de código, se ejecutan sus comandos y se muestra un resultado. Puedes ejecutar las celdas en orden o ejecutar celdas individuales según sea necesario.
Visualiza las métricas de Prometheus de tu clúster
El clúster de GKE se configura con Google Cloud Managed Service para Prometheus, que permite la recopilación de métricas en el formato Prometheus. Este servicio proporciona una solución completamente administrada para la supervisión y las alertas, lo que permite la recopilación, el almacenamiento y el análisis de métricas del clúster y sus aplicaciones.
En el siguiente diagrama, se muestra cómo Prometheus recopila métricas para tu clúster:
El clúster privado de GKE en el diagrama contiene los siguientes componentes:
- Pods de Elasticsearch que exponen métricas en la ruta
/
y el puerto9114
. El contenedor de archivo adicional llamadometrics
proporciona estas métricas y contiene el elasticsearch_exporter. - Recopiladores 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 de archivo adicional con el exportador de métricas en el 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:
Crea el recurso
PodMonitoring
para extraer métricas porlabelSelector
:kubectl apply -n elastic -f manifests/04-prometheus-metrics/pod-monitoring.yaml
El manifiesto
pod-monitoring.yaml
describe el recursoPodMonitoring
:Después de unos minutos, se mostrará el panel integrado “Elasticsearch Prometheus Overview”.
Para ver más gráficos relacionados con los datos, importa un panel de Cloud Monitoring personalizado con los parámetros de configuración definidos en
dashboard.json
:gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json
Después de que el comando se ejecute de forma correcta, ve a los Paneles de Cloud Monitoring:
En la lista de paneles, abre el panel
ElasticSearch Overview
. La recopilación y visualización de las métricas puede llevar entre 1 y 2 minutos.En el panel, se muestra un recuento de las métricas clave:
- Índices
- Documentos y fragmentos
- Operaciones pendientes
- Ejecuta nodos con sus estados
Crea una copia de seguridad de la configuración del clúster
La función Copia de seguridad para GKE te permite programar copias de seguridad regulares de toda la configuración del clúster de GKE, incluidas las cargas de trabajo implementadas y sus datos.
En este instructivo, configurarás un plan de copia de seguridad para tu clúster de GKE a fin de realizar copias de seguridad de todas las cargas de trabajo, incluidos Secrets y Volumes, todos los días a las 3 a.m. Para garantizar una administración del almacenamiento eficiente, las copias de seguridad que tengan más de tres días se borran automáticamente.
Habilita la función Copia de seguridad para GKE en tu clúster:
gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \ --project=${PROJECT_ID} \ --location=${REGION} \ --update-addons=BackupRestore=ENABLED
Crea un plan de copia de seguridad con un programa diario para todos los espacios de nombres dentro 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 relevantes en el entorno de ejecución.
El formato del nombre del clúster se relaciona con tu proyecto y región de la siguiente manera:
projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME
Cuando se te solicite, 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 que se completa la ejecución, el resultado es similar al siguiente:
Created backup plan [elasticsearch-cluster-backup].
Puedes ver el plan de copia de seguridad recién creado
elasticsearch-cluster-backup
en la consola de Copia de seguridad para GKE.
Si deseas restablecer las opciones de configuración de copia de seguridad guardadas, consulta Restablece una copia de seguridad.