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
Vantagens
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:
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.
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
- 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
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
forRUNNING
.
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
Autenticar usando senhas
É 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 porta8070
. - 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 podmetrics-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.
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
Exclua o projeto
Delete a Google Cloud project:
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.