Elasticsearch-Vektordatenbank in GKE bereitstellen

Umgebung einrichten

So richten Sie Ihre Umgebung mit Cloud Shell ein:

1. Legen Sie Umgebungsvariablen für Ihr Projekt, Ihre Region und ein Kubernetes-Clusterressourcenpräfix fest:

   export PROJECT_ID=PROJECT_ID
   export KUBERNETES_CLUSTER_PREFIX=elasticsearch
   export REGION=us-central1
   

   • Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID. Google Cloud

   In dieser Anleitung wird die Region us-central1 verwendet, um Ihre Bereitstellungsressourcen zu erstellen.

2. Prüfen Sie die Helm-Version:

   helm version
   

   Aktualisieren Sie die Version, wenn sie älter als 3.13 ist:

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

3. Klonen Sie das Beispielcode-Repository aus GitHub:

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

4. Wechseln Sie in das Verzeichnis elasticsearch, um mit dem Erstellen der Bereitstellungsressourcen zu beginnen:

   cd kubernetes-engine-samples/databases/elasticsearch
   

Clusterinfrastruktur erstellen

In diesem Abschnitt führen Sie ein Terraform-Skript aus, um einen privaten, hochverfügbaren regionalen GKE-Cluster zum Bereitstellen Ihrer Elasticsearch-Datenbank zu erstellen.

Sie können Elasticsearch mit einem Standard- oder Autopilot-Cluster bereitstellen. Jede hat ihre eigenen Vorteile und unterschiedliche Preismodelle.

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}

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

Outputs:

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

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}

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

Outputs:

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

Mit dem Cluster verbinden

Konfigurieren Sie kubectl so, dass Anmeldedaten abgerufen und mit Ihrem neuen GKE-Cluster kommuniziert wird:

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

Elasticsearch-Datenbank und StatefulHA-Operator bereitstellen

In diesem Abschnitt stellen Sie die Elasticsearch-Datenbank (im Clustermodus) und den zustandsorientierten Operator mithilfe des ECK-Operator-Helm-Diagramms in Ihrem GKE-Cluster bereit.

Das Deployment erstellt einen GKE-Cluster mit der folgenden Konfiguration:

• Drei Replikate der Elasticsearch-Knoten.
• DaemonSet zum Ändern der Einstellungen für virtuellen Speicher, um eine optimale Elasticsearch-Leistung zu erzielen. Ein DaemonSet ist ein Kubernetes-Controller, der dafür sorgt, dass auf jedem Knoten in einem Cluster eine Kopie eines Pods ausgeführt wird.
• Konfiguration von NodeAffinity und PodAntiAffinity, um eine ordnungsgemäße Verteilung auf Kubernetes-Knoten zu gewährleisten, die Verwendung von Knotenpools zu optimieren und die Verfügbarkeit über verschiedene Zonen hinweg zu maximieren.
• Ein zustandsorientierter HA-Operator, der Failover-Prozesse verwaltet und Hochverfügbarkeit gewährleistet. Ein StatefulSet ist ein Kubernetes-Controller, der für jeden seiner Pods eine dauerhafte eindeutige Identität beibehält.
• Zur Authentifizierung erstellt die Datenbank Kubernetes-Secrets mit Authentifizierungsdaten, Passwörtern und Zertifikaten.

So stellen Sie die Elasticsearch-Datenbank mithilfe des Helm-Diagramms bereit:

1. StatefulHA-Add-on aktivieren:

   Autopilot

   GKE aktiviert das Add-on StatefulHA bei der Clustererstellung automatisch.

   Standard

   Führen Sie dazu diesen Befehl aus:

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

   Es kann 15 Minuten dauern, bis dieser Befehl abgeschlossen ist und der Cluster den Status „Bereit“ anzeigt.

2. Erstellen Sie eine benutzerdefinierte Ressourcendefinition (CRD) für Elastic Cloud on Kubernetes (ECK):

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

3. ECK-Operator bereitstellen:

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

