Elasticsearch-Vektordatenbank in GKE bereitstellen

Autopilot Standard

In dieser Anleitung wird beschrieben, wie Sie einen Elasticsearch-Vektordatenbankcluster in Google Kubernetes Engine (GKE) bereitstellen.

Vektordatenbanken sind Datenspeicher, die speziell für die Verwaltung und Suche in großen Sammlungen von hochdimensionalen Vektoren entwickelt wurden. Diese Vektoren stellen Daten wie Text, Bilder, Audio, Video oder alle Daten dar, die numerisch codiert werden können. Im Gegensatz zu relationalen Datenbanken, die auf genaue Übereinstimmungen beruhen, sind Vektordatenbanken auf die Suche nach ähnlichen Elementen oder das Identifizieren von Mustern in umfangreichen Datasets spezialisiert.

Elasticsearch ist eine Vektordatenbank, die Such- und Analysefunktionen kombiniert. Es enthält eine offene REST API zur Verwaltung Ihres Clusters und unterstützt strukturierte Abfragen, Volltextabfragen und komplexe Abfragen. Mit Elasticsearch können Sie Wortgruppen, Ähnlichkeiten und Präfixsuchen mit automatisch vervollständigten Vorschlägen ausführen.

Diese Anleitung richtet sich an Cloud Platform-Administratoren und -Architekten, ML-Entwickler und MLOps-Experten (DevOps), die an der Bereitstellung von Elasticsearch-Datenbankclustern auf GKE interessiert sind.

Vorteile

Elasticsearch bietet folgende Vorteile:

Eine Vielzahl von Bibliotheken für verschiedene Programmiersprachen und eine offene API zur Einbindung in andere Dienste.
Horizontale Skalierung und Unterstützung für Fragmentierung und Replikation, die Skalierung und Hochverfügbarkeit vereinfacht.
Cluster-Balancing mit mehreren Knoten für optimale Ressourcennutzung.
Container- und Kubernetes-Unterstützung für eine nahtlose Integration in moderne cloudnative Umgebungen.

Lernziele

In dieser Anleitung erfahren Sie mehr über die folgenden Themen:

GKE-Infrastruktur für Elasticsearch planen und bereitstellen.
Elasticsearch in einem GKE-Cluster bereitstellen und konfigurieren.
Stellen Sie den Operator StatefulHA bereit, um für Elasticsearch eine Hochverfügbarkeit zu gewährleisten.
Demo-Dataset hochladen und Suchanfrage ausführen.
Messwerte in einem Dashboard erfassen und visualisieren

Bereitstellungsarchitektur

In dieser Anleitung stellen Sie einen hochverfügbaren regionalen GKE-Cluster für Elasticsearch bereit, wobei mehrere Kubernetes-Knoten über mehrere Verfügbarkeitszonen verteilt sind. Diese Konfiguration sorgt für Fehlertoleranz, Skalierbarkeit und geografische Redundanz. Damit können Rolling Updates und Wartungen durchgeführt werden, während SLAs für Verfügbarkeit und Verfügbarkeit bereitgestellt werden. Weitere Informationen finden Sie unter Regionale Cluster.

Wenn ein Knoten nicht mehr erreichbar ist, wird ein Pod auf diesem Knoten nicht sofort neu geplant. Wenn Pods ein StatefulSet verwenden, kann es länger als acht Minuten dauern, bis Anwendungs-Pods gelöscht und auf neue Knoten neu geplant werden.

Zur Behebung dieses Problems führt der StatefulHA-Operator folgende Schritte aus:

Behebt Verzögerungen bei der Neuplanung, übernimmt Failover-Einstellungen und verkürzt die Wiederherstellungszeit mithilfe der Einstellungen .forceDeleteStrategy: AfterNodeUnreachable.
Die StatefulSet-Anwendung muss RePD verwenden.
Erweitert GKE mit einer benutzerdefinierten HighAvailabilityApplication-Ressource, die im selben Namespace wie Elasticsearch bereitgestellt wird. Dadurch kann der StatefulHA-Operator Failover-Ereignisse überwachen und darauf reagieren.

Das folgende Diagramm zeigt einen Elasticsearch-Cluster, der auf mehreren Knoten und Zonen in einem GKE-Cluster ausgeführt wird:

Elasticsearch-Bereitstellungsarchitektur

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Die Nutzung von Elasticsearch ist im Rahmen der Server Side Public License (SSPL) kostenlos.

Hinweise

In dieser Anleitung verwenden Sie Cloud Shell zum Ausführen von Befehlen. Cloud Shell ist eine Shell-Umgebung für die Verwaltung von Ressourcen, die in Google Cloud gehostet werden. Es ist bei Google Cloud CLI, kubectl, Helm und Terraform-Befehlszeilentools vorinstalliert. Wenn Sie Cloud Shell nicht verwenden, müssen Sie die Google Cloud CLI installieren.

Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Installieren Sie die Google Cloud CLI.

Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

gcloud init

Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die neueste Version haben, indem Sie

gcloud components
      update

ausführen.

Google Cloud-Projekt erstellen oder auswählen.

Erstellen Sie ein Google Cloud-Projekt:
```
gcloud projects create PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud-Projekt, das Sie erstellen.
Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch den Namen Ihres Google Cloud-Projekts.

Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

Aktivieren Sie die Cloud Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE APIs:

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

Installieren Sie die Google Cloud CLI.

Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

gcloud init

Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die neueste Version haben, indem Sie

gcloud components
      update

ausführen.

Google Cloud-Projekt erstellen oder auswählen.

Erstellen Sie ein Google Cloud-Projekt:
```
gcloud projects create PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud-Projekt, das Sie erstellen.
Wählen Sie das von Ihnen erstellte Google Cloud-Projekt aus:
```
gcloud config set project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch den Namen Ihres Google Cloud-Projekts.

Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

Aktivieren Sie die Cloud Resource Manager, Compute Engine, GKE, IAM Service Account Credentials, and Backup for GKE APIs:

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

Gewähren Sie Ihrem Google-Konto Rollen. Führen Sie den folgenden Befehl für jede der folgenden IAM-Rollen einmal aus: role/storage.objectViewer, roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS" --role=ROLE
```
- Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
- Ersetzen Sie EMAIL_ADDRESS durch Ihre E-Mail-Adresse.
- Ersetzen Sie ROLE durch jede einzelne Rolle.

Umgebung einrichten

So richten Sie Ihre Umgebung mit Cloud Shell ein:

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 die Google Cloud-Projekt-ID.
In dieser Anleitung wird die Region us-central1 verwendet, um Ihre Bereitstellungsressourcen zu erstellen.

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

Klonen Sie das Beispielcode-Repository aus GitHub:

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

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.

Autopilot

Das folgende Diagramm zeigt einen im Projekt bereitgestellten Autopilot-GKE-Cluster.

GKE Autopilot-Cluster

Führen Sie die folgenden Befehle in der Cloud Shell aus, um die Clusterinfrastruktur bereitzustellen:

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 ersetzt zur Laufzeit die folgenden Variablen:

GOOGLE_OAUTH_ACCESS_TOKEN ruft mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab, das Interaktionen mit verschiedenen Google Cloud APIs authentifiziert.
PROJECT_ID, REGION und KUBERNETES_CLUSTER_PREFIX sind die im Abschnitt Umgebung einrichten definierten Umgebungsvariablen und den neuen relevanten Variablen für den Autopilot-Cluster zugewiesen, den Sie erstellen.

Geben Sie bei Aufforderung yes ein.

Die Ausgabe sieht in etwa so aus:

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

Outputs:

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

Terraform erstellt die folgenden Ressourcen:

Ein benutzerdefiniertes VPC-Netzwerk und ein privates Subnetz für die Kubernetes-Knoten
Ein Cloud Router für den Zugriff auf das Internet über Network Address Translation (NAT).
Ein privater GKE-Cluster in der Region us-central1.
Ein ServiceAccount mit Logging- und Monitoring-Berechtigungen für den Cluster.
Google Cloud Managed Service for Prometheus-Konfiguration für Clustermonitoring und Benachrichtigungen.

Standard

Das folgende Diagramm zeigt einen privaten Standard-GKE-Cluster, der in drei verschiedenen Zonen bereitgestellt wird.

GKE-Standardcluster

Führen Sie die folgenden Befehle in der Cloud Shell aus, um die Clusterinfrastruktur bereitzustellen:

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 ersetzt zur Laufzeit die folgenden Variablen:

GOOGLE_OAUTH_ACCESS_TOKEN ruft mit dem Befehl gcloud auth print-access-token ein Zugriffstoken ab, das Interaktionen mit verschiedenen Google Cloud APIs authentifiziert.
PROJECT_ID, REGION und KUBERNETES_CLUSTER_PREFIX sind die im Abschnitt Umgebung einrichten definierten Umgebungsvariablen und den neuen relevanten Variablen für den Standard-Cluster zugewiesen, den Sie erstellen.

Geben Sie bei Aufforderung yes ein. Es kann einige Minuten dauern, bis diese Befehle abgeschlossen sind und der Cluster den Status „Bereit“ anzeigt.

Die Ausgabe sieht in etwa so aus:

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

Outputs:

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

Terraform erstellt die folgenden Ressourcen:

Ein benutzerdefiniertes VPC-Netzwerk und ein privates Subnetz für die Kubernetes-Knoten
Ein Cloud Router für den Zugriff auf das Internet über Network Address Translation (NAT).
Ein privater GKE-Cluster in der Region us-central1 mit aktiviertem Autoscaling (ein bis zwei Knoten pro Zone).
Ein ServiceAccount mit Logging- und Monitoring-Berechtigungen für den Cluster.
Google Cloud Managed Service for Prometheus-Konfiguration für Clustermonitoring und Benachrichtigungen.

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.
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.
Zur Authentifizierung erstellt die Datenbank Kubernetes-Secrets mit Authentifizierungsdaten, Passwörtern und Zertifikaten.

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

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

ECK-Operator bereitstellen:

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

Erstellen Sie den Namespace elastic für die Datenbank:
```
kubectl create ns elastic
```

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

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

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

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.

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.

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>

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.

Demo-Dataset hochladen und Suchanfragen mit Jupyter-Notebook ausführen

In diesem Abschnitt laden Sie Vektoren in Elasticsearch-Dokumente hoch und führen semantische Suchanfragen mit dem offiziellen Elasticsearch-Python-Client durch. Ein Dokument in Elasticsearch besteht aus verschiedenen Feldern, die jeweils mit dem entsprechenden Wert gekoppelt sind. Für eine effektive Nutzung von Elasticsearch empfehlen wir Ihnen, Ihre Daten in diese Dokumente zu strukturieren, die dann zu Suchzwecken indiziert werden.

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.

Erstellen Sie die ConfigMaps books-dataset und notebook und führen Sie den Jupyter-Pod aus, um mit Ihrem Elasticsearch-Cluster zu interagieren:

kubectl create -n elastic configmap books-dataset --from-file=manifests/03-notebook/dataset.csv
kubectl create -n elastic configmap notebook --from-file=manifests/03-notebook/vector-database.ipynb
kubectl apply -n elastic -f manifests/03-notebook/jupyter.yaml

Das zuvor erstellte Secret mit dem Namen elasticsearch-ha-es-elastic-user wird im Client-Pod als Umgebungsvariable namens PW bereitgestellt.
Die ConfigMap books-dataset enthält eine csv-Datei mit Buchdaten für den Elasticsearch-Index.
Die ConfigMap notebook enthält das Jupyter-Notebook, um den Elasticsearch-Index aus books-dataset zu erstellen.

Das jupyter.yaml-Manifest beschreibt das notebook-Deployment und seinen Dienst:

---
apiVersion: v1
kind: Service
metadata:
  labels: &labels
    app: jupyter-notebook
  name: notebook
spec:
  ports:
  - port: 8888
  selector: *labels
  type: LoadBalancer
  # type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: notebook
  labels: &labels
    app: jupyter-notebook
spec:
  selector:
    matchLabels: *labels
  template:
    metadata: 
      labels: *labels
    spec:
      containers:
      - name: jupyter
        image: tensorflow/tensorflow:2.15.0-jupyter
        resources:
          requests:
            memory: "4500Mi"
            cpu: "1"
          limits:
            memory: "4500Mi"
            cpu: "1"
        ports:
        - containerPort: 8888
        env:
        - name: PW
          valueFrom:
            secretKeyRef:
              name: elasticsearch-ha-es-elastic-user
              key: elastic
        volumeMounts:
        - name: books-dataset
          mountPath: /usr/local/dataset
        - name: notebook
          mountPath: /tf
        - name: elastic-cert
          mountPath: /usr/local/cert
      volumes:
      - name: books-dataset
        configMap:
          name: books-dataset
      - name: notebook
        configMap:
          name: notebook
      - name: elastic-cert
        secret:
          secretName: elasticsearch-ha-es-http-certs-public

