Redis mit Redis Enterprise in GKE bereitstellen

Standard

In dieser Anleitung wird beschrieben, wie Sie Redis Enterprise in GKE-Clustern (Google Kubernetes Engine) bereitstellen.

Redis ist eine im Arbeitsspeicher ausgeführte Open-Source-NoSQL-Datenbank, die hauptsächlich für das Caching verwendet wird. Es hat integrierte Replikation, Lua-Scripting, LRU-Bereinigung, Transaktionen, Persistenz auf dem Laufwerk und Hochverfügbarkeit.

Redis Enterprise ist eine Lösung für Unternehmen, die das Open-Source-System von Redis mit einer vereinfachten Verwaltung erweitert. Dazu gehören u. a. georeplizierte Datenverteilung, lineare Skalierung des Vorgangsdurchsatzes, Data Tiering und erweiterte Sicherheitsfeatures.

Redis Enterprise hat für jede Bereitstellungsoption unterschiedliche Preise, darunter: Software, Cloud oder Hybrid- und Multi-Cloud.

Diese Anleitung richtet sich an Plattformadministratoren, Cloud-Architekten und Betriebsexperten, die daran interessiert sind, Redis Enterprise in Google Kubernetes Engine (GKE) bereitzustellen.

Ziele

GKE-Infrastruktur für Redis planen und bereitstellen
Redis Enterprise Operator bereitstellen
Redis Enterprise Cluster bereitstellen
Redis Enterprise-Datenbank erstellen
Datenbankauthentifizierung demonstrieren

Vorteile

Redis Enterprise bietet folgende Vorteile:

Eine Kubernetes-native Methode zum Verwalten des Lebenszyklus von Redis Enterprise Cluster (REC) und Redis Enterprise-Datenbanken (REDBs)
Ressourcennutzung durch gemeinsame Speicherung mehrerer Redis-Datenbanken in einem einzelnen Kubernetes-Pod
Reduzierter operativer Aufwand durch die Handhabung von routinemäßigen Wartungsaufgaben wie Patches und Upgrades
Unterstützung für Redis-Software-Images aus privaten Container-Registries wie Artifact Registry, um die Sicherheit und Verfügbarkeit von Containern zu verbessern
Unterstützung für Google Cloud Managed Service for Prometheus für Datenbank-Monitoring und -Beobachtbarkeit
Erweiterte Sicherheitsfeatures wie Verschlüsselung, Zugriffssteuerung und Einbindung in Kubernetes RBAC (Role-Based Access Control)
Erweiterte Authentifizierungsmethoden, einschließlich LDAP und Anmeldedatenmanager von Drittanbietern wie Vault
Möglichkeit, geplante Sicherungen zu konfigurieren

Bereitstellungsarchitektur

Redis Enterprise verwaltet die folgenden Kubernetes-Ressourcen:

Der Enterprise-Cluster und seine Konfiguration in einem StatefulSet. Der Cluster besteht aus Redis-Knoten (Pods) mit installierten Redis-Paketen. Diese Knoten haben laufende Prozesse, die dafür sorgen, dass der Knoten Teil eines Clusters ist. Jeder Knoten stellt einen Container zum Ausführen mehrerer Datenbankinstanzen (Shards) bereit. Obwohl in den Best Practices von Kubernetes festgelegt ist, dass ein Pod eine Anwendung mit einem Container darstellen sollte, stellt Redis Enterprise mehrere Redis-Datenbanken in einem einzelnen Container bereit. Dieser Ansatz bietet eine bessere Ressourcennutzung, Leistung und den Netzwerkdurchsatz. Jeder Container hat außerdem einen Proxy mit null Latenz, um Traffic an bestimmte Redis-Datenbankprozesse innerhalb eines Containers weiterzuleiten und zu verwalten.
Die benutzerdefinierte RedisEnterpriseDatabase-Ressource (REDBs), die die Redis-Datenbankinstanzen darstellt, die im REC erstellt wurden.
Kubernetes-Services, die REDB-Instanzen als Datenbankendpunkte bereitstellen
Ein Controller-Pod namens Service Rigger, der Datenbankendpunkte erstellt und löscht, wenn eine Datenbank erstellt oder gelöscht wird

In dieser Anleitung erstellen Sie eine 1:n-Bereitstellung. Stellen Sie dazu einen REC in einem dedizierten Namespace bereit und verwenden Sie separate Namespaces für Anwendungsbereitstellungen, um die Isolation zu verbessern.