4. Erstellen Sie den Namespace elastic für die Datenbank:

   kubectl create ns elastic
   

5. Installieren Sie die Ressource HighAvailabilityApplication (HAA), die Failover-Regeln für Elasticsearch definiert.

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

   Das ha-app.yaml-Manifest beschreibt die HighAvailabilityApplication-Ressource:

   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. Wenden Sie das Manifest an, um einen regionalen nichtflüchtigen SSD-Speicher StorageClass zu erstellen:

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

   Das Manifest regional-pd.yaml beschreibt den nichtflüchtigen SSD-Speicher 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. Stellen Sie die DaemonSet-Ressource bereit, um in jedem Knoten virtuellen Arbeitsspeicher festzulegen:

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

   Das mmap-count.yaml-Manifest beschreibt 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. Wenden Sie das Manifest an, um den Elasticsearch-Cluster bereitzustellen:

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

   Das elasticsearch.yaml-Manifest beschreibt das Deployment:

   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

   Warten Sie einige Minuten, bis der Elasticsearch-Cluster vollständig gestartet wurde.

9. Prüfen Sie den Bereitstellungsstatus:

   kubectl get elasticsearch -n elastic --watch
   

   Wenn die elasticsearch-Datenbank erfolgreich bereitgestellt wurde, sieht die Ausgabe in etwa so aus:

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

   Warten Sie, bis HEALTH als green angezeigt wird. Drücken Sie Strg + C, um den Befehl bei Bedarf zu beenden.

10. Stellen Sie einen internen Load Balancer bereit, um auf Ihre Elasticsearch-Datenbank zuzugreifen, die in derselben VPC wie Ihr GKE-Cluster ausgeführt wird:

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

    Das ilb.yaml-Manifest beschreibt den LoadBalancer-Service:

    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. Wenn Sie prüfen möchten, ob die Failover-Regeln angewendet werden, beschreiben Sie die Ressource und bestätigen Sie Status: Message: Application is protected.

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

    Die Ausgabe sieht in etwa so aus:

    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. Prüfen Sie, nachdem GKE die Arbeitslasten gestartet hat, ob GKE die Elasticsearch-Arbeitslasten erstellt hat:

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

    Die Ausgabe sieht in etwa so aus:

    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
    

Die folgenden GKE-Ressourcen werden für den Elasticsearch-Cluster erstellt:

• Die Elasticsearch-StatefulSet, die drei Pod-Replikate steuert.
• Ein DaemonSet zum Konfigurieren der Einstellungen für virtuellen Speicher.
• Dienste zum Herstellen einer Verbindung mit Elasticsearch.
• Secrets mit Superuser-Anmeldedaten und dienstbezogenen Zertifikaten.
• Zustandsorientierter HA-Operator-Pod und HighlyAvailableApplication-Ressource, die die Elasticsearch-Anwendung aktiv überwachen.

Abfragen mit Vertex AI Colab Enterprise-Notebook ausführen

In diesem Abschnitt wird beschrieben, wie Sie Einbettungen in Elasticsearch-Dokumente generieren und semantische Suchanfragen mit dem offiziellen Elasticsearch-Python-Client in einem Colab Enterprise-Notebook durchführen. Ein Dokument in Elasticsearch besteht aus verschiedenen Feldern, die jeweils mit dem entsprechenden Wert gekoppelt sind.

Weitere Informationen zu Vertex AI Colab Enterprise finden Sie in der Colab Enterprise-Dokumentation.

In diesem Beispiel verwenden Sie ein Dataset aus einer CSV-Datei, die eine Liste von Büchern verschiedener Genres enthält. Elasticsearch dient als Suchmaschine und der von Ihnen erstellte Pod dient als Client, der die Elasticsearch-Datenbank abfragt.

Sie können eine spezielle Runtime-Vorlage in der elasticsearch-vpc-VPC (Virtual Private Cloud) bereitstellen, damit das Notebook mit Ressourcen in Ihrem GKE-Cluster kommunizieren kann.