Warten Sie, bis GKE den Jupyter-Pod gestartet hat:

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

Rufen Sie die URL mit dem Zugriffstoken ab, um eine Verbindung zu Jupyter herzustellen:

export EXTERNAL_IP=$(kubectl -n elastic get svc notebook --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
kubectl logs deploy/notebook -n elastic| grep '^ .*http://127'|sed "s|127.0.0.1|${EXTERNAL_IP}|"

Öffnen Sie diese URL und klicken Sie auf die Datei vector-database.ipynb.

Klicken Sie auf Run > Run all Cells (Ausführen > Alle Zellen ausführen). Jupyter führt den Code aus und führt eine Suchanfrage für den Text drama about people and unhappy love durch.

Diese Abfrage führt eine semantische Suche nach Ihrem books-Index in Elasticsearch aus und ruft maximal zwei Ergebnisse mit dem höchsten Übereinstimmungswert ab, der für Ihre Abfrage relevant ist.

Die Ausgabe sieht in etwa so aus:

Title: Romeo and Juliet, Author: William Shakespeare, Paul Werstine (Editor),
Barbara A. Mowat (Editor), Paavo Emil Cajander (Translator), score: 1.8473973
In Romeo and Juliet, Shakespeare creates a violent world, in which two young people
fall in love. It is not simply that their families disapprove; the Montagues and
the Capulets are engaged in a blood feud.In this death-filled setting, the movement
from love at first sight to the lovers' final union in death seems almost inevitable.
And yet, this play set in an extraordinary world has become the quintessential
story of young love. In part because of its exquisite language, it is easy to
respond as if it were about all young lovers.
---------
Title: A Midsummer Night's Dream, Author: William Shakespeare, Paul Werstine
(Editor), Barbara A. Mowat (Editor), Catherine Belsey (Contributor), score: 1.8415744
Shakespeare's intertwined love polygons begin to get complicated from the
start--Demetrius and Lysander both want Hermia but she only has eyes for Lysander.
Bad news is, Hermia's father wants Demetrius for a son-in-law. On the outside
is Helena, whose unreturned love burns hot for Demetrius. Hermia and Lysander
plan to flee from the city under cover of darkness but are pursued by an enraged
Demetrius (who is himself pursued by an enraptured Helena). In the forest, unbeknownst
to the mortals, Oberon and Titania (King and Queen of the faeries) are having a
spat over a servant boy. The plot twists up when Oberon's head mischief-maker,
Puck, runs loose with a flower which causes people to fall in love with the first
thing they see upon waking. Throw in a group of labourers preparing a play for
the Duke's wedding (one of whom is given a donkey's head and Titania for a lover
by Puck) and the complications become fantastically funny.
---------

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:

Prometheus-Messwerterfassung

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:

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.

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
```
Nachdem der Befehl erfolgreich ausgeführt wurde, rufen Sie die Cloud Monitoring-Dashboards auf:

Zur Dashboard-Übersicht
Ö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.

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

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

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.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

Sie vermeiden weitere Kosten am einfachsten, wenn Sie das für die Anleitung erstellte Projekt löschen.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Google Cloud-Projekt löschen:

gcloud projects delete PROJECT_ID

Wenn Sie das Projekt gelöscht haben, ist die Bereinigung abgeschlossen. Wenn Sie das Projekt nicht gelöscht haben, fahren Sie mit dem Löschen der einzelnen Ressourcen fort.

Einzelne Ressourcen löschen

Umgebungsvariablen festlegen

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

Führen Sie den Befehl terraform destroy aus:

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

Ersetzen Sie FOLDER je nach Typ des von Ihnen erstellten GKE-Clusters durch gke-autopilot oder gke-standard.

Geben Sie bei Aufforderung yes ein.

Alle nicht angehängten Laufwerke suchen:

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

Laufwerke löschen:

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

GitHub-Repository löschen:
```
rm -r ~/kubernetes-engine-samples/
```

Nächste Schritte

Elasticsearch-Open-Source-Software
Best Practices für die Bereitstellung von Datenbanken in GKE.
Lösungen zum Ausführen datenintensiver Arbeitslasten mit GKE