Implantar o Redis no GKE usando o Redis Enterprise

Padrão

O guia mostra como implantar o Redis Enterprise nos clusters do Google Kubernetes Engine (GKE).

O Redis é um banco de dados NoSQL na memória de código aberto usado principalmente para armazenamento em cache. Ele tem replicação integrada, scripting Lua, remoção de LRU, transações, persistência no disco e alta disponibilidade.

Além disso, é uma solução de nível empresarial que estende o código aberto do Redis com gerenciamento simplificado, incluindo distribuição de dados replicados geograficamente, escalonamento linear de capacidade de operações, níveis de dados, recursos avançados de segurança e muito mais.

O Redis Enterprise tem preços diferentes para cada opção de implantação, incluindo: Software, Nuvem ou Híbrido e Multicloud.

Este guia é destinado a administradores de plataformas, arquitetos de nuvem e profissionais de operações interessados em implantar o Redis Enterprise no Google Kubernetes Engine (GKE).

Objetivos

Planejar e implantar a infraestrutura do GKE para Redis
Implantar o Redis Enterprise Operator
Implantar um cluster do Redis Enterprise
Criar um banco de dados do Redis Enterprise
Demonstrar a autenticação do banco de dados

Benefícios

O Redis Enterprise oferece os seguintes benefícios:

Uma maneira nativa do Kubernetes de gerenciar o ciclo de vida do Cluster do Redis Enterprise (REC) e os bancos de dados do Redis Enterprise (REDBs)
Utilização de recursos por meio da colocalização de vários bancos de dados do Redis em um único pod do Kubernetes.
Redução da sobrecarga operacional ao lidar com tarefas de rotina de manutenção, como aplicação de patches e upgrades
Suporte a imagens de software Redis de registros de contêineres privados, como o Artifact Registry, para melhorar a segurança e a disponibilidade dos contêineres.
Suporte ao Google Cloud Managed Service para Prometheus para monitoramento e observabilidade de banco de dados
Recursos de segurança aprimorados, como criptografia, controles de acesso e integração com o Kubernetes RBAC (controle de acesso baseado em função)
Métodos de autenticação avançados, incluindo LDAP e gerenciadores de credenciais de terceiros, como
Capacidade de configurar backups programados

Arquitetura de implantação

O Redis Enterprise gerencia os seguintes recursos do Kubernetes:

O cluster Enterprise e a configuração dele em um StatefulSet O cluster consiste em nós (pods) do Redis com pacotes do Redis instalados. Esses nós têm processos em execução para garantir que o nó faça parte de um cluster. Cada nó tem um contêiner para executar várias instâncias de banco de dados (fragmentos). As práticas recomendadas do Kubernetes determinam que um pod deve representar um aplicativo com um contêiner. No entanto, o Redis Enterprise implanta vários bancos de dados do Redis em um único contêiner. Essa abordagem oferece uma melhor utilização de recursos, desempenho e capacidade de rede. Cada contêiner também tem um proxy de latência zero para rotear e gerenciar o tráfego para processos específicos de banco de dados do Redis em um contêiner.
O recurso personalizado RedisEnterpriseDatabase (REDBs) que representa as instâncias de banco de dados do Redis criadas no REC
Serviços do Kubernetes que disponibilizam instâncias do REDB como endpoints de banco de dados
Um pod controlador chamado Service Rigger, que cria e exclui endpoints do banco de dados quando um banco de dados é criado ou excluído

Neste tutorial, você cria uma implantação de um para muitos implantando um REC em um namespace dedicado e usando namespaces separados para implantações de aplicativos, para um melhor isolamento.

No diagrama a seguir, descrevemos os componentes do Redis Enterprise e como eles estão interconectados:

O diagrama mostra um exemplo de arquitetura do Redis Enterprise. — **Figura 1**: exemplo de arquitetura do Redis Enterprise.

Neste tutorial, você vai configurar o Cluster do Redis Enterprise para ser altamente disponível. Para fazer isso, o REC exige um número ímpar de nós, no mínimo três. Você também define afinidade, regras de antiafinidade e taints de nó que garantem que cada nó do Redis seja colocado em um nó diferente do Kubernetes e que sejam distribuídos de maneira uniforme por todo o cluster do Kubernetes.

O uso de vários nós e zonas é crucial para ter um cluster do GKE altamente disponível, pelos seguintes motivos:

Tolerância a falhas: vários nós distribuem a carga de trabalho pelo cluster, garantindo que, se um nó falhar, os outros poderão assumir as tarefas, evitando inatividade e interrupções de serviço.
Escalonabilidade: ter vários nós permite o escalonamento horizontal adicionando ou removendo nós conforme necessário, garantindo a alocação ideal de recursos e acomodando o aumento de tráfego ou demandas de carga de trabalho.
Alta disponibilidade: usar várias zonas em uma região garante redundância e minimiza o risco de um ponto único de falha. Se uma zona de disponibilidade inteira passar por uma interrupção do serviço, o cluster poderá continuar sendo executado em outras zonas, mantendo a disponibilidade do serviço.
Redundância geográfica: ao abranger nós em todas as regiões, os dados e serviços do cluster são distribuídos geograficamente, proporcionando resiliência contra desastres naturais, faltas de energia ou outras interrupções locais que possam afetar uma única zona.
Atualizações e manutenção graduais: ao usar vários nós, é possível executar atualizações e manutenção graduais em nós individuais sem afetar a disponibilidade geral do cluster. Isso garante um serviço contínuo, permitindo que você realize as atualizações necessárias e aplique os patches sem interrupções.
Contratos de nível de serviço (SLAs): o Google Cloud fornece SLAs para implantações em várias zonas, garantindo um nível mínimo de tempo de atividade e disponibilidade.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Observação: se você instalou a CLI gcloud anteriormente, verifique se tem a versão mais recente executando

gcloud components
      update

Crie ou selecione um projeto do Google Cloud.

Crie um projeto do Google Cloud:
```
gcloud projects create PROJECT_ID
```
Substitua PROJECT_ID por um nome para o projeto do Google Cloud que você está criando.
Selecione o projeto do Google Cloud que você criou:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo nome do projeto do Google Cloud.

Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Ative as APIs Compute Engine, IAM, GKE, and Resource Manager:

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

Instale a CLI do Google Cloud.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Observação: se você instalou a CLI gcloud anteriormente, verifique se tem a versão mais recente executando

gcloud components
      update

Crie ou selecione um projeto do Google Cloud.

Crie um projeto do Google Cloud:
```
gcloud projects create PROJECT_ID
```
Substitua PROJECT_ID por um nome para o projeto do Google Cloud que você está criando.
Selecione o projeto do Google Cloud que você criou:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo nome do projeto do Google Cloud.

Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Ative as APIs Compute Engine, IAM, GKE, and Resource Manager:

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

Atribua os papéis à sua Conta do Google. Execute uma vez o seguinte comando para cada um dos seguintes papéis do IAM: 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
```
- Substitua PROJECT_ID pela ID do seu projeto.
- Substitua EMAIL_ADDRESS pelo seu endereço de e-mail.
- Substitua ROLE por cada papel individual.

configure seu ambiente

Neste tutorial, você usará o Cloud Shell para gerenciar recursos hospedados no Google Cloud. O Cloud Shell vem pré-instalado com o software necessário para este tutorial, incluindo kubectl, a gcloud CLI e Terraform.

Para configurar o ambiente com o Cloud Shell, siga estas etapas:

Inicie uma sessão do Cloud Shell no Console do Google Cloud clicando em Ativar o Cloud Shell no Console do Google Cloud. Isso inicia uma sessão no painel inferior do Cloud Console.

Defina as variáveis de ambiente:

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

Substitua PROJECT_ID: o Google Cloud pelo ID do projeto.

Clone o repositório do GitHub:

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

Mude para o diretório de trabalho:

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

Criar a infraestrutura do cluster

Nesta seção, você executará um script do Terraform para criar um cluster do GKE e uma VPC privada e altamente disponível.

O diagrama a seguir mostra um cluster regional padrão particular do GKE implantado em três zonas diferentes:

Para implantar essa infraestrutura, execute os seguintes comandos no 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 solicitado, digite yes. Pode levar vários minutos para que esse comando seja concluído e o cluster mostre um status pronto.

O Terraform cria os seguintes recursos:

Uma rede VPC e uma sub-rede particular para os nós do Kubernetes.
Um roteador para acessar a Internet usando NAT.
Um cluster particular do GKE na região us-central1.
Um pool de nós com escalonamento automático ativado (de um a dois nós por zona, no mínimo um nó por zona)

O resultado será assim:

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

Conexão ao cluster

Usando o Cloud Shell, configure kubectl para se comunicar com o cluster:

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

Implantar o operador Redis Enterprise no seu cluster

Nesta seção, você implantará o operador Redis Enterprise no seu cluster do Kubernetes.

Crie namespaces para o REC e os aplicativos dele:

kubectl create namespace rec-ns
kubectl create namespace application

Rotule os namespaces:

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

Obtenha a versão mais recente do pacote do operador Redis Enterprise:

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

Instale o operador Redis Enterprise:

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

O resultado será assim:

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

Implantar o cluster do Redis Enterprise

Aplique o manifesto ao cluster:
```
kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml
```
O comando pode levar alguns minutos para ser concluído.

Verifique o status da implantação do REC:

kubectl get rec -n rec-ns

O resultado será assim:

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

O cluster estará pronto quando STATE for RUNNING.

Opcional: configurar o controlador de admissão

Se quiser, é possível configurar a infraestrutura para a validação do banco de dados na implantação.

Configure o controlador de admissão e verifique se o Secret tls de admissão está presente:
```
kubectl get secret admission-tls -n rec-ns
```

Obtenha o certificado:

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

Copie o certificado no arquivo webhook.yaml:

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

Implante o webhook de validação:
```
sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
```
O controlador de admissão valida a sintaxe do banco de dados em namespaces rotulados.

Verifique o controlador de admissão criando um banco de dados não funcional:

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

O resultado será assim:

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

Criar namespaces

Por padrão, o operador Redis Enterprise não tem privilégios para executar ações fora do próprio namespace. Para permitir que o operador Redis Enterprise crie endpoints de banco de dados e REDB em outros namespaces, configure o RBAC.

Aplique o papel e a vinculação de papel correspondentes no namespace do aplicativo:

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

Crie um papel de cluster e uma vinculação de papel de cluster no 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

Edite o REC ConfigMap para adicionar controle sobre o namespace do aplicativo:

kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns

Cada namespace rotulado como ConfigMap recebe um patch.

Verifique o status dos recursos na infraestrutura do Redis no namespace rec-ns:

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

O resultado será assim:

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

Implantar bancos de dados Redis Enterprise

Crie bancos de dados Redis Enterprise nos namespaces do aplicativo:

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

Verifique o status de REDB:

kubectl get redb --all-namespaces

O resultado será assim:

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

Verifique se os serviços de cada REDB estão em execução:

kubectl get svc --all-namespaces

O resultado será assim:

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

Verifique se o Secret foi criado:

kubectl get secrets -n application

O resultado será assim:

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

É possível se conectar ao REDB usando um pod com redis-cli no namespace do aplicativo. O pod cliente usa os secrets disponíveis no namespace do aplicativo (REDB) para estabelecer uma conexão.

Os bancos de dados criados com o recurso personalizado de REDB são compatíveis apenas com a autenticação por senha sem ACL.

Crie o pod cliente:

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

Conecte-se ao pod cliente:

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

Conecte-se ao banco de dados:

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

Crie uma chave:
```
SET mykey "Hello World"
```
O resultado será assim:
```
OK
```
Obtenha a chave:
```
GET mykey
```
O resultado será assim:
```
"Hello World"
```
Saia do shell do pod
```
exit
```

Entender como o Prometheus coleta métricas para seu cluster do Redis

No diagrama a seguir, mostramos como funciona a coleta de métricas do Prometheus:

No diagrama, um cluster particular do GKE contém os seguintes componentes:

Um pod Redis que coleta métricas no caminho / e na porta 8070.
Coletores baseados em Prometheus que processam as métricas do pod do Redis.
Um recurso PodMonitoring que envia métricas ao Cloud Monitoring.

O operador Redis Enterprise expõe as métricas do cluster no formato do Prometheus.

Crie a implantação metrics-proxy:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml
```
Como o operador fornece apenas um endpoint HTTPS com o certificado autoassinado e o recurso PodMonitoring não oferece suporte à desativação da verificação de certificado TLS, use o pod metrics-proxy como um proxy reverso desse endpoint para expor as métricas na porta HTTP.