Laufzeitvorlage erstellen.

So erstellen Sie eine Colab Enterprise-Laufzeitvorlage:

1. Rufen Sie in der Google Cloud Console die Colab Enterprise-Seite Laufzeitvorlagen auf und prüfen Sie, ob Ihr Projekt ausgewählt ist:

   Zu Laufzeitvorlagen

2. Klicken Sie auf add_box Neue Vorlage. Die Seite Neue Laufzeitvorlage erstellen wird angezeigt.

3. Im Abschnitt Laufzeitgrundlagen:

   • Geben Sie im Feld Anzeigename den Wert elastic-connect ein.
   • Wählen Sie in der Drop-down-Liste Region us-central1 aus. Es ist dieselbe Region wie Ihr GKE-Cluster.

4. Im Abschnitt Compute konfigurieren:

   • Wählen Sie in der Drop-down-Liste Maschinentyp die Option e2-standard-2 aus.
   • Geben Sie im Feld Laufwerkgröße den Wert 30 ein.

5. Im Abschnitt Netzwerk und Sicherheit:

   • Wählen Sie in der Drop-down-Liste Netzwerk das Netzwerk aus, in dem sich Ihr GKE-Cluster befindet.
   • Wählen Sie in der Drop-down-Liste Subnetzwerk ein entsprechendes Subnetzwerk aus.
   • Entfernen Sie das Häkchen aus dem Kästchen Öffentlichen Internetzugriff aktivieren.

6. Klicken Sie auf Erstellen, um die Erstellung der Laufzeitvorlage abzuschließen. Ihre Laufzeitvorlage wird auf dem Tab Laufzeitvorlagen in der Liste angezeigt.

Laufzeit erstellen

So erstellen Sie eine Colab Enterprise-Laufzeit:

1. Klicken Sie in der Liste der Laufzeitvorlagen für die gerade erstellte Vorlage in der Spalte Aktionen auf more_vert und dann auf Laufzeit erstellen. Der Bereich Vertex AI-Laufzeit erstellen wird angezeigt.

2. Klicken Sie auf Erstellen, um eine Laufzeit auf Grundlage Ihrer Vorlage zu erstellen.

3. Warten Sie auf dem Tab Laufzeiten, bis der Status zu Fehlerfrei wechselt.

Notebook importieren

So importieren Sie das Notebook in Colab Enterprise:

1. Klicken Sie auf den Tab Meine Notebooks und dann auf Importieren. Der Bereich Notebooks importieren wird angezeigt.

2. Wählen Sie unter Importquelle die Option URL aus.

3. Geben Sie unter Notebook-URLs den folgenden Link ein:

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

4. Klicken Sie auf Importieren.

Mit der Laufzeit verbinden und Abfragen ausführen

So stellen Sie eine Verbindung zur Laufzeit her und führen Abfragen aus:

1. Klicken Sie im Notebook neben der Schaltfläche Verbinden auf arrow_drop_down Zusätzliche Verbindungsoptionen. Der Bereich Mit Vertex AI-Laufzeit verbinden wird angezeigt.

2. Wählen Sie Mit einer Laufzeit verbinden und dann Mit einer vorhandenen Laufzeit verbinden aus.

3. Wählen Sie die Laufzeit aus, die Sie gestartet haben, und klicken Sie auf Connect (Verbinden).

4. Klicken Sie zum Ausführen der Notebook-Zellen neben jeder Codezelle auf die Schaltfläche  Zelle ausführen.

Das Notebook enthält sowohl Codezellen als auch Text, der die einzelnen Codeblöcke beschreibt. Wenn Sie eine Codezelle ausführen, werden die darin enthaltenen Befehle ausgeführt und eine Ausgabe wird angezeigt. Sie können die Zellen der Reihe nach oder nach Bedarf einzeln ausführen.

Prometheus-Messwerte für Ihren Cluster aufrufen

