Implantar o Redis no GKE usando o Redis Enterprise


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:

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

  1. 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.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

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

  5. Make sure that billing is enabled for your Google Cloud project.

  6. 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
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

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

  10. Make sure that billing is enabled for your Google Cloud project.

  11. 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
  12. 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.

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:

  1. Inicie uma sessão do Cloud Shell no Console do Google Cloud clicando em Ícone de ativação do Cloud Shell Ativar o Cloud Shell no Console do Google Cloud. Isso inicia uma sessão no painel inferior do Cloud Console.

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

  3. Clone o repositório do GitHub:

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

  1. Crie namespaces para o REC e os aplicativos dele:

    kubectl create namespace rec-ns
    kubectl create namespace application
    
  2. Rotule os namespaces:

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

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

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

  1. 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
    
  2. Obtenha o certificado:

    export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')
    
  3. Copie o certificado no arquivo webhook.yaml:

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

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

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

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

  1. Crie bancos de dados Redis Enterprise nos namespaces do aplicativo:

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

  1. Crie o pod cliente:

    kubectl apply -n application -f manifests/03-auth/client_pod.yaml
    
  2. Conecte-se ao pod cliente:

    kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh
    
  3. Conecte-se ao banco de dados:

    redis-cli -h $SERVICE -p $PORT --pass $PASS
    
  4. Crie uma chave:

    SET mykey "Hello World"
    

    O resultado será assim:

    OK
    
  5. Obtenha a chave:

    GET mykey
    

    O resultado será assim:

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

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

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

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

  1. 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].
    
  2. No console do Google Cloud, acesse a página Painéis.

    Vá para Painéis

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

  1. Abra o painel do cluster do Redis Enterprise.

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

  3. 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
    
  4. Conecte-se ao pod cliente e prepare as variáveis:

    kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
    
  5. 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
    
  6. Atualize a página e observe se os gráficos foram atualizados para mostrar o estado real do banco de dados.

  7. Saia do shell do pod

    exit
    

Limpar

Exclua o projeto

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

Excluir recursos individuais

  1. Defina variáveis de ambiente.

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

  3. 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)")
    
  4. 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
    
  5. Para excluir o repositório do GitHub, faça o seguinte:

    rm -r ~/kubernetes-engine-samples/
    

A seguir