Implemente o Redis no GKE com o Redis Enterprise

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

O Redis é uma base de dados NoSQL de código aberto na memória usada principalmente para colocação em cache. Tem replicação incorporada, scripting Lua, remoção LRU, transações, persistência no disco e alta disponibilidade.

O Redis Enterprise é uma solução de nível empresarial que expande o Redis de código aberto com gestão simplificada, incluindo distribuição de dados com replicação geográfica, escalabilidade linear do débito de operações, hierarquização de dados, funcionalidades de segurança avançadas e muito mais.

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

Este guia destina-se a administradores de plataformas, arquitetos da nuvem e profissionais de operações interessados na implementação do Redis Enterprise no Google Kubernetes Engine (GKE).

Objetivos

  • Planeie e implemente a infraestrutura do GKE para o Redis
  • Implemente o operador Redis Enterprise
  • Implemente um cluster Redis Enterprise
  • Crie uma base de dados do Redis Enterprise
  • Demonstre a autenticação da base de dados

Vantagens

O Redis Enterprise oferece as seguintes vantagens:

  • Uma forma nativa do Kubernetes de gerir o ciclo de vida do Redis Enterprise Cluster (REC) e as bases de dados Redis Enterprise (REDBs)
  • Utilização de recursos através da colocação conjunta de várias bases de dados Redis num único pod do Kubernetes
  • Redução dos encargos operacionais através do processamento de tarefas de manutenção de rotina, como aplicação de patches e atualizações
  • Suporte para imagens de software Redis de registos de contentores privados, como o Artifact Registry, para melhorar a segurança e a disponibilidade dos contentores
  • Suporte do serviço gerido Google Cloud para Prometheus para monitorização e observabilidade de bases de dados
  • Funcionalidades de segurança melhoradas, como encriptação, controlos de acesso e integração com o RBAC (controlo de acesso baseado em funções) do Kubernetes
  • Métodos de autenticação avançados, incluindo LDAP e gestores de credenciais de terceiros, como o Vault
  • Capacidade de configurar cópias de segurança agendadas

Arquitetura de implementação

O Redis Enterprise gere os seguintes recursos do Kubernetes:

  • O cluster Enterprise e a respetiva configuração num StatefulSet. O cluster é composto por nós Redis (pods) com pacotes Redis instalados. Estes nós têm processos em execução para garantir que o nó faz parte de um cluster. Cada nó fornece um contentor para executar várias instâncias da base de dados (fragmentos). Embora as práticas recomendadas do Kubernetes indiquem que um pod deve representar uma aplicação com um contentor, o Redis Enterprise implementa várias bases de dados Redis num único contentor. Esta abordagem oferece uma melhor utilização dos recursos, desempenho e débito da rede. Cada contentor também tem um proxy de latência zero para encaminhar e gerir o tráfego para processos de base de dados Redis específicos num contentor.
  • O recurso personalizado RedisEnterpriseDatabase (REDBs) que representa as instâncias da base de dados Redis criadas no REC
  • Serviços Kubernetes que servem instâncias REDB como pontos finais de bases de dados
  • Um pod de controlador denominado Service Rigger que cria e elimina pontos finais da base de dados quando uma base de dados é criada ou eliminada

Neste tutorial, vai criar uma implementação de um para muitos implementando um REC num espaço de nomes dedicado e usando espaços de nomes separados para implementações de aplicações para um melhor isolamento.

O diagrama seguinte descreve os componentes do Redis Enterprise e como estão interligados:

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

Neste tutorial, configura o Redis Enterprise Cluster para ter elevada disponibilidade. Para isso, o REC requer um número ímpar de nós e um mínimo de três nós. Também define regras de afinidade, anti-afinidade e taints de nós que garantem que cada nó do Redis é colocado num nó diferente do Kubernetes e que os nós do Redis são distribuídos uniformemente pelo cluster do Kubernetes.