Crie o recurso PodMonitoring para raspar métricas por labelSelector:

kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml

No console do Google Cloud, acesse a página Painel de clusters do GKE.

Acessar o painel de clusters do GKE

O painel mostra uma taxa de ingestão de métricas diferente de zero.

Criar um painel

Para visualizar as métricas, crie um painel.

Crie o painel:

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

O resultado será assim:

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

No console do Google Cloud, acesse a página Painéis.

Vá para Painéis
Abra o painel do cluster do Redis Enterprise. Pode levar vários minutos para que o painel seja provisionado automaticamente.

Verificar as métricas exportadas

Para verificar as métricas, crie um banco de dados e examine as métricas.

Abra o painel do cluster do Redis Enterprise.
Crie um banco de dados adicional do Redis:
```
kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml
```
A Contagem de banco de dados no painel será atualizada.

Crie um pod cliente para se conectar ao novo banco de dados:

kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml

Conecte-se ao pod cliente e prepare as variáveis:

kubectl exec -it redis-client-c -n rec-ns -- /bin/bash

Use a ferramenta redis-cli para criar novas chaves:

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

Atualize a página e observe se os gráficos foram atualizados para mostrar o estado real do banco de dados.
Saia do shell do pod
```
exit
```

Limpar

Excluir o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

Exclua um projeto do Google Cloud:

gcloud projects delete PROJECT_ID

Excluir recursos individuais

Defina variáveis de ambiente.

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

Execute o 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 solicitado, digite yes.

Encontre todos os discos desanexados:

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

Exclua os discos:

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

Para excluir o repositório do GitHub, faça o seguinte:
```
rm -r ~/kubernetes-engine-samples/
```

A seguir

Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.

Implantar o Redis no GKE usando o Redis Enterprise

Objetivos

Benefícios

Arquitetura de implantação

Custos

Antes de começar

configure seu ambiente

Criar a infraestrutura do cluster

Conexão ao cluster

Implantar o operador Redis Enterprise no seu cluster

Implantar o cluster do Redis Enterprise

Opcional: configurar o controlador de admissão

Criar namespaces

Implantar bancos de dados Redis Enterprise

Autenticar usando senhas

Entender como o Prometheus coleta métricas para seu cluster do Redis

Criar um painel

Verificar as métricas exportadas

Limpar

Excluir o projeto

Excluir recursos individuais

A seguir