Ce guide vous explique comment déployer Redis Enterprise sur des clusters Google Kubernetes Engine (GKE).
Redis est une base de données Open Source en mémoire NoSQL principalement utilisée pour la mise en cache. Elle offre une réplication intégrée, des scripts Lua, l'éviction LRU, des transactions, la persistance sur disque et une haute disponibilité.
Redis Enterprise est une solution de niveau entreprise qui étend la base de données Open Source Redis et offre une gestion simplifiée, y compris la distribution des données géo-répliquées, le scaling linéaire du débit des opérations, la hiérarchisation des données, des fonctionnalités de sécurité avancées, etc.
La tarification de Redis Enterprise diffère pour chaque option de déploiement, y compris les suivantes : Logiciels, Cloud ou hybride et multicloud.
Ce guide est destiné aux administrateurs de plate-forme, aux architectes cloud et aux professionnels des opérations qui souhaitent déployer Redis Enterprise sur Google Kubernetes Engine (GKE).
Objectifs
- Planifier et déployer l'infrastructure GKE pour Redis
- Déployer l'opérateur Redis Enterprise
- Déployer un cluster Redis Enterprise
- Créer une base de données Redis Enterprise
- Démonstration de l'authentification de la base de données
Avantages
Redis Enterprise offre les avantages suivants :
- Un moyen Kubernetes natif de gérer le cycle de vie d'un cluster Redis Enterprise (REC) et les bases de données Redis Enterprise (REDB)
- Une utilisation des ressources en colocalisant plusieurs bases de données Redis dans un même pod Kubernetes
- Une réduction des frais généraux opérationnels en gérant les tâches de maintenance de routine telles que l'application de correctifs et les mises à niveau
- Une compatibilité des images logicielles Redis à partir de registres de conteneurs privés, tels qu'Artifact Registry, pour améliorer la sécurité et la disponibilité des conteneurs
- Une compatibilité avec Google Cloud Managed Service pour Prometheus pour la surveillance et l'observabilité de la base de données
- Des fonctionnalités de sécurité améliorées telles que le chiffrement, le contrôle des accès et l'intégration à Kubernetes RBAC (contrôle des accès basé sur les rôles)
- Des méthodes d'authentification avancées, y compris le service LDAP et les gestionnaires d'identifiants tiers tels que Vault
- La possibilité de configurer des sauvegardes planifiées
Architecture de déploiement
Redis Enterprise gère les ressources Kubernetes suivantes :
- Cluster Enterprise et sa configuration dans un StatefulSet. Le cluster est constitué de nœuds Redis (pods) avec des packages Redis installés. Ces nœuds disposent de processus en cours d'exécution pour s'assurer qu'ils font partie d'un cluster. Chaque nœud fournit un conteneur pour exécuter plusieurs instances de base de données (fragments). Bien que les bonnes pratiques de Kubernetes stipulent qu'un pod doit représenter une application avec un conteneur, Redis Enterprise déploie plusieurs bases de données Redis vers un seul conteneur. Cette approche offre une meilleure utilisation des ressources, de meilleures performances et un débit réseau plus élevé. Chaque conteneur dispose également d'un proxy à latence nulle pour acheminer et gérer le trafic vers des processus de base de données Redis spécifiques dans un conteneur.
- Ressource personnalisée
RedisEnterpriseDatabase
(REDBs) qui représente les instances de base de données Redis créées dans le REC - Services Kubernetes qui diffusent des instances REDB en tant que points de terminaison de base de données
- Un pod contrôleur nommé Service Rigger, qui crée et supprime des points de terminaison de base de données lors de la création ou de la suppression d'une base de données
Dans ce tutoriel, vous allez créer un déploiement un à plusieurs en déployant un REC dans un espace de noms dédié et en utilisant des espaces de noms distincts pour les déploiements d'applications pour une meilleure isolation.
Le schéma suivant décrit les composants de Redis Enterprise et leur interconnexion :
Dans ce tutoriel, vous allez configurer le cluster Redis Enterprise pour qu'il soit hautement disponible. Pour ce faire, le REC nécessite un nombre impair de nœuds et un minimum de trois nœuds. Vous définissez également des règles d'affinité, d'anti-affinité et des rejets de nœuds qui garantissent que chaque nœud Redis est placé dans un nœud Kubernetes différent et que les nœuds Redis sont répartis uniformément dans le cluster Kubernetes.
L'utilisation de plusieurs nœuds et zones est essentielle pour obtenir un cluster GKE à haute disponibilité, pour les raisons suivantes :
- Tolérance aux pannes : plusieurs nœuds répartissent la charge de travail sur le cluster. Ainsi, en cas de défaillance d'un nœud, les autres nœuds peuvent prendre le relais, ce qui évite les temps d'arrêt et les interruptions de service.
- Évolutivité : l'utilisation de plusieurs nœuds permet un scaling horizontal en ajoutant ou en supprimant des nœuds selon les besoins, ce qui garantit une allocation optimale des ressources et permet d'augmenter le trafic ou les demandes.
- Haute disponibilité : l'utilisation de plusieurs zones au sein d'une région garantit la redondance et réduit le risque de point de défaillance unique. Si toute une zone de disponibilité subit une défaillance, le cluster peut continuer à s'exécuter dans d'autres zones et maintenir la disponibilité du service.
- Redondance géographique : en répartissant des nœuds entre les régions, les données et les services du cluster sont répartis géographiquement, ce qui permet de résister aux catastrophes naturelles, aux pannes de courant ou à d'autres perturbations locales susceptibles d'affecter une seule zone.
- Mises à jour et maintenance progressives : en utilisant plusieurs nœuds, vous pouvez effectuer des mises à jour et une maintenance progressives sur des nœuds individuels sans affecter la disponibilité globale du cluster. Cela garantit un service continu tout en vous permettant d'effectuer les mises à jour nécessaires et d'appliquer les correctifs de manière transparente.
- Contrats de niveau de service (SLA) : Google Cloud fournit, pour les déploiements multizones, des contrats de niveau de service qui garantissent un niveau minimal de temps d'activité et de disponibilité.
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.
Avant de commencer
- 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
-
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
-
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.
- Replace
Configurer votre environnement
Dans ce tutoriel, vous utilisez Cloud Shell pour gérer les ressources hébergées sur Google Cloud. Les logiciels dont vous avez besoin pour ce tutoriel sont préinstallés sur Cloud Shell, y compris kubectl
, la gcloud CLI, et Terraform.
Pour configurer votre environnement avec Cloud Shell, procédez comme suit :
Lancez une session Cloud Shell depuis la console Google Cloud en cliquant sur Activer Cloud Shell dans la console Google Cloud. Une session s'ouvre dans le volet inférieur de la console Google Cloud.
Définissez les variables d'environnement :
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=redis export REGION=us-central1
Remplacez
PROJECT_ID
par votre ID de projet Google Cloud.Clonez le dépôt GitHub.
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Accédez au répertoire de travail :
cd kubernetes-engine-samples/databases/redis-enterprise-operator
Créer l'infrastructure de votre cluster
Dans cette section, vous allez exécuter un script Terraform pour créer un VPC et un cluster GKE régional, privé, à disponibilité élevée.
Le schéma suivant présente un cluster GKE standard régional privé déployé sur trois zones différentes :
Pour déployer cette infrastructure, exécutez les commandes suivantes à partir de Cloud Shell :
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}
Lorsque vous y êtes invité, saisissez yes
. L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.
Terraform crée les ressources suivantes :
- Un réseau VPC et un sous-réseau privé pour les nœuds Kubernetes.
- Un routeur pour accéder à Internet via NAT.
- Un cluster GKE privé dans la région
us-central1
. - Un pool de nœuds avec autoscaling activé (un à deux nœuds par zone, un nœud par zone au minimum).
Le résultat ressemble à ce qui suit :
...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...
Se connecter au cluster
Avec Cloud Shell, configurez kubectl
pour communiquer avec le cluster :
gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}
Déployer l'opérateur Redis Enterprise sur votre cluster
Dans cette section, vous allez déployer l'opérateur Redis Enterprise sur votre cluster Kubernetes.
Créez des espaces de noms pour le REC et ses applications :
kubectl create namespace rec-ns kubectl create namespace application
Ajoutez un libellé aux espaces de noms :
kubectl label namespace rec-ns connection=redis kubectl label namespace application connection=redis
Obtenez la dernière version du bundle d'opérateurs Redis Enterprise :
VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`
Installez l'opérateur Redis Enterprise :
kubectl apply -n rec-ns -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml
Le résultat ressemble à ce qui suit :
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
Déployer un cluster Redis Enterprise
Appliquez le fichier manifeste à votre cluster :
kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml
Cette commande peut prendre plusieurs minutes.
Vérifiez l'état du déploiement de REC :
kubectl get rec -n rec-ns
Le résultat ressemble à ce qui suit :
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
Le cluster est prêt lorsque
STATE
est défini surRUNNING
.
Facultatif : Configurer le contrôleur d'admission
Vous pouvez éventuellement configurer l'infrastructure pour la validation de la base de données lors du déploiement.
Configurez le contrôleur d'admission et vérifiez si le secret TLS d'admission est présent :
kubectl get secret admission-tls -n rec-ns
Obtenez le certificat :
export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')
Copiez le certificat dans le fichier
webhook.yaml
:sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
Déployez le webhook de validation :
sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
Le contrôleur d'admission valide la syntaxe de la base de données sur les espaces de noms étiquetés.
Vérifiez le contrôleur d'admission en créant une base de données non fonctionnelle :
kubectl apply -n rec-ns -f - << EOF apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseDatabase metadata: name: redis-enterprise-database spec: evictionPolicy: illegal EOF
Le résultat ressemble à ce qui suit :
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']
Créer des espaces de noms
Par défaut, l'opérateur Redis Enterprise ne dispose d'aucun droit permettant d'effectuer des actions en dehors de son propre espace de noms. Pour autoriser l'opérateur Redis Enterprise à créer des points de terminaison REDB et de base de données dans d'autres espaces de noms, vous devez configurer RBAC.
Appliquez le rôle et la liaison de rôle correspondants dans l'espace de noms de l'application :
kubectl apply -f manifests/01-basic-cluster/role.yaml -n application kubectl apply -f manifests/01-basic-cluster/role-binding.yaml -n application
Créez un rôle de cluster et une liaison de rôle de cluster dans l'espace de noms
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
Modifiez le fichier ConfigMap REC pour ajouter un contrôle sur l'espace de noms de l'application :
kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns
Chaque espace de noms libellé comme ConfigMap est corrigé.
Vérifiez l'état des ressources de votre infrastructure Redis dans l'espace de noms
rec-ns
:kubectl get pod,deploy,svc,rec,statefulset,cm,secrets -n rec-ns
Le résultat ressemble à ce qui suit :
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
Déployer des bases de données Redis Enterprise
Créez des bases de données Redis Enterprise dans les espaces de noms de l'application :
kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application
Vérifiez l'état REDB :
kubectl get redb --all-namespaces
Le résultat ressemble à ce qui suit :
NAMESPACE NAME VERSION PORT CLUSTER SHARDS STATUS SPEC STATUS AGE application app-db 7.2.0 12999 gke-rec 1 active Valid 15s
Vérifiez que les services de chaque REDB sont en cours d'exécution :
kubectl get svc --all-namespaces
Le résultat ressemble à ce qui suit :
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
Vérifiez que le secret a été créé :
kubectl get secrets -n application
Le résultat ressemble à ce qui suit :
NAME TYPE DATA AGE redb-app-db Opaque 3 96m
S'authentifier à l'aide de mots de passe
Vous pouvez vous connecter à REDB à l'aide d'un pod avec redis-cli
dans l'espace de noms de l'application. Le pod client utilise les secrets disponibles dans l'espace de noms de l'application (REDB) pour établir une connexion.
Les bases de données créées avec le REDB de ressource personnalisée ne sont compatibles qu'avec l'authentification par mot de passe sans LCA.
Créez le pod client :
kubectl apply -n application -f manifests/03-auth/client_pod.yaml
Connectez-vous au pod client :
kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh
Connectez-vous à la base de données :
redis-cli -h $SERVICE -p $PORT --pass $PASS
Créez une clé :
SET mykey "Hello World"
Le résultat ressemble à ce qui suit :
OK
Obtenez la clé :
GET mykey
Le résultat ressemble à ce qui suit :
"Hello World"
Quittez l'interface système du pod.
exit
Comprendre comment Prometheus collecte les métriques pour votre cluster Redis
Le schéma suivant illustre le fonctionnement de la collecte de métriques Prometheus :
Dans le schéma, un cluster privé GKE contient :
- Un pod Redis qui collecte des métriques sur le chemin
/
et le port8070
- Collecteurs basés sur Prometheus qui traitent les métriques à partir du pod Redis
- Une ressource
PodMonitoring
qui envoie des métriques à Cloud Monitoring
L'opérateur Redis Enterprise expose les métriques de cluster au format Prometheus.
Créez le déploiement metrics-proxy :
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml
Étant donné que l'opérateur ne fournit qu'un point de terminaison HTTPS avec le certificat autosigné et que la ressource
PodMonitoring
ne permet pas de désactiver la validation du certificat TLS, utilisez le podmetrics-proxy
en sens inverse. Proxy pour ce point de terminaison afin d'exposer les métriques sur le port HTTP.Créez la ressource PodMonitoring pour récupérer les métriques par
labelSelector
:kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml
Dans la console Google Cloud, accédez à la page Tableau de bord des clusters GKE.
Accéder au tableau de bord des clusters GKE
Le tableau de bord affiche un taux d'ingestion de métriques différent de zéro.
Créer un tableau de bord
Vous pouvez afficher les métriques en créant un tableau de bord.
Créez le tableau de bord :
gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json
Le résultat ressemble à ce qui suit :
Created [f4efbe4e-2605-46b4-9910-54b13d29b3be].
Dans la console Google Cloud, accédez à la page Tableaux de bord.
Ouvrez le tableau de bord des clusters Redis Enterprise. Le provisionnement automatique du tableau de bord peut prendre plusieurs minutes.
Vérifier les métriques exportées
Pour vérifier les métriques, créez une base de données et examinez les métriques.
Ouvrez le tableau de bord des clusters Redis Enterprise.
Créez une base de données Redis supplémentaire :
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml
Le nombre de bases de données du tableau de bord doit être mis à jour.
Créez un pod client pour vous connecter à la nouvelle base de données :
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml
Connectez-vous au pod client et préparez les variables :
kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
Utilisez l'outil
redis-cli
pour créer des clés :for i in {1..50}; do \ redis-cli -h $SERVICE -p $PORT -a $PASS \ --no-auth-warning SET mykey-$i "myvalue-$i"; \ done
Actualisez la page et observez que les graphiques ont été mis à jour pour afficher l'état réel de la base de données.
Quittez l'interface système du pod.
exit
Effectuer un nettoyage
Supprimer le projet
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
Supprimer des ressources individuelles
Définissez les variables d'environnement.
export PROJECT_ID=${PROJECT_ID} export KUBERNETES_CLUSTER_PREFIX=redis export REGION=us-central1
Exécutez la commande
terraform destroy
: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}
Lorsque vous y êtes invité, saisissez
yes
.Recherchez tous les disques non associés :
export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
Supprimez les disques :
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
Supprimez le dépôt GitHub :
rm -r ~/kubernetes-engine-samples/
Étapes suivantes
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.