Im folgenden Diagramm werden die Redis Enterprise-Komponenten und ihre Verknüpfung beschrieben:

Das Diagramm zeigt ein Beispiel für eine Redis Enterprise-Architektur. — **Abbildung 1**: Ein Beispiel für eine Redis Enterprise-Architektur.

In dieser Anleitung konfigurieren Sie den Redis Enterprise Cluster für hohe Verfügbarkeit. Dazu benötigt REC eine ungerade Anzahl von Knoten und mindestens drei Knoten. Sie legen auch Affinität, Anti-Affinitätsregeln und Knotenmarkierungen fest, damit jeder Redis-Knoten in einem anderen Kubernetes-Knoten platziert wird und die Redis-Knoten gleichmäßig über den Kubernetes-Cluster verteilt werden.

Die Verwendung mehrerer Knoten und Zonen ist aus folgenden Gründen von entscheidender Bedeutung, um einen hochverfügbaren GKE-Cluster zu erreichen:

Fehlertoleranz: Mehrere Knoten verteilen die Arbeitslast auf den Cluster. So wird sichergestellt, dass bei einem Ausfall eines Knotens die anderen Knoten die Aufgaben übernehmen können, wodurch Ausfallzeiten und Dienstunterbrechungen vermieden werden.
Skalierbarkeit: Das Vorhandensein mehrerer Knoten ermöglicht eine horizontale Skalierung. Dazu werden Knoten nach Bedarf hinzugefügt oder entfernt, um eine optimale Ressourcenzuweisung zu gewährleisten und den erhöhten Traffic- oder Arbeitslastanforderungen gerecht zu werden.
Hochverfügbarkeit: Die Verwendung mehrerer Zonen innerhalb einer Region sorgt für Redundanz und minimiert das Risiko eines Single Point of Failure. Wenn eine ganze Verfügbarkeitszone ausfällt, kann der Cluster weiterhin in anderen Zonen ausgeführt werden, um die Dienstverfügbarkeit aufrechtzuerhalten.
Geografische Redundanz: Durch die Aufteilung von Knoten über Regionen werden die Daten und Dienste des Clusters geografisch verteilt, wodurch Widerstandsfähigkeit gegen Naturkatastrophen, Stromausfälle oder andere lokale Störungen gewährleistet werden kann, die eine einzelne Zone betreffen können.
Rolling Updates und Wartung: Durch die Verwendung mehrerer Knoten können Sie Rolling Updates und Wartungen für einzelne Knoten durchführen, ohne die Gesamtverfügbarkeit des Clusters zu beeinträchtigen. Dies gewährleistet einen kontinuierlichen Dienst und ermöglicht es Ihnen, erforderliche Aktualisierungen durchzuführen und Patches nahtlos anzuwenden.
Service Level Agreements (SLAs): Google Cloud bietet SLAs für Bereitstellungen in mehreren Zonen. Damit wird ein Minimum an Betriebszeit und Verfügbarkeit garantiert.

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.

Hinweis

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine, IAM, GKE, and Resource Manager APIs:

gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine, IAM, GKE, and Resource Manager APIs:

gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com

Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/compute.securityAdmin, roles/compute.viewer, roles/container.clusterAdmin, roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
```
- Replace PROJECT_ID with your project ID.
- Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.
- Replace ROLE with each individual role.

Umgebung einrichten

In dieser Anleitung verwenden Sie Cloud Shell zum Verwalten von Ressourcen, die in Google Cloud gehostet werden. Die Software, die Sie für diese Anleitung benötigen, ist in Cloud Shell vorinstalliert, einschließlich kubectl, die gcloud CLI und Terraform.

So richten Sie Ihre Umgebung mit Cloud Shell ein:

Starten Sie eine Cloud Shell-Sitzung über die Google Cloud Console. Klicken Sie dazu in der Google Cloud Console auf Cloud Shell aktivieren. Dadurch wird im unteren Bereich der Google Cloud Console eine Sitzung gestartet.

Legen Sie Umgebungsvariablen fest:

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

Ersetzen Sie PROJECT_ID: Ihre Google Cloud mit Ihrer Projekt-ID.

Klonen Sie das GitHub-Repository:

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

Wechseln Sie in das Arbeitsverzeichnis:

cd kubernetes-engine-samples/databases/redis-enterprise-operator

Clusterinfrastruktur erstellen

In diesem Abschnitt führen Sie ein Terraform-Skript aus, um einen privaten, hochverfügbaren regionalen GKE-Cluster und eine VPC zu erstellen.

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

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

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

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

Terraform erstellt die folgenden Ressourcen:

Ein VPC-Netzwerk und ein privates Subnetz für die Kubernetes-Knoten
Ein Router für den Zugriff auf das Internet über NAT
Ein privater GKE-Cluster in der Region us-central1
Einen Knotenpool mit aktiviertem Autoscaling (ein bis zwei Knoten pro Zone, mindestens ein Knoten pro Zone)

Die Ausgabe sieht in etwa so aus:

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

Mit dem Cluster verbinden

Konfigurieren Sie in Cloud Shell kubectl für die Kommunikation mit dem Cluster:

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

Stellen Sie den Redis Enterprise-Operator in Ihrem Cluster bereit.

In diesem Abschnitt stellen Sie den Redis Enterprise-Operator in Ihrem Kubernetes-Cluster bereit.

Erstellen Sie Namespaces für den REC und die zugehörigen Anwendungen:

kubectl create namespace rec-ns
kubectl create namespace application

Kennzeichnen Sie die Namespaces mit Labels:

kubectl label namespace rec-ns connection=redis
kubectl label namespace application connection=redis

Rufen Sie die neueste Version des Redis Enterprise Operator-Bundles ab:

VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`

Installieren Sie den Redis Enterprise-Operator:

kubectl apply -n rec-ns -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml

Die Ausgabe sieht in etwa so aus:

role.rbac.authorization.k8s.io/redis-enterprise-operator created
rolebinding.rbac.authorization.k8s.io/redis-enterprise-operator created
serviceaccount/redis-enterprise-operator created
service/admission created
customresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com created
customresourcedefinition.apiextensions.k8s.io/redisenterprisedatabases.app.redislabs.com created
customresourcedefinition.apiextensions.k8s.io/redisenterpriseremoteclusters.app.redislabs.com created
customresourcedefinition.apiextensions.k8s.io/redisenterpriseactiveactivedatabases.app.redislabs.com created
deployment.apps/redis-enterprise-operator created