A utilização de vários nós e zonas é crucial para alcançar um cluster do GKE de alta disponibilidade 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 nós podem assumir as tarefas, evitando o tempo de inatividade e as interrupções do serviço.
  • Escalabilidade: 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 do tráfego ou das exigências de carga de trabalho.
  • Alta disponibilidade: a utilização de várias zonas numa região garante a redundância e minimiza o risco de um único ponto de falha. Se uma zona de disponibilidade inteira sofrer uma interrupção, o cluster pode continuar a ser executado noutras zonas, mantendo a disponibilidade do serviço.
  • Redundância geográfica: ao abranger nós em várias regiões, os dados e os serviços do cluster são distribuídos geograficamente, o que oferece resiliência contra desastres naturais, falhas de energia ou outras interrupções locais que possam afetar uma única zona.
  • Atualizações contínuas e manutenção: ao usar vários nós, pode fazer atualizações contínuas e manutenção em nós individuais sem afetar a disponibilidade geral do cluster. Isto garante um serviço contínuo enquanto lhe permite fazer as atualizações necessárias e aplicar patches de forma integrada.
  • Contratos de nível de serviço (SLAs): Google Cloud oferece SLAs para implementações em várias zonas, garantindo um nível mínimo de tempo de atividade e disponibilidade.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custos com base na sua utilização prevista, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação sem custo financeiro.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

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. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

  4. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

  5. Create or select a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Compute Engine, IAM, GKE, and Resource Manager APIs:

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles. 

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

  8. Install the Google Cloud CLI.

  9. Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

  10. Para inicializar a CLI gcloud, execute o seguinte comando: 

    gcloud init

  11. Create or select a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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

  12. Verify that billing is enabled for your Google Cloud project.

  13. Enable the Compute Engine, IAM, GKE, and Resource Manager APIs:

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles. 

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

  14. 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 the following:

    • PROJECT_ID: Your project ID.
    • USER_IDENTIFIER: The identifier for your user account. For example, myemail@example.com.
    • ROLE: The IAM role that you grant to your user account.

    15. Configure o seu ambiente

    Neste tutorial, vai usar o Cloud Shell para gerir recursos alojados no Google Cloud. O Cloud Shell vem pré-instalado com o software de que precisa para este tutorial, incluindo o kubectl, a CLI gcloud e o Terraform.

    Para configurar o seu ambiente com o Cloud Shell, siga estes passos:

    1. Inicie uma sessão do Cloud Shell a partir da Google Cloud consola clicando em Ícone de ativação do Cloud Shell Ativar Cloud Shell na Google Cloud consola. Esta ação inicia uma sessão no painel inferior da Google Cloud consola.

    2. Defina variáveis de ambiente:

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

      Substitua PROJECT_ID: seu Google Cloud pelo seu ID do projeto.

    3. Clone o repositório do GitHub:

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

    4. Altere para o diretório de trabalho:

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

    Crie a infraestrutura do cluster

    Nesta secção, executa um script do Terraform para criar um cluster do GKE regional privado de alta disponibilidade e uma VPC.

    O diagrama seguinte mostra um cluster GKE padrão regional privado implementado em três zonas diferentes:

    Para implementar esta infraestrutura, execute os seguintes comandos a partir do 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 lhe for pedido, escreva yes. Este comando pode demorar vários minutos a ser concluído e o cluster a apresentar o estado pronto.

    O Terraform cria os seguintes recursos:

    • Uma rede VPC e uma sub-rede privada para os nós do Kubernetes
    • Um router para aceder à Internet através de NAT
    • Um cluster do GKE privado na região de us-central1
    • Um conjunto de nós com o dimensionamento automático ativado (um a dois nós por zona, um nó por zona no mínimo)

    O resultado é semelhante ao seguinte:

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

    Estabeleça ligação ao cluster

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

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

    Implemente o operador Redis Enterprise no seu cluster

    Nesta secção, implementa o operador do Redis Enterprise no seu cluster do Kubernetes.

    1. Crie espaços de nomes para o REC e as respetivas aplicações:

      kubectl create namespace rec-ns
