La guida illustra come eseguire il deployment Redis Enterprise ai cluster Google Kubernetes Engine (GKE).
Redis è un servizio NoSQL in memoria open source usato principalmente per la memorizzazione nella cache. Dispone di replica integrata, scripting Lua, Eliminazione dell'LRU, transazioni, persistenza su disco e disponibilità elevata.
Redis Enterprise è una soluzione di livello enterprise che estende Redis open source con una gestione semplificata, tra cui la distribuzione dei dati con replica geografica, la scalabilità lineare del throughput delle operazioni, la suddivisione in livelli dei dati, funzionalità di sicurezza avanzate e altro ancora.
Redis Enterprise ha prezzi diversi per ogni opzione di implementazione, tra cui: Software, Cloud o ibrido e multi-cloud.
Questa guida è rivolta agli amministratori di piattaforma, ai cloud architect e professionisti delle operazioni interessati a eseguire il deployment di Redis Enterprise Google Kubernetes Engine (GKE).
Obiettivi
- Pianifica ed esegui il deployment dell'infrastruttura GKE per Redis
- Esegui il deployment dell'operatore Redis Enterprise
- Esegui il deployment di un cluster Redis Enterprise
- Crea un database Redis Enterprise
- Dimostrare l'autenticazione del database
Vantaggi
Redis Enterprise offre i seguenti vantaggi:
- Un modo nativo di Kubernetes per gestire il ciclo di vita dei cluster Redis Enterprise (REC) e dei database Redis Enterprise (REDB)
- Utilizzo delle risorse mediante la collocazione in comune di più database Redis in un singolo pod Kubernetes
- Ha ridotto l'overhead operativo grazie alla gestione delle attività di manutenzione di routine, patch e upgrade
- Supporto per le immagini software Redis da registry dei container privati, come Artifact Registry, per migliorare la sicurezza e la disponibilità dei container
- Supporto di Google Cloud Managed Service per Prometheus per il monitoraggio e il monitoraggio dei database osservabilità
- Funzionalità di sicurezza avanzate come crittografia, controlli dell'accesso e integrazione con RBAC (controllo degli accessi basato sui ruoli) di Kubernetes
- Metodi di autenticazione avanzati, tra cui LDAP e gestori delle credenziali di terze parti come Vault
- Possibilità di configurare i backup pianificati
Architettura di deployment
Redis Enterprise gestisce le seguenti risorse Kubernetes:
- Il cluster Enterprise e la relativa configurazione in un StatefulSet. Il cluster è costituito da nodi Redis (pod) con i pacchetti Redis installati. Questi nodi hanno per garantire che il nodo faccia parte di un cluster. Ogni nodo fornisce un contenitore per eseguire più istanze di database (shard). Sebbene le best practice di Kubernetes indichino che un pod debba rappresentare un'applicazione con un container, Redis Enterprise esegue il deployment di più database Redis in un unico container. Questo approccio offre una migliore utilizzo delle risorse, prestazioni e velocità effettiva della rete. Ogni container ha anche un proxy a latenza zero per instradare e gestire il traffico verso specifici processi del database Redis all'interno di un container.
- La risorsa personalizzata
RedisEnterpriseDatabase
(REDB) che rappresenta le istanze di database Redis create all'interno del REC - Servizi Kubernetes che pubblicano istanze REDB come endpoint di database
- Un pod di controllo chiamato Service Rigger che crea ed elimina gli endpoint del database quando viene creato o eliminato un database
In questo tutorial, crei un deployment one-to-many implementando un REC in uno spazio dei nomi dedicato e utilizzando spazi dei nomi distinti per i deployment delle applicazioni per un isolamento migliore.
Il seguente diagramma descrive i componenti di Redis Enterprise e il loro interconnesse:
In questo tutorial, configuri Redis Enterprise Cluster in modo che sia altamente disponibile. Per farlo, il REC richiede un numero dispari di nodi e un minimo di tre nodi. Imposti inoltre regole di affinità, anti-affinità e contaminazioni dei nodi che assicurano che ogni nodo Redis sia posizionato in un nodo Kubernetes diverso e che i nodi Redis siano distribuiti uniformemente nel cluster Kubernetes.
L'utilizzo di più nodi e zone è fondamentale per ottenere un'elevata disponibilità cluster GKE per i seguenti motivi:
- Tolleranza agli errori: più nodi distribuiscono il carico di lavoro nel cluster, garantendo che, in caso di errore di un nodo, gli altri possano assumere il controllo delle attività, evitando tempi di inattività e interruzioni del servizio.
- Scalabilità: avere più nodi consente la scalabilità orizzontale aggiungendo o rimuovendo nodi in base alle esigenze, garantendo un'allocazione ottimale delle risorse in grado di soddisfare le maggiori esigenze di traffico o carico di lavoro.
- Disponibilità elevata: l'utilizzo di più zone all'interno di una regione garantisce la ridondanza e riduce al minimo il rischio di un singolo punto di défaillance. Se un'intera zona di disponibilità presenta un'interruzione, il cluster può continuare a funzionare in altre zone, mantenendo la disponibilità del servizio.
- Ridondanza geografica: abbracciando i nodi tra regioni, il valore e servizi sono distribuiti geograficamente, fornendo resilienza calamità naturali, interruzioni di corrente o altre interruzioni locali che potrebbero in una singola zona.
- Aggiornamenti e manutenzione in sequenza: utilizzando più nodi, puoi eseguire aggiornamenti e manutenzione in sequenza sui singoli nodi senza influire sulla disponibilità complessiva del cluster. In questo modo viene garantito un servizio continuo, allo stesso tempo ti consente di eseguire gli aggiornamenti necessari e applicare le patch senza problemi.
- Accordi sul livello del servizio (SLA): Google Cloud fornisce SLA per i deployment multizona, garantendo un livello minimo di uptime e disponibilità.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.
Prima di iniziare
- 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
Configura l'ambiente
In questo tutorial utilizzerai Cloud Shell per gestire le risorse ospitate
in Google Cloud. Cloud Shell è preinstallato con il software necessario
per questo tutorial, inclusi
kubectl
, il
gcloud CLI e Terraform.
Per configurare l'ambiente con Cloud Shell:
Avvia una sessione Cloud Shell dalla console Google Cloud facendo clic su Attiva Cloud Shell nella console Google Cloud. Verrà avviata una sessione nel riquadro inferiore della console Google Cloud.
Imposta le variabili di ambiente:
export PROJECT_ID=PROJECT_ID export KUBERNETES_CLUSTER_PREFIX=redis export REGION=us-central1
Sostituisci
PROJECT_ID
: il tuo Google Cloud con ID progetto.Clona il repository GitHub:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Passa alla directory di lavoro:
cd kubernetes-engine-samples/databases/redis-enterprise-operator
Crea l'infrastruttura del cluster
In questa sezione eseguirai uno script Terraform per creare un'istanza privata, un cluster GKE a livello di regione e un VPC ad alta disponibilità.
Il seguente diagramma mostra un cluster GKE regionale privato standard di cui è stato eseguito il deployment in tre zone diverse:
Per eseguire il deployment di questa infrastruttura, esegui i seguenti comandi da 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}
Quando richiesto, digita yes
. Potrebbero essere necessari diversi minuti prima che questo comando
completata e affinché il cluster mostri lo stato Pronto.
Terraform crea le seguenti risorse:
- Una rete VPC e una subnet privata per i nodi Kubernetes
- Un router per accedere a Internet tramite NAT
- Un cluster GKE privato nella regione
us-central1
- Un pool di nodi con scalabilità automatica abilitata (da uno a due nodi per zona, nodo per zona minimo)
L'output è simile al seguente:
...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...
Connettiti al cluster
Utilizzando Cloud Shell, configura kubectl
in modo che comunichi con il cluster:
gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}
Esegui il deployment dell'operatore Redis Enterprise nel cluster
In questa sezione eseguirai il deployment Operatore Redis Enterprise al tuo cluster Kubernetes.
Crea spazi dei nomi per il REC e le relative applicazioni:
kubectl create namespace rec-ns kubectl create namespace application
Etichetta gli spazi dei nomi:
kubectl label namespace rec-ns connection=redis kubectl label namespace application connection=redis
Scarica la versione più recente del bundle Redis Enterprise Operator:
VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`
Installa l'operatore Redis Enterprise:
kubectl apply -n rec-ns -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml
L'output è simile al seguente:
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
Esegui il deployment del cluster Redis Enterprise
Applica il manifest al cluster:
kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml
Il completamento del comando potrebbe richiedere diversi minuti.
Controlla lo stato del deployment del REC:
kubectl get rec -n rec-ns
L'output è simile al seguente:
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
Il cluster è pronto quando
STATE
èRUNNING
.
(Facoltativo) Configura il controller di ammissione
Facoltativamente, puoi configurare l'infrastruttura per la convalida del database al momento del deployment.
Configura il controller di ammissione e controlla se il secret tls di ammissione è attuale:
kubectl get secret admission-tls -n rec-ns
Ottieni il certificato:
export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')
Copia il certificato nel file
webhook.yaml
:sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
Esegui il deployment del webhook di convalida:
sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
Il controller di ammissione convalida la sintassi del database negli spazi dei nomi etichettati.
Verifica il controller di ammissione creando un database non funzionale:
kubectl apply -n rec-ns -f - << EOF apiVersion: app.redislabs.com/v1alpha1 kind: RedisEnterpriseDatabase metadata: name: redis-enterprise-database spec: evictionPolicy: illegal EOF
L'output è simile al seguente:
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']
Crea spazi dei nomi
Per impostazione predefinita, l'operatore Redis Enterprise non dispone dei privilegi per eseguire azioni al di fuori del proprio spazio dei nomi. Per consentire a Redis Enterprise Operator di creare endpoint REDB e database in altri spazi dei nomi, devi configurare RBAC.
Applica il ruolo e l'associazione di ruoli corrispondente nello spazio dei nomi dell'applicazione:
kubectl apply -f manifests/01-basic-cluster/role.yaml -n application kubectl apply -f manifests/01-basic-cluster/role-binding.yaml -n application
Crea il ruolo e l'associazione del ruolo cluster nello spazio dei nomi
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
Modifica il ConfigMap REC per aggiungere il controllo sullo spazio dei nomi dell'applicazione:
kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns
La patch è applicata a ogni spazio dei nomi etichettato come ConfigMap.
Controlla lo stato delle risorse nell'infrastruttura Redis nel Spazio dei nomi
rec-ns
:.kubectl get pod,deploy,svc,rec,statefulset,cm,secrets -n rec-ns
L'output è simile al seguente:
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
Esegui il deployment dei database Redis Enterprise
Crea database Redis Enterprise negli spazi dei nomi dell'applicazione:
kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application
Controlla lo stato REDB:
kubectl get redb --all-namespaces
L'output è simile al seguente:
NAMESPACE NAME VERSION PORT CLUSTER SHARDS STATUS SPEC STATUS AGE application app-db 7.2.0 12999 gke-rec 1 active Valid 15s
Verifica che i servizi di ogni REDB siano in esecuzione:
kubectl get svc --all-namespaces
L'output è simile al seguente:
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
Verifica che il secret sia stato creato:
kubectl get secrets -n application
L'output è simile al seguente:
NAME TYPE DATA AGE redb-app-db Opaque 3 96m
Esegui l'autenticazione utilizzando password
Puoi connetterti a REDB utilizzando un pod con redis-cli
nell'applicazione
nello spazio dei nomi. Il pod client utilizza i secret disponibili nello spazio dei nomi dell'applicazione (REDB) per stabilire una connessione.
I database creati con il supporto della risorsa personalizzata REDB sono solo supportati autenticazione tramite password senza ACL.
Crea il pod client:
kubectl apply -n application -f manifests/03-auth/client_pod.yaml
Connettiti al pod client:
kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh
Connettiti al database:
redis-cli -h $SERVICE -p $PORT --pass $PASS
Crea una chiave:
SET mykey "Hello World"
L'output è simile al seguente:
OK
Ottieni la chiave:
GET mykey
L'output è simile al seguente:
"Hello World"
Esci dalla shell del pod
exit
Scopri come Prometheus raccoglie le metriche per il tuo cluster Redis
Il seguente diagramma mostra come funziona la raccolta delle metriche di Prometheus:
Nel diagramma, un cluster privato GKE contiene:
- Un pod Redis che raccoglie le metriche sul percorso
/
e sulla porta8070
- Raccoglitori basati su Prometheus che elaborano le metriche del pod Redis
- Una risorsa
PodMonitoring
che invia le metriche a Cloud Monitoring
L'operatore Redis Enterprise espone le metriche del cluster in formato Prometheus.
Crea il deployment metrics-proxy:
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml
Poiché l'operatore fornisce solo un endpoint HTTPS con l'oggetto e la risorsa
PodMonitoring
non supporta la disattivazione Verifica del certificato TLS: il podmetrics-proxy
viene usato come operazione inversa proxy per questo endpoint per esporre le metriche sulla porta HTTP.Crea il PodMonitoring per eseguire lo scraping delle metriche in base a
labelSelector
:kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml
Nella console Google Cloud, vai alla pagina Dashboard dei cluster GKE.
Vai alla dashboard dei cluster GKE
La dashboard mostra il tasso di importazione delle metriche diverse da zero.
Creare una dashboard
Puoi visualizzare le metriche creando una dashboard.
Crea la dashboard:
gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json
L'output è simile al seguente:
Created [f4efbe4e-2605-46b4-9910-54b13d29b3be].
Nella console Google Cloud, vai alla pagina Dashboard.
Apri la dashboard Redis Enterprise Cluster. Potrebbero essere necessari diversi minuti per il provisioning automatico della dashboard.
Verificare le metriche esportate
Per verificare le metriche, crea un nuovo database ed esaminale.
Apri la dashboard Redis Enterprise Cluster.
Crea un database Redis aggiuntivo:
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml
Il valore Conteggio database nella dashboard dovrebbe aggiornarsi.
Crea un pod client per connetterti al nuovo database:
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml
Connettiti al pod client e prepara le variabili:
kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
Utilizza lo strumento
redis-cli
per creare nuove chiavi:for i in {1..50}; do \ redis-cli -h $SERVICE -p $PORT -a $PASS \ --no-auth-warning SET mykey-$i "myvalue-$i"; \ done
Aggiorna la pagina e osserva che i grafici sono stati aggiornati per mostrare lo stato effettivo del database.
Esci dalla shell del pod
exit
Esegui la pulizia
Elimina il progetto
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
Elimina singole risorse
Imposta le variabili di ambiente.
export PROJECT_ID=${PROJECT_ID} export KUBERNETES_CLUSTER_PREFIX=redis export REGION=us-central1
Esegui il comando
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}
Quando richiesto, digita
yes
.Trova tutti i dischi scollegati:
export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
Elimina i dischi:
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
Elimina il repository GitHub:
rm -r ~/kubernetes-engine-samples/
Passaggi successivi
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.