Redis Enterprise Cluster bereitstellen

Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml
```
Die Ausführung dieses Befehls kann mehrere Minuten dauern.

Prüfen Sie den Status der REC-Bereitstellung:

kubectl get rec -n rec-ns

Die Ausgabe sieht in etwa so aus:

NAME      NODES   VERSION    STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
gke-rec   3       7.2.4-52   Running   Valid         Valid           4              2023-09-29T20:15:32Z      4m7s

Der Cluster ist bereit, wenn STATE den Wert RUNNING hat.

Optional: Admission-Controller konfigurieren

Sie können optional die Infrastruktur für die Datenbankvalidierung beim Deployment konfigurieren.

Richten Sie den Admission-Controller ein und prüfen Sie, ob das Admission-TLS-Secret vorhanden ist:
```
kubectl get secret admission-tls -n rec-ns
```

Rufen Sie das Zertifikat ab:

export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')

Kopieren Sie das Zertifikat in die Datei webhook.yaml:

sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml

Stellen Sie den Validierungs-Webhook bereit:
```
sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
```
Der Admission-Controller validiert die Datenbanksyntax für beschriftete Namespaces.

Prüfen Sie den Admission-Controller, indem Sie eine nicht funktionierende Datenbank erstellen:

kubectl apply -n rec-ns -f - << EOF
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: redis-enterprise-database
spec:
  evictionPolicy: illegal
EOF

Die Ausgabe sieht in etwa so aus:

Error from server: error when creating "STDIN": admission webhook "redisenterprise.admission.redislabs" denied the request: 'illegal' is an invalid value for 'eviction_policy'. Possible values are ['volatile-lru', 'volatile-ttl', 'volatile-random', 'allkeys-lru', 'allkeys-random', 'noeviction', 'volatile-lfu', 'allkeys-lfu']

Namespaces erstellen

Standardmäßig hat der Redis Enterprise Operator keine Berechtigungen zum Ausführen von Aktionen außerhalb seines eigenen Namespace. Damit der Redis Enterprise Operator REDB- und Datenbankendpunkte in anderen Namespaces erstellen kann, müssen Sie RBAC konfigurieren.

Wenden Sie die entsprechende Rollen- und Rollenbindung im Anwendungs-Namespace an:

kubectl apply -f manifests/01-basic-cluster/role.yaml -n application
kubectl apply -f manifests/01-basic-cluster/role-binding.yaml -n application

Erstellen Sie die Clusterrolle und die Clusterrollenbindung im Namespace rec-ns:

kubectl apply -n rec-ns -f manifests/01-basic-cluster/cluster_role.yaml 
kubectl apply -n rec-ns -f manifests/01-basic-cluster/cluster_role_binding.yaml

Bearbeiten Sie die REC ConfigMap, um die Kontrolle über den Anwendungs-Namespace hinzuzufügen:
```
kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns
```
Jeder als ConfigMap gekennzeichnete Namespace wird gepatcht.

Prüfen Sie den Status der Ressourcen in Ihrer Redis-Infrastruktur im Namespace rec-ns:

kubectl get pod,deploy,svc,rec,statefulset,cm,secrets -n rec-ns

Die Ausgabe sieht in etwa so aus:

NAME                                             READY   STATUS    RESTARTS        AGE
pod/gke-rec-0                                    2/2     Running   0               172m
pod/gke-rec-1                                    2/2     Running   0               171m
pod/gke-rec-2                                    2/2     Running   0               168m
pod/gke-rec-services-rigger-5f885f59dc-gc79g     1/1     Running   0               172m
pod/redis-enterprise-operator-6668ccd8dc-kx29z   2/2     Running   2 (5m58s ago)   5h

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/gke-rec-services-rigger     1/1     1            1           172m
deployment.apps/redis-enterprise-operator   1/1     1            1           5h

NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)             AGE
service/admission      ClusterIP   10.52.11.13   <none>        443/TCP             5h
service/gke-rec        ClusterIP   10.52.5.44    <none>        9443/TCP,8001/TCP   172m
service/gke-rec-prom   ClusterIP   None          <none>        8070/TCP            172m
service/gke-rec-ui     ClusterIP   10.52.3.29    <none>        8443/TCP            172m

NAME                                               NODES   VERSION    STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
redisenterprisecluster.app.redislabs.com/gke-rec   3       7.2.4-52   Running   Valid         Valid           4              2023-10-05T11:07:20Z      172m

NAME                       READY   AGE
statefulset.apps/gke-rec   3/3     172m

NAME                                    DATA   AGE
configmap/gke-rec-bulletin-board        1      172m
configmap/gke-rec-health-check          5      172m
configmap/kube-root-ca.crt              1      5h2m
configmap/operator-environment-config   1      5h

NAME                   TYPE     DATA   AGE
secret/admission-tls   Opaque   2      5h
secret/gke-rec         Opaque   2      172m

Redis Enterprise-Datenbanken bereitstellen

Erstellen Sie Redis Enterprise-Datenbanken in den Anwendungs-Namespaces:

kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application

Prüfen Sie den REDB-Status:

kubectl get redb --all-namespaces

Die Ausgabe sieht in etwa so aus:

NAMESPACE       NAME       VERSION   PORT    CLUSTER   SHARDS   STATUS   SPEC STATUS   AGE
application   app-db   7.2.0     12999   gke-rec   1        active   Valid         15s

Prüfen Sie, ob die Services für jeden REDB ausgeführt werden:

kubectl get svc --all-namespaces

Die Ausgabe sieht in etwa so aus:

NAMESPACE      NAME      TYPE          CLUSTER-IP   EXTERNAL-IP                           PORT(S)    AGE
application  app-db  ExternalName  <none>       redis-12999.rec-ns.svc.cluster.local  12999/TCP  72m

Prüfen Sie, ob das Secret erstellt wurde:

kubectl get secrets -n application

Die Ausgabe sieht in etwa so aus:

NAME            TYPE     DATA   AGE
redb-app-db   Opaque   3      96m

Sie können über einen Pod mit redis-cli im Anwendungs-Namespace eine Verbindung zu REDB herstellen. Der Client-Pod verwendet die im Anwendungs-Namespace (REDB) verfügbaren Secrets, um eine Verbindung herzustellen.

Datenbanken, die mit der benutzerdefinierten Ressource-REDB erstellt wurden, unterstützen nur die Passwortauthentifizierung ohne ACL.

Erstellen Sie den Client-Pod:

kubectl apply -n application -f manifests/03-auth/client_pod.yaml

Stellen Sie eine Verbindung zum Client-Pod her:

kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh

Stellen Sie eine Verbindung zur Datenbank her:

redis-cli -h $SERVICE -p $PORT --pass $PASS

Schlüssel erstellen:
```
SET mykey "Hello World"
```
Die Ausgabe sieht in etwa so aus:
```
OK
```
Rufen Sie den Schlüssel ab:
```
GET mykey
```
Die Ausgabe sieht in etwa so aus:
```
"Hello World"
```
Beenden Sie die Pod-Shell
```
exit
```

Informationen zum Erfassen von Messwerten für den Redis-Cluster durch Prometheus

Das folgende Diagramm zeigt, wie die Erfassung von Prometheus-Messwerten funktioniert:

Im Diagramm enthält ein privater GKE-Cluster Folgendes:

Einen Redis-Pod, der Messwerte für den Pfad / und den Port 8070 erfasst.
Prometheus-basierte Collectors, die die Messwerte aus dem Redis-Pod verarbeiten.
Eine PodMonitoring-Ressource, die Messwerte an Cloud Monitoring sendet

Der Redis Enterprise-Operator stellt Clustermesswerte im Prometheus-Format bereit.

Erstellen Sie das Metrics-Proxy-Deployment:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml
```
Da der Operator nur einen HTTPS-Endpunkt mit dem selbst signierten Zertifikat bereitstellt und die Ressource PodMonitoring die Deaktivierung der TLS-Zertifikatsprüfung nicht unterstützt, verwenden Sie den Pod metrics-proxy als Reverse Proxy für diesen Endpunkt, um die Messwerte am HTTP-Port verfügbar zu machen.
Erstellen Sie die Ressource PodMonitoring, um Messwerte nach labelSelector zu extrahieren:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml
```
Rufen Sie in der Google Cloud Console die GKE-Seite Cluster auf.

Zum GKE-Cluster-Dashboard

Im Dashboard wird die Datenaufnahmerate ungleich null angezeigt.

Dashboard erstellen

Sie können die Messwerte aufrufen, indem Sie ein Dashboard erstellen.

Dashboard erstellen:

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

Die Ausgabe sieht in etwa so aus:

Created [f4efbe4e-2605-46b4-9910-54b13d29b3be].

Rufen Sie in der Google Cloud Console die Seite Dashboards auf.

Dashboards aufrufen
Öffnen Sie das Redis Enterprise Cluster-Dashboard. Es kann einige Minuten dauern, bis das Dashboard automatisch bereitgestellt wird.

Exportierte Messwerte prüfen

Erstellen Sie eine neue Datenbank und prüfen Sie die Messwerte, um die Messwerte zu prüfen.

Öffnen Sie das Redis Enterprise Cluster-Dashboard.
Erstellen Sie eine zusätzliche Redis-Datenbank:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml
```
Die Datenbankanzahl im Dashboard sollte aktualisiert werden.
Erstellen Sie einen Client-Pod, um eine Verbindung zur neuen Datenbank herzustellen:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml
```
Stellen Sie eine Verbindung zum Client-Pod her und bereiten Sie Variablen vor:
```
kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
```

Verwenden Sie das redis-cli-Tool, um neue Schlüssel zu erstellen.

for i in {1..50}; do \
  redis-cli -h $SERVICE -p $PORT -a $PASS \
  --no-auth-warning SET mykey-$i "myvalue-$i"; \
done

Aktualisieren Sie die Seite und achten Sie darauf, dass die Grafiken den tatsächlichen Datenbankstatus anzeigen.
Beenden Sie die Pod-Shell
```
exit
```

Bereinigen

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.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Einzelne Ressourcen löschen

Umgebungsvariablen festlegen

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

Führen Sie den Befehl terraform destroy aus:

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

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,zone)")

Laufwerke löschen:

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

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

Nächste Schritte

Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center

Redis mit Redis Enterprise in GKE bereitstellen

Ziele

Vorteile

Bereitstellungsarchitektur

Kosten

Hinweis

Umgebung einrichten

Clusterinfrastruktur erstellen

Mit dem Cluster verbinden

Stellen Sie den Redis Enterprise-Operator in Ihrem Cluster bereit.

Redis Enterprise Cluster bereitstellen

Optional: Admission-Controller konfigurieren

Namespaces erstellen

Redis Enterprise-Datenbanken bereitstellen

Mit Passwörtern authentifizieren

Informationen zum Erfassen von Messwerten für den Redis-Cluster durch Prometheus

Dashboard erstellen

Exportierte Messwerte prüfen

Bereinigen

Projekt löschen

Einzelne Ressourcen löschen

Nächste Schritte