Redis mit Redis Enterprise in GKE bereitstellen


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.

Lernziele

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

Hinweise

  1. 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.
  2. Installieren Sie die Google Cloud CLI.
  3. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

    gcloud init
  4. 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.

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

  6. Aktivieren Sie die Compute Engine, IAM, GKE, and Resource Manager APIs:

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com
  7. Installieren Sie die Google Cloud CLI.
  8. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

    gcloud init
  9. 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.

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

  11. Aktivieren Sie die Compute Engine, IAM, GKE, and Resource Manager APIs:

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com
  12. Gewähren Sie Ihrem Google-Konto Rollen. Führen Sie den folgenden Befehl für jede der folgenden IAM-Rollen einmal aus: 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: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

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:

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

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

  3. Klonen Sie das GitHub-Repository:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    
  4. 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.

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

    kubectl create namespace rec-ns
    kubectl create namespace application
    
  2. Kennzeichnen Sie die Namespaces mit Labels:

    kubectl label namespace rec-ns connection=redis
    kubectl label namespace application connection=redis
    
  3. 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}'`
    
  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

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

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

  1. 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
    
  2. Rufen Sie das Zertifikat ab:

    export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')
    
  3. Kopieren Sie das Zertifikat in die Datei webhook.yaml:

    sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
    
  4. 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.

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

  1. 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
    
  2. 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
    
  3. 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.

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

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

    kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application
    
  2. 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
    
  3. 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
    
  4. 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
    

Mit Passwörtern authentifizieren

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.

  1. Erstellen Sie den Client-Pod:

    kubectl apply -n application -f manifests/03-auth/client_pod.yaml
    
  2. Stellen Sie eine Verbindung zum Client-Pod her:

    kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh
    
  3. Stellen Sie eine Verbindung zur Datenbank her:

    redis-cli -h $SERVICE -p $PORT --pass $PASS
    
  4. Schlüssel erstellen:

    SET mykey "Hello World"
    

    Die Ausgabe sieht in etwa so aus:

    OK
    
  5. Rufen Sie den Schlüssel ab:

    GET mykey
    

    Die Ausgabe sieht in etwa so aus:

    "Hello World"
    
  6. 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.

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

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

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml
    
  3. 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.

  1. 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].
    
  2. Rufen Sie in der Google Cloud Console die Seite Dashboards auf.

    Dashboards aufrufen

  3. Ö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.

  1. Öffnen Sie das Redis Enterprise Cluster-Dashboard.

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

  3. 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
    
  4. Stellen Sie eine Verbindung zum Client-Pod her und bereiten Sie Variablen vor:

    kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
    
  5. 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
    
  6. Aktualisieren Sie die Seite und achten Sie darauf, dass die Grafiken den tatsächlichen Datenbankstatus anzeigen.

  7. Beenden Sie die Pod-Shell

    exit
    

Bereinigen

Projekt löschen

    Google Cloud-Projekt löschen:

    gcloud projects delete PROJECT_ID

Einzelne Ressourcen löschen

  1. Umgebungsvariablen festlegen

    export PROJECT_ID=${PROJECT_ID}
    export KUBERNETES_CLUSTER_PREFIX=redis
    export REGION=us-central1
    
  2. 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.

  3. 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)")
    
  4. 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
    
  5. 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