kubectl create namespace application

    2. Etiquete os espaços de nomes:

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

    3. Obtenha a versão mais recente do pacote do operador do 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 do Redis Enterprise:

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

      O resultado é semelhante ao seguinte:

      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

    Implemente o Redis Enterprise Cluster

    1. Aplique o manifesto ao cluster:

      kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml

      O comando pode demorar vários minutos a ser concluído.

    2. Verifique o estado da implementação do REC:

      kubectl get rec -n rec-ns

      O resultado é semelhante ao seguinte:

      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 está pronto quando STATE é RUNNING.

    Opcional: configure o controlador de admissão

    Opcionalmente, pode configurar a infraestrutura para a validação da base de dados na implementação.

    1. Configure o controlador de admissão e verifique se o segredo de 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 para o ficheiro webhook.yaml:

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

    4. Implemente 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 da base de dados em espaços de nomes etiquetados.

    5. Valide o controlador de admissão criando uma base 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 é semelhante ao seguinte:

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

    Crie espaços de nomes

    Por predefinição, o operador Redis Enterprise não tem privilégios para realizar ações fora do seu próprio espaço de nomes. Para permitir que o operador do Redis Enterprise crie pontos finais de REDB e de base de dados noutros espaços de nomes, tem de configurar o RBAC.

    1. Aplique a função e a associação de funções correspondentes no espaço de nomes da aplicação:

      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 uma função de cluster e uma associação de funções 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 controlo sobre o espaço de nomes da aplicação:

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

      Cada espaço de nomes etiquetado como ConfigMap é corrigido.

    4. Verifique o estado dos recursos na sua infraestrutura Redis no espaço de nomes rec-ns:.

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

      O resultado é semelhante ao seguinte:

      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

    Implemente bases de dados Redis Enterprise

    1. Crie bases de dados Redis Enterprise nos espaços de nomes das aplicações:

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

    2. Verifique o estado do REDB:

      kubectl get redb --all-namespaces

      O resultado é semelhante ao seguinte:

      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 é semelhante ao seguinte:

      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 é semelhante ao seguinte:

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

    Autentique com palavras-passe

    Pode estabelecer ligação ao REDB através de um Pod com redis-cli no espaço de nomes da aplicação. O pod do cliente usa os segredos disponíveis no espaço de nomes da aplicação (REDB) para estabelecer uma ligação.

    As bases de dados criadas com o recurso personalizado REDB só suportam a autenticação por palavra-passe sem ACL.

    1. Crie o pod do cliente:

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

    2. Ligue-se ao pod do cliente:

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

    3. Associe à base de dados:

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

    4. Crie uma chave:

      SET mykey "Hello World"

      O resultado é semelhante ao seguinte:

      OK

    5. Obtenha a chave:

      GET mykey

      O resultado é semelhante ao seguinte:

      "Hello World"

    6. Saia da shell do Pod

      exit

    Compreenda como o Prometheus recolhe métricas para o seu cluster Redis

    O diagrama seguinte mostra como funciona a recolha de métricas do Prometheus:

    No diagrama, um cluster privado do GKE contém:

    • Um pod do Redis que recolhe métricas no caminho / e na porta 8070
    • Recolhedores baseados no Prometheus que processam as métricas do pod do Redis
    • Um recurso PodMonitoring que envia métricas para o Cloud Monitoring

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

    1. Crie a implementação metrics-proxy:

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

      Uma vez que o operador só fornece um ponto final HTTPS com o certificado autoassinado e o recurso PodMonitoring não suporta a desativação da validação do certificado TLS, usa o pod metrics-proxy como um proxy inverso para este ponto final para expor as métricas na porta HTTP.

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

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

    3. Na Google Cloud consola, aceda à página Painel de controlo de clusters do GKE.

      Aceda ao painel de controlo de clusters do GKE

      O painel de controlo mostra a taxa de carregamento de métricas diferente de zero.

    Crie um painel de controlo

    Pode ver as métricas criando um painel de controlo.

    1. Crie o painel de controlo:

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

      O resultado é semelhante ao seguinte:

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

    2. Na Google Cloud consola, aceda à página Painéis de controlo.

      Aceder a Painéis de controlo

    3. Abra o painel de controlo do Redis Enterprise Cluster. O aprovisionamento automático do painel de controlo pode demorar vários minutos.

    Valide as métricas exportadas

    Para validar as métricas, crie uma nova base de dados e examine as métricas.

    1. Abra o painel de controlo do Redis Enterprise Cluster.

    2. Crie uma base de dados Redis adicional:

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

      A quantidade de bases de dados no painel de controlo deve ser atualizada.

    3. Crie um pod de cliente para estabelecer ligação à nova base de dados:

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

    4. Estabeleça ligação ao pod do 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 que os gráficos foram atualizados para mostrar o estado real da base de dados.

    7. Saia da shell do pod

      exit

    Limpar

    Elimine o projeto

      Delete a Google Cloud project:

      gcloud projects delete PROJECT_ID

    Elimine 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 lhe for pedido, escreva yes.

    3. Encontre todos os discos não anexados:

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

    4. Elimine 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. Elimine o repositório do GitHub:

      rm -r ~/kubernetes-engine-samples/

    O que se segue?