Der GKE-Cluster wird mit Google Cloud Managed Service for Prometheus konfiguriert, der die Erfassung von Messwerten im Prometheus-Format ermöglicht. Dieser Dienst bietet eine vollständig verwaltete Lösung für Monitoring und Benachrichtigungen, die die Erfassung, Speicherung und Analyse von Messwerten aus dem Cluster und seinen Anwendungen ermöglicht.

Das folgende Diagramm zeigt, wie Prometheus Messwerte für Ihren Cluster erfasst:

Der private GKE-Cluster im Diagramm enthält die folgenden Komponenten:

• Elasticsearch-Pods, die Messwerte für den Pfad / und den Port 9114 verfügbar machen. Diese Messwerte werden vom Sidecar-Container namens metrics bereitgestellt, der den elasticsearch_exporter enthält.
• Prometheus-basierte Collectors, die die Messwerte aus dem Elasticsearch-Pod verarbeiten.
• Eine PodMonitoring-Ressource, die Messwerte an Cloud Monitoring sendet.

Die Clusterkonfiguration definiert einen Sidecar-Container mit Messwertexporter im Prometheus-Format:

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

So exportieren Sie die Messwerte und zeigen sie an:

1. Erstellen Sie die PodMonitoring-Ressource, um Messwerte nach labelSelector zu extrahieren:

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

   Das pod-monitoring.yaml-Manifest beschreibt die PodMonitoring-Ressource:

   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

   Nach einigen Minuten wird das integrierte Dashboard „Elasticsearch Prometheus – Übersicht“ angezeigt.

2. Wenn Sie weitere datenbezogene Grafiken aufrufen möchten, importieren Sie ein benutzerdefiniertes Cloud Monitoring-Dashboard mit den in dashboard.json definierten Konfigurationen:

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

3. Nachdem der Befehl erfolgreich ausgeführt wurde, rufen Sie die Cloud Monitoring-Dashboards auf:

   Zur Dashboard-Übersicht

4. Öffnen Sie in der Liste der Dashboards das ElasticSearch Overview-Dashboard. Es kann ein bis zwei Minuten dauern, bis Messwerte erfasst und angezeigt werden.

   Im Dashboard wird die Anzahl der wichtigsten Messwerte angezeigt:

   • Indexe
   • Dokumente und Shards
   • Ausstehende Vorgänge
   • Ausgeführte Knoten mit ihrem Systemstatus

Clusterkonfiguration sichern

Mit dem Feature Sicherung für GKE können Sie regelmäßige Sicherungen Ihrer gesamten GKE-Clusterkonfiguration planen, einschließlich der bereitgestellten Arbeitslasten und deren Daten.

In dieser Anleitung konfigurieren Sie einen Sicherungsplan für Ihren GKE-Cluster, um täglich um 3:00 Uhr alle Arbeitslasten, einschließlich Secrets und Volumes, zu sichern. Um eine effiziente Speicherverwaltung zu gewährleisten, werden Sicherungen, die älter als drei Tage sind, automatisch gelöscht.

1. Aktivieren Sie das Feature "Sicherung für GKE" für Ihren Cluster:

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

2. Erstellen Sie einen Sicherungsplan mit einem täglichen Zeitplan für alle Namespaces im 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
   

   Der Befehl verwendet zur Laufzeit die relevanten Umgebungsvariablen.

   Das Format des Clusternamens bezieht sich auf Ihr Projekt und Ihre Region:

   projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME
   

   Geben Sie bei Aufforderung y. ein. Die Ausgabe sieht in etwa so aus:

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

   Dieser Vorgang kann einige Minuten dauern. Nach Abschluss der Ausführung sieht die Ausgabe in etwa so aus:

   Created backup plan [elasticsearch-cluster-backup].
   

3. Der neu erstellte Sicherungsplan elasticsearch-cluster-backup wird in der Console von Backup for GKE aufgeführt.

   Zu „Sicherung für GKE“

Informationen zum Wiederherstellen der gespeicherten Sicherungskonfigurationen finden Sie unter Sicherung wiederherstellen.